Představme si asistenta, který má připravit podklady pro zákazníka. Přečte e-mail, otevře interní dokument a navrhne odpověď. Potud běžná kancelářská práce. Jenže mezi návrhem odpovědi a jejím odesláním leží hranice, kterou nelze svěřit větě „buď opatrný“ v zadání modelu. Na druhé straně už někdo dostal soubor, peníze změnily majitele nebo zmizela data.
Právě do tohoto místa míří AgentGate, projekt, o němž dnes píšeme v rychlé zprávě o autorizační bráně pro AI agenty. Před provedením akce má vyhodnotit její riziko a vrátit jednu ze tří odpovědí: povolit, zamítnout, požádat člověka. Je to rozumnější výchozí bod než doufat, že dostatečně důrazné varování v chatu nahradí řízení přístupu.
Na celém projektu je ale zajímavější něco jiného než slibovaná rychlost. Rozhodnout, že se akce nemá provést, a skutečně jí zabránit jsou dvě různé schopnosti. Dokumentace AgentGate ten rozdíl ukazuje docela názorně. A právě podle něj by firmy měly podobné pojistky vybírat.
Model radí, pravidla rozhodují. Jenže z čeho?
Podle repozitáře AgentGate běží kontrola mimo samotného agenta. Menší klasifikační model posuzuje čtyři věci: vliv nedůvěryhodných instrukcí, soulad navržené akce s cílem, její vratnost a odesílání dat ven. Navazující pravidla pak určí výsledný verdikt. Součástí návrhu jsou záznamy rozhodnutí v PostgreSQL a přehled pro člověka, který schvaluje pozastavené operace.
Zní to technicky, ale praktický význam je jednoduchý. Stejný požadavek na odeslání souboru může být splněním úkolu i jeho zneužitím. Záleží na tom, který soubor odchází, komu, proč a z jakého podnětu. Útok označovaný jako prompt injection se snaží do podobného rozhodování propašovat instrukce například z dokumentu nebo e-mailu, který měl být pouhým podkladem. Kontrola mimo agenta proto dává smysl: pracovní podklad nemá dostat možnost přepsat pravidla celé firmy.
Oddělený proces ovšem z modelového odhadu neudělá jistotu. Klasifikátor pořád může chybně vyhodnotit kontext nebo nepoznat škodlivý požadavek. A pokud pevné pravidlo říká „zamítni při vysokém skóre rizika“, jeho výsledek závisí i na kvalitě tohoto skóre. Deterministická pravidla znamenají předvídatelné zpracování vstupu, nikoli neomylné pochopení situace.
To je důležité při čtení sebevědomého README. Projekt uvádí rychlost v řádu desítek milisekund a ukazuje několik úspěšných bezpečnostních scénářů. Jsou to údaje a demonstrace autora, nikoli naše měření nebo nezávislý audit. Ukázka, v níž kontrola správně odmítne známý útok, neprokazuje odolnost vůči všem ostatním. A nula dolarů za externí modelové volání neznamená nulové náklady na hardware, provoz a správu.
Závora nepomůže, pokud kolem vede druhá cesta
Integrační příručka popisuje mimo jiné obal pro komunikaci MCP. Ten zachytává volání nástrojů a původnímu serveru je předá pouze při verdiktu „allow“. Ve zdrojovém kódu tohoto obalu vede „deny“ k chybové odpovědi, zatímco „ask“ vrací informaci o potřebě lidského schválení; samotné volání v tu chvíli nepředá dál. Nejde tedy jen o další upozornění pro model.
Vedle toho dokumentace ukazuje přímou integraci přes HTTP. Klient nejprve požádá o posouzení a podle výsledku následně spustí vlastní nástroj. Tady už záleží na tom, zda integrátor kontrolu opravdu postavil do všech cest k provedení akce. Samostatná služba, která odpovídá „nedoporučuji“, nemá automaticky pravomoc odebrat klientovi přístup k databázi.
To není důkaz nalezené zranitelnosti AgentGate; projekt jsme provozně netestovali. Je to podstatná podmínka takové architektury. Pokud agent nebo jím ovládaný proces stále může použít stejné přihlašovací údaje přímo, provozovatel musí zabránit obcházení kontrolního místa. Jinak brána hlídá hlavní vchod, zatímco vedlejší dveře zůstaly otevřené.
Už u izolace MCP serverů v kontejnerech jsme rozebírali, proč oddělení procesu nenahrazuje správně omezená oprávnění. AgentGate přidává jinou vrstvu: posouzení konkrétního kroku před jeho provedením. Tyto vrstvy se doplňují. Ani dobrý odhad rizika ale není důvodem vrátit agentovi univerzální klíče od produkce.
Schvalovací tlačítko ještě není lidský dohled
Předání rozhodnutí člověku se obvykle označuje jako human-in-the-loop. V prezentaci vypadá dobře: riziková operace se zastaví a někdo ji potvrdí. V praxi je rozhodující, co ten člověk uvidí a co přesně jeho souhlas dovolí. Schválení neurčitého pokynu „odeslat výsledek“ je něco jiného než souhlas s konkrétní přílohou a konkrétním příjemcem.
Představme si třeba obchodního asistenta, který připravuje nabídku. Rozumný požadavek ke schválení ukáže adresáta, obsah zprávy i přiložený dokument. Schválení má patřit právě této podobě akce, ne libovolné další zprávě, kterou agent později sestaví. To je naše doporučení pro nasazení, nikoli tvrzení, že AgentGate všechny tyto vazby již zajišťuje.
Podobně záleží na tom, co systém udělá při výpadku rozhodovacího modelu. Specifikace pravidel AgentGate popisuje předání člověku nebo zamítnutí při chybě modelu; pro nejisté výsledky nabízí rovněž předání ke schválení. Smyslem takové pojistky je, aby se technický problém nezměnil v automatické povolení. Samotný text pravidla ale nestačí: stejnou zásadu musí respektovat i klient, který nástroj nakonec vykonává.
A pak je tu obyčejná únava. Když obsluha schvaluje desítky neurčitých dotazů, tlačítko se snadno promění v administrativní překážku, kterou chce mít rychle za sebou. Podle nás proto není cílem posílat člověku všechno. Rutinní, úzce omezené čtení může probíhat automaticky; odeslání citlivých dat nebo nevratná změna si zaslouží konkrétní rozhodnutí. Dobrá automatizace šetří pozornost pro chvíle, kdy má skutečnou hodnotu.
Co má firma chtít před prvním ostrým během
Pro posouzení podobného nástroje bychom začali čtyřmi praktickými situacemi. Asistent pošty má umět vytvořit koncept bez práva jej sám odeslat. Databázový pomocník má dostat účet odpovídající povoleným operacím, ne správce celé databáze. Provozní agent má mít oddělené zjišťování stavu od zásahů do služby. A nákupní asistent musí mít jasně vymezeného příjemce platby a rozsah schválení. Jsou to modelové příklady nasazení, ne incidenty zjištěné u AgentGate.
U každého z nich je třeba zkoušet také nepohodlné varianty: kontrolní služba neodpoví, objeví se neznámý nástroj, po schválení se změní argumenty nebo se stejná žádost odešle znovu. Úspěšná odpověď brány ještě nepotvrzuje úspěšné provedení akce. A chyba při provádění zase neprokazuje, že se nic nestalo. Zejména u plateb či odesílání zpráv nesmí být automatické opakování náhradou za zjištění skutečného stavu.
Záznam rozhodnutí je v takové situaci užitečný, ale potřebujeme k němu i výsledek provedení. Pro audit má cenu vědět, co agent navrhl, kdo to povolil, co nástroj skutečně udělal a zda šlo následky vrátit. Současně je třeba hlídat, aby se z historie nestala další kopie citlivých dokumentů přístupná příliš mnoha lidem. Dashboard přidává přehled; sám neřeší pravidla zacházení s jeho obsahem.
AgentGate stojí za pozornost tím, kam kontrolu umisťuje: mezi záměr modelu a akci nástroje. Nemáme důvod z veřejného repozitáře dělat hotové bezpečnostní doporučení ani mu přisuzovat nezávisle ověřenou účinnost. Máme ale dobrý důvod trvat na principu, který otevírá. Agent může navrhovat, co chce udělat. Právo to skutečně provést musí dostat od systému, který jeho návrh dokáže i zastavit. Pokud tuhle pravomoc nemá, nekoupili jsme bezpečnostní hranici. Přidali jsme další názor do konverzace.
