AWS ukazuje tokeny „v mene používateľa“ pre viacnájomných agentov

Amazon Web Services posúva debatu o podnikových AI agentoch od samotného volania modelu k tomu, kto presne smie cez agenta konať. V novom technickom návode pre Amazon Bedrock AgentCore Gateway opisuje implementáciu výmeny tokenov „on behalf of“, teda v mene používateľa, pre viacnájomné agentické systémy. Nejde o ďalší marketingový príklad chatbota, ale o jednu z kľúčových vrstiev, ktorá rozhoduje, či sa agent dá bezpečne pustiť k interným API, dátam a pracovným nástrojom rôznych zákazníkov alebo oddelení.

Základný problém je jednoduchý: ak agent pristupuje k nástroju iba cez jeden servisný účet, cieľový systém často nevie, za ktorého človeka alebo nájomcu sa akcia vykonáva. To je v demo prostredí pohodlné, no v reálnej firme nebezpečné. Audit potom vidí iba agenta, nie pôvodného používateľa; oprávnenia sa ľahko rozlejú príliš široko; a pri zdieľanom agentovi medzi viacerými tenantmi rastie riziko, že nesprávne zviazaný token otvorí dáta, ktoré do požiadavky nepatria. AWS preto stavia článok okolo claimov v JSON Web Tokenoch, transformácií medzi jednotlivými hopmi a väzby na konkrétne publikum služby.

V návode je dôležité najmä to, že AgentCore Gateway nevystupuje iba ako pasívna brána pred nástrojmi. Má byť miestom, kde sa pred volaním nástroja overí identita, tenant, publikum tokenu a pravidlá prístupu. AWS používa Okta ako poskytovateľa identity a ukazuje, ako sa z pôvodného používateľského tokenu vytvára token určený pre konkrétny downstream systém. Takýto prístup je bližší klasickej podnikovej bezpečnosti než jednoduchému „API kľúču pre agenta“: každý krok má vlastné tvrdenia v tokene a cieľová služba má dostať token určený práve pre ňu.

Pre firmy je podstatný pojem viazanie publika. Token vydaný pre jeden nástroj by nemal byť použiteľný v inom nástroji, aj keby sa k nemu agent alebo útočník dostal. V agentických workflow je to dôležité preto, že agent môže počas jednej úlohy plánovať viac krokov, volať databázu, CRM, systém lístkov alebo internú dokumentáciu. Bez úzkeho publika a tenantového kontextu sa z reťazca volaní stáva veľká plocha na zneužitie. S viazaním publika je každé volanie presnejšie obmedzené a dá sa samostatne auditovať.

Téma má praktický dopad aj mimo AWS. Väčšina diskusií o agentoch sa sústreďuje na plánovanie, pamäť, nástroje a cenu inferencie. Pri nasadzovaní v bankách, zdravotníctve, verejnom sektore alebo B2B SaaS však prvá otázka znie inak: ako agent zachová rovnaké prístupové pravidlá, aké by platili pre človeka v používateľskom rozhraní? Implementácia OBO výmeny tokenov je jednou z odpovedí. Agent nemá obísť existujúce identity, ale preniesť používateľský kontext cez kontrolovanú bránu.

Zároveň nejde o úplné vyriešenie bezpečnosti agentov. Tokeny určujú, kto a kam smie volať, ale samy nepovedia, či je vybraná akcia rozumná, či prompt neobsahuje injekciu alebo či nástroj nevracia citlivý obsah späť do modelu. Preto má byť takáto architektúra spojená s logovaním, validáciou argumentov nástrojov, obmedzením rozsahu oprávnení a pravidlami pre schvaľovanie rizikových akcií. OBO vrstva je skôr podmienka pre bezpečné nasadenie než hotový bezpečnostný produkt.

Pre vývojárov agentických platforiem je zaujímavé, že AWS opisuje konkrétny vzor pre multi-tenant prostredie. To je prostredie, v ktorom jeden agent alebo jedna služba obsluhuje viac zákazníkov, projektov či organizačných jednotiek. Ak sa tenantové tvrdenia spracujú až v aplikácii, chyba v logike môže mať veľký dopad. Ak sú súčasťou tokenového toku a overujú sa na hranici brány, kontrola je bližšie k infraštruktúre a ľahšie sa opakuje naprieč nástrojmi.

Návod tiež naznačuje, kam smerujú cloudové agentické platformy. Nestačí dodať runtime pre model a konektory na nástroje. Podniky budú čoraz viac vyžadovať identity, autorizáciu, oddelenie tenantov, preukázateľné auditné stopy a možnosť integrovať agentov s existujúcimi poskytovateľmi identity. Ak tieto vrstvy nevzniknú, agenti ostanú uzamknutí v menej citlivých úlohách. Ak vzniknú dobre, môžu sa dostať bližšie k procesom, ktoré dnes vyžadujú manuálnu prácu v interných systémoch.

Najdôležitejšie posolstvo článku je preto triezve: schopnejší agent zvyšuje hodnotu len vtedy, ak systém vie presne povedať, v mene koho koná. AWS tu nepredstavuje nový model, ale bezpečnostný vzor pre jeho používanie. Pre slovenské a európske firmy, ktoré uvažujú o agentoch nad dátami zákazníkov alebo zamestnancov, je to užitočný signál. Architektúra agentov sa bude musieť navrhovať spolu s identitou a prístupovými právami, nie až po úspešnom prototype.