Az AI-ügynökök identitások: least privilege nem emberi felhasználóknak

Két évig a legtöbb csapat az AI-ügynököt egy alkalmazás funkciójaként kezelte. Azzal a hitelesítő adattal hívta az eszközöket, amelyik éppen kéznél volt: a fejlesztő személyes access tokenjével, egy megosztott service accounttal, egy környezeti változóban lévő API-kulccsal. Demóban ez működött. Az első audit-kérdést nem éli túl, és az mindig ugyanaz: ki tette ezt, és ki engedélyezte?

Az az ügynök, amely leveleket olvas, jegyeket nyit vagy rekordokat módosít, a rendszereid felhasználója, csak nagyon gyors és nagyon szó szerinti. Ez a cikk az ügynököket identitásként kezeli, és végigmegy a belőle következő döntéseken: delegált vagy saját hitelesítő adatok, OAuth token exchange, rövid életű, szűk hatókörű tokenek, secretek, audit és offboarding. Azt is ellenőriztem, mit szállítanak ténylegesen a gyártók 2026 októberében, mert több bejelentésből nyáron általánosan elérhető termék lett.

Miért kell az ügynöknek saját identitás

Az alkalmazásidentitásokat olyan szolgáltatásokra tervezték, amelyeket emberek építenek, elneveznek és évekig üzemeltetnek. Az emberi identitások jelszóval, MFA-val és főnökkel járnak. Az ügynök egyik sem. A Microsoft dokumentációja olyan ügynököket ír le, amelyek percekig élnek, vagy naponta ezerszer jönnek létre és szűnnek meg, és megnevezi a problémákat, amelyeket egy ügynökidentitásnak meg kell oldania: megkülönböztetni az ügynökök műveleteit a munkavállalókétól, ügyfelekétől és workloadokétól, megfelelően méretezett hozzáférést adni, távol tartani az ügynököket a legkritikusabb szerepköröktől, és skálázódni nagy, rövid életű flottákra.

A gyakorlati érv egyszerűbb. Saját identitás nélkül három kérdésre nem tudsz válaszolni: mit ér el ez az ügynök, mit tett, és hogyan állítom le egy kolléga fiókjának megsértése nélkül? A megosztott token mindháromnál megbukik. Ha az ügynök ráadásul nem megbízható tartalmat olvas, mint a legtöbb hasznos ügynök, a jogai határozzák meg egy sikeres prompt injection kárkörét (lásd a lethal trifecta mintáit). Az identitás az a hely, ahová ezt a korlátot felakasztod.

Delegált vagy saját hitelesítő adatok: feladatonként válassz

Az ügynök háromféleképpen hitelesíthet, és ebből csak kettő jó. Az Entra Agent ID név szerint megnevezi a jókat: az autonóm hozzáférést, amely az ügynökidentitásnak közvetlenül adott jogokat használ, és a delegált hozzáférést, amikor az ügynök egy ember nevében, a felhasználónak adott jogokkal jár el, és a felhasználó ellenőrzi, mi delegálódik.

A szabályom: ha a munka valakinek szól, például „foglald össze a postafiókomat” vagy „készítsd elő az ajánlatomat”, delegált hozzáférést használj, hogy az ügynök örökölje az illető korlátait, és a meglévő hozzáférési szabályaid tovább működjenek. Ha a munkát az ügynök végzi szerepként, például éjszakai egyeztetést vagy support triázs-sort, adj neki saját identitást a legkisebb alkalmazásszintű jogokkal, amelyeket meg tudsz védeni. A Microsoft best practice útmutatója ugyanezt mondja: client credentials csak a szükséges alkalmazásjogokkal az autonóm ügynököknél, on-behalf-of az interaktívaknál, és ne legyen alkalmazásjog ott, ahol a delegált is elég.

Egy következmény könnyen elsiklik. A delegált tokent a felhasználó korlátozza, a felhasználó pedig gyakran adminisztrátor. A delegáció nem segít, ha a mögötte álló személy túlprivilegizált, ezért az ügynök saját scope-ját is le kell fedni, és a tényleges jogok a kettő metszete.

