A VB Transform 2026 rendezvényen Mukesh Karki, az NTT DATA AIVista műszaki igazgatója és Mayank Upadhyay, a Snowflake biztonsági és megbízhatósági vezetője azt hangsúlyozta, hogy bár azonosítással kapcsolatos problémák rendezése szükséges, önmagában nem elég a biztonságos, nagyszabású ügynökrendszerek üzemeltetéséhez. Előadásuk szerint az akció-szintű engedélyezés és a hamisíthatatlan auditnaplók beépítése minden ügynökinterakcióba elengedhetetlen.
Miért probléma a megosztott hitelesítés?
A VentureBeat júniusi kutatása szerint a vállalatok 69%-a továbbra is olyan AI-ügynököket használ, amelyek megosztott hitelesítő adatokkal működnek — ez a gyakorlat összefügg magasabb biztonsági incidens- és majdnem-incidens arányokkal. Upadhyay rámutatott, hogy sok feltevés a korábbi szoftvergenerációból származik:
„A hagyományos szoftvervilágban egy ember kattint valahol, és a szoftver determinisztikusan elvégzi a megszokott API-hívást. Az ügynöki világban azonban a szoftvernek saját „agya” van, és folyamatosan újrarendeződik. Ha egy ügynöknek több jogosultságot adsz, mint amire adott célhoz szüksége van, az ügynök felfedező jellegű, sok mindent kipróbál, és nem kívánt melléhatások léphetnek fel.”
További kockázatot jelent egyetlen statikus API-kulcs beágyazása az ügynökbe: „Nagyon rossz mintázat, ha egy API-kulcsot bedobsz az ügynökbe, és az úgy kommunikál egy SaaS-szolgáltatással, mintha bárki más beszélne vele, mert így az ügynök megkapja mindenki igényének egyesítését,” tette hozzá. Emellett nehezíti a forenzikát is: ha valami rosszul sül el, nem lehet pontosan hozzárendelni a felelős ügynökhöz.
A scopeolt hitelesítés csak a kiindulópont szabályozott iparágakban
Karki ügyfelei többsége biztosítási, egészségügyi és pénzügyi szektorokból érkezik; ő a scopeolt hitelesítő adatokat alapnak tekinti. „Szabályozott környezetben egy, a megosztott körre kiterjedő hitelesítő adatokkal nem rendelkező ügynök egyszerűen nem fog futni, pont.” Ugyanakkor hangsúlyozta, hogy a scopeolt hitelesítés csupán az első réteg: van az ügynök működési jogkörének földrajzi/joghatósági oldala és az adott szervezet belső szabályai.
Példaként említette, hogy egy kárigazgató ügynök Washington államban más szabályok szerint működik, mint Kaliforniában, és minden káresemény egyedi. „Ezek a scopeolt hitelesítések nem elegendőek, mert a döntéseknek akció-alapúnak és szabály-orientáltnak kell lenniük éppen akkor, amikor végrehajtja az adott lépést.”
Hol bukik meg az „alkalmazotti” analógia az ügynököknél?
Karki szerint az alkalmazotti analógia csak részben működik: az ügynököknek meg kell tanulniuk egy szervezet sajátos kontextusát, hasonlóan egy új munkavállalóhoz. Ugyanakkor emberekkel ellentétben a vállalatok nem tudnak ésszerűen hosszú időn át bizalmat kiépíteni ezreknyi ügynökkel.
„Egy sztáralkalmazott az egyik szervezetben nem biztos, hogy ugyanilyen jól teljesít máshol, nem azért, mert romlott a képessége, hanem mert hiányzik a helyi kontextus. Ugyanez igaz az ügynökökre. Ha minden alkalmazottnak száz ügynöke van, nem mondhatod azt, hogy majd mindet átvilágítod és háttérellenőrzöd” — mondta Karki.
Upadhyay azt javasolta, hogy az ügynököket szervezeti hierarchia szempontjából eggyel lejjebb érdemes kezelni: „Kezeld őket gyakornokokként. Jó szándékuk megvan, de nem mindig értik, mit csinálnak, és figyelni kell őket, miközben fokozatosan építed a bizalmat.” A Snowflake platformon az adminisztrátorok globális védőkorlátokat (például csak-olvasás műveletek) szabhatnak meg, és a fejlesztők egyedi munkamenetek indításakor tovább szűkíthetik az ügynök jogosultságait.
Háromrétegű megközelítés az ügynök-irányításban
Karki szerint a governance-nek minden egyes ügynök-akciónál jelen kell lennie, és kívül kell elhelyezkednie magát az ügynököt: ez az egyetlen módja annak, hogy később bizonyítani lehessen, hogy az ügynök csak engedélyezett műveletet hajtott végre.
Upadhyay három rétegbe sorolta a governance-t:
- Ügynök réteg: identitás, eszközjogosultságok és MCP (model control plane) governance.
- Modell réteg: közvetett prompt-injekció elleni védelem és a modellek az ügyfél VPC-jében való futtatásának lehetősége, hogy a promptok ne legyenek láthatóak a modellszolgáltató felé.
- Adat réteg: legkisebb jogosultság elve, zero-copy architektúra és szerepalapú hozzáférés-vezérlés.
A három réteg együttes működése szükséges ahhoz, hogy az ügynökök biztonságosan és kiszámítható módon működjenek.
Mit érdemes először auditálni a vállalatoknak?
Upadhyay szerint két helyen érdemes kezdeni a meglévő ügynökök governance-ének auditálását. Először is a statikus titkok (például beágyazott API-kulcsok) jogosultságait kell átvilágítani, mivel ez a legnagyobb, javítható támadási felület. Másodszor a shadow AI kezelése egy MCP átjárón keresztül: így a fejlesztőknek nem kell saját, nem menedzselt MCP szervereket futtatniuk, és az adminisztrátorok láthatják, ki melyik MCP szerverrel kommunikál.
Karki figyelmeztet, hogy sok intézkedést nem lehet utólag ráépíteni egy már futó ügynökrendszerre, különösen ha bizonyítani kell az auditoroknak, miért viselkedett az ügynök egy adott módon. „A bizonyíthatóságot a rendszer tervezésekor felülről lefelé kell beépíteni.”
Kiegyensúlyozás: korlátozás vs. képesség
Mindkét szakember elismerte a kötelező kompromisszumot a korlátozás és a képesség között. Ezt részletes feladat-szinten lehet kezelni: magas kockázatú műveleteknél autonóm végrehajtás visszatartása confidence scoringgel, köztes megoldásként sandbox alkalmazása. Ugyanakkor hangsúlyozták, hogy a szabályok és a nyomonkövethetőség alapjait már a rendszer tervezésekor le kell fektetni.
Támogatott tartalom: a cikket az NTT DATA AIVista mutatta be. A VentureBeat által megjelentetett támogatott (sponsored) anyagok olyan cégek által előállított tartalmak, amelyek fizetnek a megjelenésért vagy üzleti kapcsolatban állnak a kiadóval, és mindig egyértelműen jelzik ezt a státuszt.
