Bezpečnost AI agenta začíná jedním pravidlem: váš AI agent by nikdy neměl držet vaše přihlašovací údaje. Zde je 38 let starý broker vzor, který to zajišťuje.
AI agenti jsou zmatení zástupci. To je 38 let starý bezpečnostní vzor a odpověď je stejně stará: vložte brokera — důvěryhodnou, sledovatelnou, deterministickou, auditovatelnou, nezfalšovatelnou, úzce vymezenou a politikou řízenou ne-AI mezivrstvu — mezi agenta a SaaS API, která potřebuje volat, a která drží přihlašovací údaje, které by agent neměl mít.
V roce 1988 Norm Hardy publikoval krátký článek, kde popsal skutečný incident ze svého působení v Tymshare. Fortran kompilátor zvaný FORT byl umístěn v systémovém adresáři jménem SYSX. Pro sběr statistik využití potřeboval kompilátor zapisovat do (SYSX)STAT, takže operační systém udělil FORTu „licenci na domácí soubory“, která mu umožňovala zapisovat do jakéhokoliv souboru v SYSX. V tomto adresáři byl i fakturační soubor systému, (SYSX)BILL. Uživatel mohl při spuštění kompilátoru zadat název souboru pro volitelný výstup ladění. Jednoho dne uživatel zadal (SYSX)BILL. Kompilátor požádal OS o otevření tohoto souboru pro zápis; OS, s ohledem na licenci, to umožnil. Fakturační data byla přepsána. Kompilátor udělal přesně to, k čemu byl navržen. Chyba byla v architektuře.
Hardy to nazval problém zmateného zástupce: privilegovaný program (zástupce) má vlastní oprávnění; méně privilegovaný volající po něm něco chce; zástupce se splete v tom, na čí oprávnění jedná, a použije své vlastní. Řešením je odebrat zástupci toto oprávnění a umístit jej za samostatnou vrstvu, která volání zprostředkuje na vyžádání. Tou vrstvou je broker.
O třicet osm let později je každý AI agent, který vaše firma provozuje, zmatený zástupce. A většina z nich běží bez brokera.
Proč AI agenti zhoršují bezpečnostní problém
FORT od Hardyho měl jeden vstupní kanál: příkazovou řádku. Moderní AI agent jich má desítky: těla e-mailů, načtené webové stránky, nahrané PDF, výstupy nástrojů z MCP serverů, zprávy od ostatních agentů v multi-agentním systému. Cokoliv, co se dostane do kontextového okna, může vydat instrukce, a agent je ze své podstaty považuje za legitimní.
To narušuje předpoklad, na kterém tradiční řízení přístupu závisí: volající ovládá vstup. Ve webové aplikaci pochází volající (autentizovaná relace) i vstup (tělo HTTP požadavku) ze stejného místa. U agenta je volajícím kdokoliv, kdo ovlivní prompt, což znamená, že útočník, který může napsat e-mail nebo ovlivnit výsledek vyhledávání, je také volající.
V listopadu 2025 bezpečnostní výzkumníci z PromptArmor ukázali, jak to vypadá v praxi. Skryli škodlivé instrukce ve fontu o velikosti 1 pixelů v integračním návodu. Když vývojář nasměroval Google Antigravity IDE na tento návod, agent obešel vlastní ochranu souborů založenou na .gitignore tím, že spustil cat. Poté unikl obsah souborů .env na útočníkem ovládanou URL webhook.site prostřednictvím vlastního prohlížeče subagenta Antigravity. Uživatel vše nastavil správně. Sandbox fungoval. Agent prostě nedokázal rozlišit, co požaduje uživatel a co mu říká vstup.
Stejný vzorec jako u Hardyho FORTu, o desítky let později: široká oprávnění, nedůvěryhodný vstup, žádný způsob, jak je oddělit.
Komunita má odpovědi. Jen jsou roztroušené.
Tohle není nový problém. Bezpečnostní komunita píše odpovědi už desítky let:
Bezpečnost založená na schopnostech (Dennis & Van Horn, 1966; později jazyk E a práce Marka Millera na Caja v Google). Princip: neudělujte obecná oprávnění na základě identity nebo umístění; předávejte explicitní, nezfalšovatelné schopnosti pro každý zdroj, ke kterému má program přístup. Schopnost spojuje co můžete dělat s čím to můžete dělat a nelze ji zaměnit za nic jiného.
Brokerované přihlašovací údaje (zakotveno v OWASP LLM Top 10). Nedávejte API tokeny do kontextu LLM. Důvěryhodná mezivrstva provede volání jménem agenta; model rozhoduje co dělat, broker řeší jak. Prompt injection, která model požádá o vytištění přihlašovacích údajů, nezíská nic užitečného. Údaje tam nejsou.
Phantom Token Pattern (Curity, původně pro OAuth v mikroslužbách). Agent drží neprůhledný identifikátor relace, ne skutečný bearer token. Proxy ověří identifikátor, na síťovém okraji vymění za skutečné přihlašovací údaje a předá dál. Pokud agent unikne své prostředí, útočník získá řetězec, který vyprší s koncem relace.
Vkládání přihlašovacích údajů právě včas (systémy workload identity jako Aembit). Vytvářejte krátkodobé, úzce vymezené přihlašovací údaje pro každý požadavek místo vydávání dlouhodobých tokenů.
Nic z toho nechybí v literatuře. Chybí to ve výchozím nastavení. Většina agentních platforem stále předává modelu OAuth token bez brokera mezi nimi a spoléhá na štěstí.
Jak funguje broker v Zero
Nevynalezli jsme žádný z výše uvedených vzorů. Propojili jsme je do jednoho brokera, který běží ve výchozím nastavení pro každého agenta v Zero. Je to důvěryhodná mezivrstva, kterou tyto vzory popisují, navržená pro platformu AI agentů. Každé volání, které agent provede na konektor, prochází přes něj. Každý konektor představuje jednu externí SaaS (Slack, GitHub, Notion atd.).
Broker sedí mezi každým agentem a každým konektorem. Skutečné přihlašovací údaje žijí pouze na straně brokera za přerušovanou čárou.
Představte si to jako tři vrstvy.
1. Izolace přihlašovacích údajů
Sandbox agenta nikdy nedrží skutečné přihlašovací údaje ke konektoru. Když připojíte SaaS k Zero, OAuth token nebo API klíč zůstává na straně brokera. Sandbox dostane zástupný řetězec, který vypadá dostatečně jako tajemství prostředí, aby stávající nástroje fungovaly, ale žádná SaaS by jej nepřijala.
Když agent provede požadavek na registrovaný host konektoru, broker požadavek spáruje, vyřeší šablonu ověření konektoru a vloží skutečné přihlašovací údaje na síťovém okraji. Požadavek jde nahoru s platným ověřením; agent nikdy nedržel nic užitečného. Agent napadený prompt injection, který vypíše své proměnné prostředí, předá útočníkovi zástupný řetězec, ne SaaS token.
To je phantom token pattern aplikovaný na AI agenty.
2. Politická brána konektoru
Konektor v Zero by měl být víc než jen vypínač. Každý konektor popisuje základní API, která pokrývá, a jak má být ověření vloženo. Pokud upstream služba zveřejňuje stabilní mapování rozsahů na endpointy, může také popsat, která pojmenovaná oprávnění pokrývají jednotlivé metody a cesty. Slackův slack-api-ref je dobrý příklad.
Když tedy agent připojený ke Slacku volá chat.postMessage, broker může tento požadavek namapovat na chat:write. Když čte auditní logy, je to admin.analytics:read. Pro každého agenta permission_policies definuje, jak se tato pojmenovaná oprávnění chovají: povolit, zamítnout nebo se zeptat. Politika je vynucena na brokeru před vložením ověření, ne jako nápověda pro model. Pokud se agent pokusí provést volání pokryté zamítnutým oprávněním, třeba kvůli prompt injection, požadavek se nikdy nedostane do upstream sítě.
Ne každý konektor má dnes toto rozlišení. Některá upstream API nezveřejňují stabilní mapování rozsahů na endpointy. GitHubův GraphQL je typický případ: REST strana lze mapovat, ale GraphQL zatím ne. U těchto konektorů broker stále řídí vložení přihlašovacích údajů a síťovou cestu, zatímco politická brána se vrací ke hrubší politice na úrovni konektoru nebo hostitele, kterou platforma může skutečně vynutit. Tyto doplňujeme, jakmile jsou upstream data dostupná. Netvrdíme pokrytí, které jsme nevybudovali.
Tokeny nenesou obecná oprávnění. Oprávnění je brokerováno za každého agenta, v rozlišení, které upstream podporuje. To je polovina odpovědi založené na schopnostech.
3. Provozní smyčka a audit
Princip nejmenších oprávnění funguje jen tehdy, když je chybový stav použitelný. Agenti rostou. Po šesti týdnech může výzkumný agent, který začal čtením z Notion, potřebovat zapsat shrnutí zpět. Běžné chyby jinde: agent tiše běží bez nového oprávnění a selže, nebo operátor v panice udělí příliš mnoho práv a už je nikdy neodebere.
Zamítnutý požadavek na konektor vrací strukturovanou 403: konektor, metoda, cesta, základní URL a odpovídající názvy oprávnění, pokud je broker dokáže identifikovat. Systémový prompt agenta mu říká, jak zamítnutí diagnostikovat a jak požádat přesně o to oprávnění, na které právě narazil, čímž vznikne jednorázový grantovací URL pro uživatele nebo administrátora. To udržuje eskalační cestu navázanou na konkrétní požadované oprávnění místo toho, aby se z toho stalo „povolit vše“.
Žádosti o změnu oprávnění čekají ve frontě. Vlastníci a administrátoři je mohou schválit nebo zamítnout z dashboardu; schválené žádosti aktualizují politiku agenta a další pokus projde. Většina platforem tuto smyčku vynechává. Bez ní zůstává „nejmenší oprávnění“ jen na prezentaci, místo aby běželo v produkci.
Stejná cesta přes brokera slouží auditu. Síťové logy na úrovni běhu zaznamenávají síťovou aktivitu sandboxu napříč HTTP, TCP, DNS a nižšími úrovněmi paketů pro ne-TCP provoz. Požadavky spárované s konektorem obsahují strukturovaná broker metadata: konektor, odpovídající oprávnění (pokud je k dispozici), výsledek povolit/zamítnout, metadata o ověření a příznak zpoplatnění. Pokud se někdo později zeptá „co tento agent dělal v úterý ve 3 odpoledne?“, odpověď zrekonstruujete z těchto záznamů. Prevence něco přehlédne. Auditní stopa je způsob, jak to zjistit.
Co jsme nevyřešili
I se vším výše může agent s legitimním chat:write být stále přesvědčen, aby zveřejnil trapnou zprávu do kanálu, ke kterému už má přístup. Broker zúží rozsah škody; neeliminuje ji.
Druhou polovinou odpovědi je schvalování akcí s vysokým dopadem, validace výstupů a považování návratů nástrojů za nedůvěryhodné ve výchozím stavu. Tato práce je na roadmapě, zatím není v produktu. Kdo tvrdí, že problém zmateného zástupce vyřešil end-to-end, něco vám prodává.
Tohle by měl být základ, ne funkce navíc
Bezpečnost založená na schopnostech existuje od 70. let. Brokerované přihlašovací údaje jsou v OWASP LLM Top 10. Phantom tokeny předcházejí éře LLM. Nic z toho nechybí proto, že by nikdo neznal odpověď. Chybí to proto, že rané agentní platformy optimalizovaly pro „ať demo funguje“ a bezpečnost odložily na později, což často nikdy nepřišlo.
Další generace platforem by měla mířit výš. Tokeny by neměly vstupovat do kontextu modelu. Oprávnění by měla být vyjmenována za každého agenta. Eskalace práv by měla jít přes člověka. Každá akce by měla být auditovatelná end-to-end. Nic z toho není nové. Vše by mělo být standardem.
Když vybíráte platformu pro agenty, otázka „je to bezpečné?“ nikam nevede. Každý dodavatel řekne ano. Lepší otázka: ukažte mi svého brokera a popište, co se stane, když agent požádá o rozsah, který nemá.
Broker je ve výchozím nastavení před každým agentem v Zero. Inventář konektorů, mapování rozsahů, politiky oprávnění a logika brokera jsou v repozitáři Zero. Našli jste konektor, který nemáme? Založte issue.
Reference
Základní
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (zakládající článek o capability-systémech)
- Mark Miller et al., Caja: bezpečnost založená na schopnostech pro web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Citované reálné incidenty
- PromptArmor, Google Antigravity Exfiltrates Data, listopad 2025
- Simon Willison, pokrytí a analýza, listopad 25, 2025