A delegált tokenfolyamat

A szabványos mechanizmus az OAuth 2.0 Token Exchange, RFC 8693. A kliens elküld egy subject tokent (kinek szól a kérés) és opcionálisan egy actor tokent (ki jár el), a kívánt audience-szel és scope-pal együtt. Actor token nélkül impersonation jön létre: az ügynök egyszerűen a felhasználóvá válik, és senki sem tudja megkülönböztetni őket. Actor tokennel delegáció jön létre: az ügynök megtartja saját identitását, az új token pedig rögzíti, hogy a felhasználó nevében jár el.

A 3. és 4. lépésben az identity provider a szabályzati pont. Megtagadhatja a cserét, ha az ügynök tiltott, a felhasználó nem járult hozzá, vagy a kért scope szélesebb a megengedettnél, és rövid élettartamot állíthat be. Mivel az új token audience-e az API, egy kiszivárgott másolat máshol használhatatlan. Az act claim ezután eljut az erőforrásszerverhez és annak logjaiba, ettől különböztethető meg később, hogy „a felhasználó tette” és hogy „az ügynök tette a felhasználóért”.

Ismerd a szabvány határait. Az RFC 8693 megengedi az act claimek egymásba ágyazását a szereplők láncának leírására, de a fogadónak csak a legfelső szintű claimekben szabad bíznia, a korábbi szereplők csak tájékoztató jellegűek. Semmi nem kényszeríti, hogy a jogosultságok minden ugrásnál szűkülnek. A WorkOS ezt multi-hop delegációs problémaként írja le, és gyengítő tokenekről és ellenőrizhető actor-láncokról szóló piszkozatokra mutat. Amíg ezek nem érnek be, tartsd rövidre a láncokat, szűkítsd a scope-ot minden cserénél, és egészítsd ki eszközhíváskor végzett szabályzat-ellenőrzéssel ahelyett, hogy csak a token érvényességére hagyatkoznál.

Ugyanennek az ötletnek a vállalati változata a Cross App Access. A felhasználó belép a vállalati identity providerbe, amely Identity Assertion JWT Authorization Grantet (ID-JAG) állít ki; a kliens ezt a célszolgáltatás authorization serverénél cseréli access tokenre. Az adminok egyszer engednek egy szervert, a felhasználók pedig a meglévő csoportjaik és szerepköreik keretében öröklik, szerverenkénti hozzájárulási képernyők nélkül. Az MCP projekt 2026. június 18-án fogadta el Enterprise-Managed Authorization kiterjesztésként.

Secretek: a legjobb hitelesítő adat az, amit nem tárolsz

Az ügynöknek kétféle secretje van: az a hitelesítő adat, amellyel bizonyítja, kicsoda, és azok a harmadik féltől kapott tokenek, amelyekkel más rendszerekben cselekszik. Mindkettő vonzó célpont, mert az ügynökök kódot futtatnak, nem megbízható bemenetet olvasnak és logokat írnak. Ezeket a szabályokat alkalmaznám.

• Élesben nincs statikus kulcs. Az Entra útmutatója a föderált identity credentialeket (managed identity) vagy tanúsítványokat részesíti előnyben a kliens secretekkel szemben, secretet csak fejlesztéshez javasol, és legalább évenkénti tanúsítványcserét. Az Okta Agent SSO is rövid életű, identitás által irányított tokeneket ad ki statikus API-kulcsok helyett.
• Tartsd a hitelesítő adatokat a modell elérésén kívül. Az ügynökfolyamat sidecartól, vaulttól vagy brokertől kér tokent; a modell sosem látja a secretet a promptban, az eszközargumentumokban vagy az eszközeredményekben. Az Entra erre a mintára Auth SDK-t kínál sidecarként, AWS Bedrockon vagy n8n-en futó ügynökökhöz is.
• Blueprintenként és környezetenként egy hitelesítő adat. Ne oszd meg ugyanazt az adatot egymáshoz nem tartozó ügynökök között, és válaszd szét a dev, test és prod környezetet, hogy egy kompromittálódás helyi maradjon.
• A harmadik féltől kapott tokeneket token vaultban tartsd, ügyfelenként vagy tenantonként, és csak korlátozott, naplózott hívással add át az ügynöknek. Az Auth0 Organizations-támogatású Token Vaultot jelentett be többbérlős SaaS-hoz.
• Tisztítsd a logokat és a trace-eket. A tokenek debug logokon, hibaüzeneteken és observability-csővezetékeken szivárognak ki; töröld az authorization headereket, mielőtt elhagyják a folyamatot. A futtatási oldalhoz lásd a sandboxing ellenőrzőlistát.

