Service Principal integráció a Fabricben: kulcsfontosságú fejlemények a Data Agents számára 2026-ban

Eddig minden Fabric data agent API-hívásban delegált user token utazott: valakinek be kellett jelentkeznie, mielőtt az agent válaszolt. Demóban ez rendben van, telepített alkalmazásban viszont valódi akadály. A mostani preview-val a Fabric data agentek már service principal (SPN) hitelesítést is elfogadnak, és a termékcsapat saját közlése szerint ez volt az egyik leggyakrabban kért képesség azoktól az ügyfelektől, akik prototípusból éles rendszert csinálnának.

Papíron szűk funkció: egy új módja a token megszerzésének. A gyakorlatban azon múlik, beülhet-e egy data agent egyáltalán egy valódi alkalmazás mögé, ezért több figyelmet érdemel, mint amennyi egy átlagos preview-hírnek jut.

Mi változott valójában

A Fabric data agent olyan AI-agent, amely a Fabricben tárolt vállalati adatok felett kérdez le és következtet, akár Lakehouse-ban, akár Warehouse-ban, akár más támogatott forrásban él az adat. A workspace-ben építed meg, publikálod, és API-n keresztül hívod. A hitelesítés eddig szigorúan interaktív volt: az API delegált user tokent várt, vagyis minden hitelesítési folyamathoz kellett egy ember.

A service principal ezt a kényszert oldja fel. Alkalmazás-identitás a Microsoft Entra ID-ban, saját credential-ekkel és saját jogosultsági körrel, így egy backend-szolgáltatás a saját nevében hitelesíthet, ahelyett hogy egy ember session-jét kölcsönözné. A minta az Azure-ban régóta bevett; az újdonság, hogy mostantól a Fabric data agentek is elfogadják.

Miért törik el a user token élesben

Képzeljünk el egy tipikus középvállalati pénzügyi csapatot, amely belső chat-eszközt épít a költségadatai fölé. A prototípus annak a BI-fejlesztőnek a nevében hitelesít, aki összerakta, mert ez a legkisebb ellenállás útja, és elég meggyőzően működik ahhoz, hogy az emberek elkezdjenek rá támaszkodni. Aztán a fejlesztő szabadságra megy, vagy egy conditional access szabály a zárás harmadik napján újrabejelentkezést kényszerít ki, és az eszköz, amelyre már húszan számítanak, nem válaszol többet. A szokásos kerülőút egy megosztott „service user” fiók, ami még rosszabb: ember formájú identitás vaultban tárolt jelszóval, MFA-kivétellel, világos gazda nélkül, pontosan az, amit egy biztonsági átvilágítás kiszúr. Mire mindezt körbebástyáztad, a prototípus már egyáltalán nem olcsó.

Ezt a rést zárja most be a preview, ugyanazzal a mechanizmussal, amelyet az Azure többi része régóta használ.

Az alkalmazás-identitás mindkét gondot egyszerre kezeli. A jogosultságok arra szűkülnek, amire az alkalmazásnak ténylegesen szüksége van, nem arra, amije egy munkavállalónak éppen van; a biztonsági csapat pedig auditálható, alkalmazás-szintű identitást kap, amelyet ugyanúgy felügyelhet és monitorozhat, mint bármely más infrastruktúra-elemet.

A beállítás, és a részlet, amin érdemes megállni

Maga a folyamat rövid. Regisztrálsz egy alkalmazást a Microsoft Entra ID-ban, létrehozol hozzá egy service principalt, hozzáférést adsz neki a Fabric workspace-hez, a credential-jeivel access tokent kérsz, és ezzel a tokennel hívod a data agent API-t.

A harmadik lépésen érdemes megállni. A data agent a workspace jogosultságait örökli, külön agent-szintű engedély nincs: egyedül a workspace-jogosultság dönti el, mihez nyúlhat az alkalmazás-identitás. Ez kényelmes, ugyanakkor a workspace-t teszi meg biztonsági határnak, amitől a workspace-higiénia (mi milyen adat mellett él) rendezettségi kérdésből hozzáférés-kontroll kérdéssé válik.

