Az elmúlt évben a szerző körülbelül két tucat vállalati agent-architektúrát vizsgált meg bankok, kiskereskedők, egészségügyi rendszerek és szabályozó szervezetek között. A rendszerdobozok — MCP gateway, tool registry, vector store, orchestrator, policy engine és observability stack — szép rendben megvoltak, és a komponensek közötti hívások, kontextusmegosztás, illetve eszközmeghívások is fel voltak tüntetve. A diagramok 2026-os mércével nézve már elvárható kiépítettséget mutatnak. Ami viszont rendszeresen hiányzik, az az, hogy ki az azonosított szereplő (principal), kit képvisel az ügynök és ki vállalja a felelősséget, ha hibázik.
Ennek a hiányosságnak van egy gyűjtőneve: principal drift — az a folyamat, amelyben egy elég nagy rendszeren belül fokozatosan elszakad egymástól az a humán jogosultság, amelyhez egy bejegyzett műveletnek kötődnie kellene, és maga az a végrehajtó entitás, amely ténylegesen végrehajtotta a műveletet. Az identitás először omlik össze, mert a napló csak generikus szolgáltatási principalt rögzít. Ezt követi az autoritás eróziója: ha nincs stabil principal, ahová a szabályok köthetők, nem lehet megbízhatóan korlátozni, mit tehet az ügynök. Végül a felelősség is feloldódik: az incidensköltséget az viseli, akinek a tárgyalási helyzete a gyengébb a vizsgálat végén.
A hanyatlás menete egy egyszerű példán
Vegyünk egy rutinszerű visszatérítési (refund) ügynököt. Egy ügyfélszolgálati munkatárs csevegés közben arra kéri az ügynököt, hogy dolgozzon fel egy 48 dolláros visszatérítést. Az ügynök ellenőrzi az jogosultságot, végrehajtja a visszatérítést és naplózza a lépést. Az audit bejegyzés valószínűleg olyasmit mutat: refund-agent-prod-03, futtatva a customer-service platform csapat által birtokolt service principal alatt. Ez igaz, de félrevezető. Valójában az ügynök a munkatárs nevében és az ügyfél érdekében járt el, egy delegációs láncon keresztül, amelyet nem rögzítettek.
Egy jól tervezett rendszerben az ügyfél, a munkatárs, az ügynök identitása és a service principal együtt szerepelnek, lekérdezhető láncként és a munkameneten túl is tartósan elérhetők. A legtöbb gyakorlatban használt rendszerben ez nincs meg; az identitás összeomlik egy generikus szolgáltatási principalre, és nincs többé egyértelmű „ki”, amihez bármi más köthető lenne.
Autoritáshiány: a lehetőség és a korlátozás elválása
Következő lépésként az autoritás erodálódik. A refund ügynöknek van egy issue_refund eszköze, amely technikailag bármilyen rendelés visszatérítésére képes. Az engedélynek azonban szűkebbnek kellene lennie (pl. visszatérítések 200 dollárig, 90 napnál nem régebbi rendelések, jó állapotú ügyfelek, 50 dollár fölött automatikus eskálázás). Ez a jogosultság viszont gyakran egy promptban, YAML fájlban vagy egy Notion-oldalon él — olyan helyen, amelyet a csapat utoljára egy más szabályrendszer idején frissített.
A runtime érvényesítheti a képességet (capability), de nem feltétlenül az autoritást (authority). Ha rossz bemenet vagy összezavarodott gondolatmenet miatt az ügynök tévesen 1 800 dollárt utal egy másik ügyfélnek, utólag nincs tiszta válasz arra, hogy „ki hagyta jóvá ezt a szabályt?”, mert maga a szabály soha nem vált hivatalos, hitelesített tárggyá. Magasabb tételnél ugyanez sokkal súlyosabb: egy kódolási ügynök, amely merge hozzáféréssel rendelkezik védett branch-hez, egy kommentbe épített prompttal kaphat utasítást „konfigurációs értékeket naplózni hibakereséshez”, és titkokat juttathat ki egy külső monitoring szolgáltatásnak — és senki nem fogja látni, hogy miért történt.
Felelősség feloldódása
Az incidens után a felek könnyen egymásra mutogatnak: a fejlesztőcsapat azt mondja, követte a politikát; a politika szerzői azt, hogy nem számítottak az adott bemenetre; a platformcsapat pedig azt, hogy az ügynök egy service principal alatt futott, amelynek viselkedését ők nem birtokolják. Az audit napló rögzítheti a műveletet, de nem rögzíti a döntést előidéző gondolatmenetet, a lekért kontextust vagy a prompttörténetet, amely alakította a döntést. Az utólagos vizsgálat régészetivé válik, és végül az fizeti a költséget, akinek a tárgyalási helyzete a leggyengébb.
Miért nem elég az IAM és a megszokott szabályozás?
Vannak IAM rendszerek, identity governance, policy-as-code, audit trail-ek és SIEM-ek — több évtizedes megfelelőségi gyakorlat. De ezek az eszközök olyan feltételezésekre épülnek, amelyeket az ügynökök rendszeresen megszegnek. Az IAM és IGA emberi időskálákra számít: emberek felvesznek, távoznak, szolgáltatásfiókok negyedévente rotálódnak. Az ügynökök viszont munkamenetenként jönnek létre, láncokba komponálódnak (egy ügynök hív egy másikat, amely tovább hív egy harmadikat), és gyakran delegált tokeneken keresztül utánozzák a felhasználókat — olyan láncot, amelyet a hagyományos IGA nem képes megfelelően reprezentálni.
A policy engine-ek az API, adatbázis és hálózati végpont pillanatában érvényesítenek. Az ügynökök legfontosabb döntéseit viszont azelőtt hozzák, hogy elérnék ezeket az ellenőrzési pontokat: a gondolkodási lépésben dől el, melyik eszközt hívják meg és milyen paraméterekkel. A kiforrott audit naplók abból indulnak ki, hogy a bemenetek visszajátszása reprodukálja a kimenetet; ügynököknél a prompt és a lekérés visszajátszása más eredményt adhat, mert a model maga is állapotot ad hozzá, amit a napló nem rögzített.
Vannak eszközök — de önmagukban nem elegendők
A kereskedők által kínált egységesített megoldások ezt a kérdést el akarják intézni. Microsoft Entra Agent ID (jelenleg public preview) a legtisztább megközelítés eddig: az emberi és munkaterhelés-azonosításon alapuló conditional access, identity governance és identity protection kiterjesztése az AI ügynökökre új identitástípusként. Google és Salesforce is hasonló rétegeken dolgozik. Ezek valódi előrelépést jelentenek az identitás első linkjének kezelésében, de még nem jelentenek teljes kormányzást. A conditional access meg tudja mondani, hogy egy ügynök hozzáférési kísérlete engedélyezett volt-e; nem tudja megmondani, hogy az ügynök döntése a hozzá tartozó hatáskörön belül született-e, miért jutott erre a döntésre, vagy melyik üzleti egység visel policy-felelősséget.
A hiányzó réteg: a reasoning-grade audit
A tényleges kormányzási rétegnek a döntéseket kell rögzítenie, nem pusztán a műveleteket. A hiányzó elem teherhordó primitívje a reasoning-grade audit, ami sokkal inkább hasonlít egy repülési feketedobozra, mint egy egyszerű syslogra. Egy példa arra, milyen mezőket kell tartalmaznia egy ilyen eseményrekordnak:
{ "event_id": "refund-2026-05-17-08431", "triggered_by": { "human_principal": "rep:olivia.chen@firm.com", "delegated_via": "support-console-session-9c2a", "customer_principal": "cust:7741289" }, "agent": { "identity": "refund-agent", "version": "v4.7.2", "policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)" }, "task": "Process refund for order 88812204", "retrieved_context": [ ... ], "reasoning_trace": "...", "tool_calls": [ ... ], "action": "refund:48.00", "principal_chain_hash": "0x9e7b3f..." }
Nem minden ügynöknek van szüksége ilyen részletes rögzítésre: egy időpont-egyeztető asszisztensre például nem. Azoknak azonban, amelyek pénzt mozgatnak, kódot telepítenek, vagy szabályozók szemében jelentős döntéseket hoznak, kötelező ennek megfelelő rögzítést alkalmazni. A megőrzés és lekérdezhetőség költséges, és komoly adatvédelmi implikációkkal jár, hiszen ezek a naplók tartalmazzák mindazt, amit az ügynök látott, beleértve olyan adatokat, amelyeket a rendszer eleve nem akart hosszú távon megőrizni.
Ennek megfelelően arányos megőrzési stratégiára van szükség: teljes reasoning-capture magas blast-radius ügynököknél (szabályozóval kapcsolatba kerülők, ügyfélpénzzel dolgozók, szerződésileg jelentős hatásúak, production-módosítók), és könnyített naplózás belső, alacsony kockázatú asszisztenseknél.
Ki írja és ki tartja karban ezeket a szabályokat?
Az architektúra-diagram ritkán teszi fel a kérdést: ki építi és ki üzemelteti ezt a réteget? A biztonság (security) képes érvényesíteni a szabályt, de nem feltétlenül tudja megalkotni. A visszatérítési jogköröket a refund üzleti tulajdonosai ismerik, nem a tűzfal. Az IT identitást tud kiosztani, de nem tudja megfogalmazni, mi számít “jó állapotnak” vagy hogyan néz ki egy eskálázási szabály. A MCP és az A2A protokoll közösségek dolgoznak a vezeték szintű identitáson és delegáción: az MCP eszközhívás-provenance-t ad, és az Entra Agent ID-re, illetve a legtöbb piaci megoldásra épülnek; az A2A a cross-agent delegáció primitívein konvergál. Mindkettő fontos, de egyik sem írja a policy-ket.
Az vállalatoknak egy új funkcióra van szükségük, amely a szabályokat birtokló üzleti egységek és a futtató platformcsapatok közé ékelődik. Hívjuk ezt agent operations-nek: tipikusan négy–nyolc fős csoport egy Global 2000 vállalatnál, beágyazott (nem központosított), közvetlenül a CIO-hoz vagy CISO-hoz jelentve, és tisztán megfogalmazott mandátummal: minden production agent regisztrálása; a névleges humán tulajdonos rögzítése; verziózott autoritás-specifikációk és megőrzési szabályok vezetése; valamint az életciklus kezelése. Minden agentet alá kell írni egy policy-vel, valódi ütemezéssel felülvizsgálni és ténylegesen kivonni a forgalomból, amikor az kezdeményezés lezárul — nem úgy, hogy csendben továbbél szponzorok nélkül.
A feladat nem könnyű. El kell kerülni, hogy a felülvizsgálati ütemezetek merev ceremóniákká váljanak, hogy a policy-artifaktok elmaradjanak az ügynök-deploy sebességétől, vagy hogy a funkció csak egy hely legyen, ahová az ügynököket halálra ítélik bizottsági döntéssel. Az agent operationsnak a platformcsapatok sebességével kell szállítani; különben negyedév alatt megkerülik.
Szabályozás és határidők
A munka sürgető: az EU AI Act nagy kockázatú rendelkezései ebben az évben lépnek hatályba, és a szabályozók magyarázhatóságot, nyomonkövethetőséget, életciklus-nyilvántartásokat és név szerint megnevezett emberi felelősséget fognak kérni. Ezek pontosan azok az artefaktumok, amelyeket egy agent operations funkció előállít.
A szerző felhívása egyszerű és megvalósítható: vegyenek ki egy produkcióban futó ügynököt, és egy délután alatt próbálják meg bizonyítékokkal alátámasztva megválaszolni a következőket: Kihez kötődik a jogosultsága, visszavezetve az akciót egy név szerint megjelölt emberhez? Hol van az autoritás definiálva, és ki írta alá a jelenlegi verziót? Ha holnap hibázik, ki fizet, hogyan dől el ez és mely reasoning-grade rekordok támasztják alá? A legtöbb építész három kérdésre üres válasszal és egy görcsös érzéssel távozik. Ennek a jelenségnek a neve a principal drift, és ha láthatóvá tesszük, kezelhetővé is válik.
A technikai háló, amelyet építettek, valós és szükséges, de nem elégséges. A hiányzó réteg az intézmény fölötte: a regiszter, az aláírt policy-k, a reasoning-grade audit és a lánc végén álló név szerint megjelölt felelős. A legtöbb vállalatnál ez még nem létezik, és nem fog érkezni pusztán egy új platform vásárlásával. Ki kell dolgozniuk maguknak.