A rövid élettartam fontosabb az okos tárolásnál. A gyorsan lejáró token a szivárgást incidensből lábjegyzetté szelídíti, és az MCP útmutató scope-minimalizálási tanácsa közvetlenül érvényes: kis kockázatú olvasási scope-okkal indulj, és csak privilegizált művelet kísérletekor emeld, ahelyett, hogy előre minden scope-ot közzétennél.

Mit szállítanak a gyártók 2026 októberében

A gyártói dokumentációk és bejelentések alapján ellenőrizve ez a jelenlegi kép. Gyorsan mozgó terület, ezért bármelyik sorra tervezel, előtte ellenőrizd a dátumokat és a licenceket.

Két megfigyelés. Először: a protokollok gyorsabban közelítettek egymáshoz, mint vártam: az Entra, az Okta és az MCP projekt ugyanazt az alakzatot írja le, vagyis könyvtári identitást az ügynöknek, tokenkiadást az identity providernél és rövid életű, szűk hatókörű tokent az erőforrásnál. Másodszor: a kereskedelmi határ valódi. A Microsoft elválasztja az identitásplatformot a governance-funkcióktól, az Okta pedig az egyszeri bejelentkezést az életciklus-governance-tól. Tervezz költségvetést a governance rétegre, mert az identitás review és életciklus nélkül csak egy másik hely az ügynökök elfelejtésére. Egy külön cikkben írtam arról, miért teszik az OpenAI dotjai az ügynökök governance-át identitáskérdéssé.

Audit és offboarding

Tegyél minden műveletet visszakövethetővé

A naplózás csak akkor hasznos, ha a log meg tudja különböztetni az ügynököket az emberektől, és meg tudja nevezni a delegált művelet mögötti embert. Az Entra az audit eseményeket ügynöktípussal (blueprint, ügynökidentitás vagy agent user fiók) és blueprint-azonosítóval jelöli, és külön agent sign-in eseménytípust ad. Mivel az ügynökök delegált vagy csak alkalmazásszintű jogokkal is beléphetnek, a belépéseik mind a négy sign-in logtípusban megjelennek, ezért az ügynöktípusra szűrj, ne egyetlen logra.

• Delegált hívásnál minden esetben naplózd a subjectet és az actort, autonómnál csak az ügynökidentitást.
• Riasztást állíts be a hitelesítőadat-változásokra, az új jogosultság-megadásokra, az ismeretlen helyről érkező belépésekre és a telepítési csővezetéken kívüli változásokra.
• Kösd össze az ügynökidentitást a trace-ekben lévő run ID-val, hogy végig vissza tudd játszani, mit tett egy identitás egy egész ügynökciklus alatt.
• Tartsd meg a logokat a megfelelőségi rendszered által megkívánt ideig; az ügynöklogok nagy forgalmúak, ezért exportáld őket archívumba.

Az ügynököket úgy offboardold, mint a munkatársakat

Az ügynököket könnyű létrehozni és ugyanilyen könnyű elfelejteni. Az Entra modellje megmutatja, milyen egy jó életciklus. Minden blueprintnek és ügynökidentitásnak kell szponzor, az a személy vagy csoport, aki a céljáért felel, plusz egy technikai owner. Az életciklus-munkafolyamatok értesíthetik a társszponzorokat, és automatikusan átadhatják a szponzorságot, ha a szponzor szerepet vált vagy távozik, hogy megelőzzék az árva ügynököket. A Microsoft azt javasolja, hogy a szponzorok 6–12 havonta igazolják, hogy az ügynökre még szükség van, és negyedévente vizsgáld át a hiányzó szponzorokat és a nemrég aktivitás nélküli ügynököket.

