> Adj minden AI-ügynöknek saját identitást, delegált tokent és kikapcsolót. Token exchange, secretek, audit, offboarding, és mit kínál az Entra, az Okta és az Auth0. > > Web page: https://balazscsorba.com/hu/blog/ai-agent-identity-least-privilege · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/ai-agent-identity-least-privilege.md) · [Deutsch](https://balazscsorba.com/de/blog/ai-agent-identity-least-privilege.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: AI agent identity management, non-human identity AI agents, AI agent least privilege, OAuth token exchange for AI agents, on-behalf-of flow AI agent, Microsoft Entra Agent ID, Okta Agent SSO Cross App Access, AI agent credentials and secrets, offboarding AI agents, delegated vs autonomous agent access [Blog](https://balazscsorba.com/hu/blog)/Biztonság és megfelelés # Az AI-ügynökök identitások: least privilege nem emberi felhasználóknak Adj minden AI-ügynöknek saját identitást, delegált tokent és kikapcsolót. Token exchange, secretek, audit, offboarding, és mit kínál az Entra, az Okta és az Auth0. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·12 perc olvasás - AI agent identity - Least privilege - OAuth token exchange - Non-human identity ![Diagram: egy felhasználó, egy saját identitású ügynök és egy identity provider, amely rövid életű, szűk hatókörű tokent állít ki egy API-hoz.](https://balazscsorba.com/images/blog/ai-agent-identity-least-privilege/cover.webp?v=02eaaf068e) ## A lényeg röviden - Az az ügynök, amely cselekszik, a rendszereid felhasználója. Adj neki saját identitást, névvel ismert emberi szponzort és életciklust, ne más belépési adatainak másolatát vagy megosztott API-kulcsot. - Feladatonként válassz a delegált hozzáférés (az ügynök egy személy nevében jár el, annak jogain belül) és az autonóm hozzáférés (az ügynök saját, minimális jogokkal dolgozik) között. Soha ne keverd a kettőt egy tokenben. - Az OAuth token exchange (RFC 8693) a szabványos építőelem: a felhasználó tokenjét és az ügynök identitását rövid életű, szűk audience-ű és scope-ú tokenre cseréled, amely sub-ot és act-ot is rögzít. - 2026-ban az eszközök megvannak: Microsoft Entra Agent ID és Agent 365 (GA május 1.), Okta Agent SSO (GA augusztus 24.) Cross App Accessszel az MCP-ben, és az Auth0 for AI Agents. A protokollok szabványosak, a governance továbbra is a te dolgod. - Az offboarding a leggyengébb láncszem: előbb tiltsd le, később töröld, add át a szponzorságot, ha valaki távozik, és rendszeresen vizsgáld felül az ügynököket, hogy egy árva se tartsa meg a hozzáférését. Ezen az oldalon 1. [Miért kell az ügynöknek saját identitás](https://balazscsorba.com/#why-identity) 2. [Delegált vagy saját hitelesítő adatok: feladatonként válassz](https://balazscsorba.com/#delegated-or-own) 3. [A delegált tokenfolyamat](https://balazscsorba.com/#token-flow) 4. [Secretek: a legjobb hitelesítő adat az, amit nem tárolsz](https://balazscsorba.com/#secrets) 5. [Mit szállítanak a gyártók 2026 októberében](https://balazscsorba.com/#vendors) 6. [Audit és offboarding](https://balazscsorba.com/#audit-offboarding) 7. [Kontroll-ellenőrzőlista](https://balazscsorba.com/#checklist) 8. [Mit tennék először](https://balazscsorba.com/#what-to-do) 9. [Források](https://balazscsorba.com/#sources) 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](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns)). 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. Minta Kit lát az API Erősség Hibamód **Kölcsönvett belépés vagy megosztott kulcs** (antipattern) A személyt vagy egy megosztott fiókot, soha az ügynököt Gyorsan megépíthető Nincs elszámoltathatóság, nincs ügynökönkénti visszavonás, a jogok messze túllépik a feladatot **Delegált (felhasználó nevében)** A felhasználót, az ügynök actorként rögzítve Az ügynök sosem haladhatja meg a felhasználót; a hozzájárulás és a felhasználói szabályok érvényesek Felhasználót igényel a körben; a hosszú futású feladatok túlélik a felhasználói sessiont **Autonóm (saját identitás)** Magát az ügynököt Ütemezésre és eseményekre illik; a jogok explicitek és átvizsgálhatók A túl széles alkalmazásjogosultságot könnyű megadni és nehéz észrevenni 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. Az API sosem látja a felhasználó eredeti tokenjét vagy az ügynök hosszú életű hitelesítő adatát, csak egy neki kiállított tokent. 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”. **Soha ne add tovább a bejövő tokent** Ha az ügynököd MCP-szervert vagy belső eszközszervert hív, annak a szervernek csak a neki kiállított tokeneket szabad elfogadnia, és nem szabad továbbítania őket. Az MCP biztonsági útmutatója a token passthrough-t antipatternnek nevezi, és kimondja, hogy a szerverek nem fogadhatnak el (MUST NOT) olyan tokent, amelyet nem kifejezetten nekik állítottak ki, mert ez áttöri az audience-határokat, megkerüli a rate limiteket és a monitoringot, és rontja az audit nyomvonalat. Cserélj, ne továbbíts. Lásd még az [MCP-szerver biztonsági ellenőrzőlistámat](https://balazscsorba.com/hu/blog/mcp-server-security-checklist). 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](https://balazscsorba.com/hu/blog/sandboxing-coding-agents-ci-checklist). 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. Ajánlat Mit kapsz Állapot és fenntartások **Microsoft Entra Agent ID** Agent identity blueprintek (sablonok) és ügynökidentitások, opcionális párosított agent user fiókok, ownerek és szponzorok, OAuth autonóm és on-behalf-of folyamatokkal, sign-in és audit logok; nem Microsoft ügynökökkel is működik sidecaron vagy workload identity federationön át Általánosan elérhető, minden Entra-ügyfélnek. Az Entra biztonsági funkcióinak (például Conditional Access) kiterjesztése az ügynökökre Agent 365-öt igényel **Microsoft Agent 365** Központi ügynök-registry és -térkép, életciklus- és hozzáférés-governance az Entrával és a Purview-val, Defender-védelem GA 2026. május 1-jén a Commercial szegmensben, felhasználónkénti licenc; a Microsoft 365 E7 tartalmazza, E5-höz és másokhoz kiegészítő **Okta Agent SSO és Okta for AI Agents** A Cross App Accesst támogató ügynökök bekerülnek a Universal Directorybe és rövid életű tokent kapnak; a külön termék discoveryt, életciklust, tanúsítási felülvizsgálatot, jóváhagyási munkafolyamatokat és deaktiválást ad, Cross App Access nélküli ügynökökre is Agent SSO GA 2026. augusztus 24-én, az Okta SSO alapjában felár nélkül; az Okta for AI Agents külön előfizetés **Auth0 for AI Agents** Auth for MCP, On-Behalf-Of Token Exchange, Token Vault, finomszemcsés engedélyezés Az Auth for MCP-t és az OBO token exchange-et 2026 májusában jelentették be GA-ként. Az „Agent as Principal” funkciót júniusra developer previewként jelezték; a jelenlegi állapotát nem tudtam ellenőrizni **MCP Enterprise-Managed Authorization** IdP által vezérelt engedélyezés MCP-szerverekhez ID-JAG-gel; kliensek, például a Claude és a VS Code, szerverek, például az Asana, az Atlassian, a Figma, a Linear és a Supabase 2026 júniusa óta hivatalos MCP-kiterjesztés; kliens- és szerveroldali támogatást is igényel **OpenAI specialist dotok** Dotok, amelyek meglévő rendszereken át külön identitással, hitelesítő adatokkal és eszközökkel láthatók el; az OpenAI saját állítása szerint a Microsofttal dolgozik Agent 365-kontrollokon 2026\. szeptember 29-én vállalati pilotként jelentették be; a bejelentésen túli részletek az ellenőrzésemkor nem voltak nyilvánosak 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](https://balazscsorba.com/hu/blog/openai-dots-always-on-agents-impact) 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](https://balazscsorba.com/hu/blog/agent-loop-explained) 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. Kontroll Így néz ki a jó Bizonyíték **Egyedi identitás** Ügynökönként egy identitás, nincs megosztott fiók, nincs személyes token Az ügynökök könyvtári listája ownerekkel **Szponzor és owner** Névvel ismert felelős személy vagy csoport, távozáskor átadva Szponzor mező, életciklus-munkafolyamat futása **Hozzáférési mód kiválasztva** Delegált a személynek végzett munkához, autonóm a szerepekhez; sosem mindkettő egy tokenben Tervezési jegyzet ügynökönként **Token exchange** Audience-re korlátozott tokenek rögzített actorral; nincs token passthrough Token claimek egy teszt trace-ben **Least privilege** Legszűkebb scope-ok, step-up kockázatos műveletekhez, a tényleges jogokat az ügynök és a felhasználó is lefedi Jogosultság-review, megtagadott scope tesztje **Rövid élettartam** Percnyi nagyságrendű access tokenek, nincs statikus éles kulcs Token-konfiguráció, kulcsleltár **Secretkezelés** Managed vagy föderált hitelesítő adatok, vault vagy sidecar, semmi a promptokban vagy logokban Secret-szkennelés promptokon, trace-eken és logokon **Szabályzat a kapuban** Ügynökspecifikus conditional access, kockázatalapú tiltás, eszközszintű ellenőrzések Szabályzat-export, blokkolt belépés tesztje **Audit nyomvonal** Ügynöktípus, blueprint, subject és actor a logokban; riasztások beállítva Példa-vizsgálat végigjátszva **Review és offboarding** Szponzori igazolás, árva-review, letesztelt letiltás és tokenvisszavonás Utolsó review dátuma, a gyakorlat eredménye 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?](https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id) 2. [Microsoft Learn: What are agent identities?](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities) 3. [Microsoft Learn: Best practices for Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/best-practices-agent-id) 4. [Microsoft Learn: Microsoft Entra Agent ID logs](https://learn.microsoft.com/en-us/entra/agent-id/sign-in-audit-logs-agents) 5. [Microsoft Learn: How agent identity deletion works](https://learn.microsoft.com/en-us/entra/agent-id/concept-agent-identity-deletion) 6. [Microsoft Learn: What's new in Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id) 7. [Microsoft Learn: Microsoft Agent 365 overview](https://learn.microsoft.com/en-us/microsoft-agent-365/overview) 8. [Okta: Okta brings first-class identity to AI agents with Agent SSO (24 August 2026)](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) 9. [Okta: Auth0 gives developers the identity layer to securely ship agentic apps (May 2026)](https://www.okta.com/newsroom/articles/auth0-may-2026-product-innovations/) 10. [IETF: RFC 8693, OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693) 11. [Model Context Protocol blog: Enterprise-Managed Authorization, zero-touch OAuth for MCP (18 June 2026)](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) 12. [Model Context Protocol: Security best practices](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices) 13. [WorkOS: AI agents and the multi-hop delegation problem](https://workos.com/blog/oauth-multi-hop-delegation-ai-agents) 14. [TechCrunch: OpenAI launches Dots, its bubbly agentic avatar](https://techcrunch.com/2026/09/29/openai-launches-dots-its-bubbly-agentic-avatar/) ## Gyakori kérdések Mi az a non-human identity egy AI-ügynöknél? Saját fiók, amellyel a szoftverügynök azonosítja magát a rendszereknél ahelyett, hogy egy személy belépését vagy megosztott kulcsot kölcsönvenne. A Microsoft Entra Agent ID például úgy írja le az ügynökidentitásokat, mint olyan identitásfiókokat, amelyek egyedi azonosítást és hitelesítést adnak az AI-ügynököknek, elkülönítve a munkavállalói, ügyfél- és workload-identitásoktól. A felhasználó vagy az ügynök saját hitelesítő adatait használja egy AI-ügynök? Delegált hozzáférést használj, ha az ügynök egy adott személynek végez munkát, és sosem léphet túl annak jogain; az ügynök saját identitását, ha ütemezve vagy eseményre autonóm módon fut. Mindkét esetben az ügynöknek azonosíthatónak kell lennie a logokban, és a tokenjének csak a feladathoz szükséges scope-okat szabad hordoznia. A felhasználó jelszavának vagy egy hosszú életű személyes tokennek a megosztása az, amit kerülnöd kell. Mi az az OAuth token exchange, és miért fontos az ügynököknél? Az RFC 8693 olyan grantet definiál, amelyben a kliens egy már meglévő tokent mutat fel, és másik audience-ű vagy szűkebb scope-ú tokent kap. Actor tokennel delegációt fejez ki: az új token az act claimen keresztül azt mondja, hogy az ügynök a felhasználó nevében jár el. Így a lefelé hívott API-k és az audit logok mindkét identitást látják. Hogyan tároljam az AI-ügynökök secretjeit? Lehetőleg sehogy: részesítsd előnyben a managed identity-ket vagy a workload identity federationt, adj ki rövid életű tokeneket, és a hitelesítő adatokat vaultban vagy sidecarban tartsd, ne promptokban, környezeti dumpokban vagy logokban. A Microsoft best practice-ei élesben föderált credentialeket vagy tanúsítványokat javasolnak, kliens secretet csak fejlesztéshez. Hogyan állítsak le biztonságosan egy AI-ügynököt? Előbb tiltsd le az identitását, mert ez azonnal blokkolja a hitelesítést és megőrzi a bizonyítékokat, és csak átvizsgálás után töröld. Az Entrában egy blueprint letiltása az összes belőle létrehozott ügynököt blokkolja, a törölt ügynökidentitások pedig 30 napig visszaállíthatók. Vond vissza az ügynök harmadik féltől kapott tokenjeit is, töröld a secretjeit, és add át vagy szüntesd meg a szponzorát. Megoldja-e az ügynökidentitás kérdését az Entra Agent ID, az Okta és az Auth0? A vezetékelést megoldják: identitások, tokenkiadás, szabályzatok, logok és életciklus-munkafolyamatok. Azt nem döntik el, mennyi hozzáférést kapjon egy ügynök, ki felel érte, vagy mi történik, ha rosszindulatú dokumentumot olvas. Ezek a döntések nálad maradnak, ezért a kontroll-ellenőrzőlista többet számít, mint a szállító megválasztása. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [PII-kitakarás LLM-pipeline-okban: hol, hogyan, és mit mond a GDPR](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines) - [EU AI Act az 50. cikken túl: GPAI, magas kockázatú határidők, teendők](https://balazscsorba.com/hu/blog/eu-ai-act-gpai-high-risk-2026) - [Prompt injection elleni védelem: a lethal trifecta és hat tervezési minta](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns) - [MCP biztonsági ellenőrzőlista: tool poisoning, rug pull és OAuth](https://balazscsorba.com/hu/blog/mcp-server-security-checklist) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)