Egy identitás, sok felhasználó

A bejelentés nem rejti véka alá a hozadékot: az alkalmazásod úgy szolgálhatja ki a végfelhasználóit, válaszolhat adatkérdésekre és működtethet beszélgetős felületeket, hogy közben egyiküknek sem kell közvetlen Fabric-hozzáférés. Terítés szempontjából pontosan ez kell. Egy controllernek, aki a költséghely-eltérésekre kérdez rá, ne kelljen Fabric-licenc és workspace-szerep ahhoz, hogy választ kapjon.

Kontrolling-szemmel viszont ugyanez a mondat veti fel az első kérdést bármilyen bevezetési checklisten: ha száz felhasználó ül egyetlen alkalmazás-identitás mögött, a felhasználónkénti biztonsági kontextus az alkalmazásnál véget ér. A Syngentánál végzett Fabric lakehouse-munkám erősen épít a row-level securityre és a felhasználó kilétéhez kötött hozzáférési szabályokra, egy megosztott alkalmazás-identitás viszont önmagában nem viszi le ezt a „ki”-t az adatig. A bejelentés ezzel nem foglalkozik, és nem is dolga, hiszen hitelesítési funkcióról szól. De mielőtt egy pénzügyi adatok feletti agent élesbe megy, valakinek el kell döntenie: vagy az agent teljes hatóköre biztonságos az alkalmazás minden felhasználójára nézve, vagy az alkalmazásréteg kényszeríti ki a saját korlátozásait, és bárhogy dönt, annak nyoma kell legyen egy auditban.

Foundry agentek és a lánc többi része

A bejelentés második forgatókönyve egy olyan mintát ír le, amellyel a Microsoft elmondása szerint gyakran találkozik: a beszélgetős élményt és az orchestration-logikát egy Microsoft Foundryben épített agent viszi, amelyhez knowledge source-ként Fabric data agent kapcsolódik, és ez adja a megalapozott válaszokat a vállalati adatokból. Fejlesztés közben ez user-bejelentkezéssel is jól működik. Az élesítésnél szokott elakadni, mert egy éles alkalmazás nem kérhet minden egyes requesthez felhasználói bejelentkezést.

Az SPN-támogatással a lánc végig zárt: az éles alkalmazás (custom app vagy Azure Web App) a service principallal hitelesít, meghívja a Foundry agentet, az pedig a principal access tokenjével hívja a Fabric data agentet; a válasz ugyanezen a láncon megy vissza. A bejelentés hozzáteszi, hogy az Azure Web App ezt natívan támogatja, a credential-életciklust az Azure kezeli, így kézzel rotálandó secret sincs.

Miután a Morgan Stanley-nél részt vettem egy cégszintű RAG-megoldás tervezésében és tesztelésében, az a tartós benyomásom, hogy ez a látványmentes csővezeték-munka, ki mit hív és kinek a nevében, több naptári időt visz el, mint bármi, ami magával a modellel kapcsolatos. Egy működő prototípus egy hétvége; egy identitás-történet, amire a compliance is rábólint, az maga a projekt.

Hol olvashatók a részletek

A data agentekkel kísérletező pénzügyi és BI-csapatok számára a gyakorlati tanulság az, hogy elfogyott a fő szerkezeti kifogás, amiért egy agent prototípus-státuszban ragadhat. Ami marad, az governance-munka: a workspace hatókörének meghúzása, a felhasználói szintű korlátozások helyének eldöntése, az identitás audit-célú dokumentálása. Ebben pedig a pénzügyi csapatok jobbak, mint hinnék magukról.

A teljes írás, a Service Principal Support for Data Agents in Fabric (Preview) a Fabric Updates Blogon, mindkét forgatókönyvet végigveszi a hitelesítési folyamatokkal együtt, és linkeli a lépésről lépésre szóló beállítási dokumentációt. Még egy megjegyzés a posztból: ha a data agented KQL database-hez kapcsolódik, arra az útvonalra az SPN-támogatás még nincs benne ebben a preview-ban, a poszt szerint hamarosan érkezik.