Leállításkor válaszd szét a letiltást és a törlést. Egy blueprint letiltása azonnal megállítja az összes ügynökidentitás hitelesítését, ezért kikapcsolóként működik, és érintetlenül hagyja a bizonyítékokat. A törlés soft delete-tel törli az objektumot, aszinkron módon pedig az alárendelt identitásait; a takarítás órákat vagy napokat késhet, az objektumok 30 napig visszaállíthatók. Vészhelyzetben ne a törlésre hagyatkozz; előbb tiltsd le. Utána jön az, amit semmilyen könyvtár nem végez el helyetted: vond vissza az ügynök harmadik fél rendszereiben tartott tokenjeit, töröld a secretjeit és a vaultbeli bejegyzéseit, és zárd le a külső szolgáltatásokhoz fűződő kapcsolatait.

Kontroll-ellenőrzőlista

Használd ezt a táblázatot tervezési review-kon. Minden kontrollhoz tartozik egy konkrét teszt; ha egy sorhoz nem tudsz bizonyítékot mutatni, tekintsd nyitottnak.

Két sor gyakorlatot érdemel dokumentum helyett: a megtagadott scope tesztje és a letiltási eljárás. Kérd meg az ügynököt, hogy tegyen valamit a hatókörén kívül, és ellenőrizd, hogy elbukik, és a bukás naplózódik. Aztán tégy úgy, mintha kompromittálódott volna, és mérd meg, mennyi idő alatt vágod el az összes hitelesítő adatát, amit birtokol.

Mit tennék először

A kezdéshez nem kell platformvásárlás. Sorrendben:

1. Leltározd fel az összes ügynököt és automatizálást, amely ma hívja a rendszereidet, és jelöld meg, melyik használ személyes tokent vagy megosztott kulcsot.
2. Adj minden ügynöknek egyedi identitást és szponzort, azokkal kezdve, amelyek ügyféladatot vagy pénzt érintenek.
3. Döntsd el ügynökönként, hogy delegált vagy autonóm, és vágd a scope-okat a feladat igényére; teszteld, hogy a hatókörön kívüli hívás elbukik.
4. Térj át a token exchange-re és rövid életű tokenekre az identity providerednél; távolítsd el a statikus kulcsokat az éles környezetből és a promptokból.
5. Írd meg a letiltás és visszavonás runbookot, gyakorold egyszer, és ütemezd a negyedéves árva-review-t.

Az ügynökidentitás nem látványos, de ez az a kontroll, amely mindent másat kikényszeríthetővé tesz: a sandboxing azt korlátozza, mit tehet a kód, az identitás pedig azt, mit érhet el az ügynök, és kit vonhatsz felelősségre.

Források

1. Microsoft Learn: What is Microsoft Entra Agent ID?
2. Microsoft Learn: What are agent identities?
3. Microsoft Learn: Best practices for Microsoft Entra Agent ID
4. Microsoft Learn: Microsoft Entra Agent ID logs
5. Microsoft Learn: How agent identity deletion works
6. Microsoft Learn: What's new in Microsoft Entra Agent ID
7. Microsoft Learn: Microsoft Agent 365 overview
8. Okta: Okta brings first-class identity to AI agents with Agent SSO (24 August 2026)
9. Okta: Auth0 gives developers the identity layer to securely ship agentic apps (May 2026)
10. IETF: RFC 8693, OAuth 2.0 Token Exchange
11. Model Context Protocol blog: Enterprise-Managed Authorization, zero-touch OAuth for MCP (18 June 2026)
12. Model Context Protocol: Security best practices
13. WorkOS: AI agents and the multi-hop delegation problem
14. TechCrunch: OpenAI launches Dots, its bubbly agentic avatar