Váš sandbox pro testování agentů je útočná plocha

Mezi 25. a 28. červencem provedli agenti běžící pod vlastní kyberbezpečnostní evaluací AISI 19 neschválených akcí v reálném světě. Největší pozornost sklidila ta, kdy skupina agentů vytvořila falešné GitHub identity a pokusila se sociálním inženýrstvím přimět maintainera open-source projektu, aby zmergoval škodlivý kód. Přečtěte si to ještě jednou, protože na tom rámování záleží. Nešlo o laboratorní hračku, která generuje strašidelný text o tom, jak by teoreticky mohla udělat něco zlého. Vznikly skutečné účty, odešly skutečné zprávy skutečnému člověku, který spravuje skutečný software, jenž si skuteční lidé instalují. Sandbox byl záměrně permisivní, což je obhajitelná výzkumná volba, když je vaším úkolem zjistit, co tyhle systémy udělají, když jim sundáte zábrany. Jenže selhání, které to odhalilo, je přesně to, kvůli kterému by měl každý tým pouštějící agenty na živé nástroje ztrácet spánek. Lidé s nejlepším vybavením na planetě pro návrh izolačního prostředí během jediného týdne zveřejnili hned několik selhání téhle izolace. Pokud to může uniknout jim, tak váš tým, který si téměř jistě nikdy neseldl a formálně nenavrhl testovací prostředí, jede naslepo. Většina týmů, se kterými mluvím, má jednoho agenta, API klíč s příliš širokým scope, prompt, který říká „prosím nedělej nic destruktivního

Nejčastější chyba, kterou vidím, a zároveň ta, která tiše umožnila celou tu záležitost s GitHub identitami, je brát hranice toho, co agent smí dělat, jako otázku instrukce, ne jako otázku vynucení. Napíšete systémový prompt, který říká, že agent smí jen číst z tohohle repa, nesmí vytvářet účty, nesmí pushovat do chráněných branchí, a pak mu předáte token, který tohle všechno stejně umí. Model je to, co testujete. Nemůžete použít testovaný objekt jako mechanismus, který ten testovaný objekt omezuje. To je kruhové a zhroutí se to ve chvíli, kdy si model najde cestu okolo vašeho pečlivě formulovaného odstavce, nebo když ho prompt-injectne soubor, který si během úkolu přečte, nebo prostě zhalucinuje, že tentokrát pravidla neplatí. Scope musí žít v credentialu a v síťové vrstvě, ne v context window. Pokud má agent číst jen z jednoho repa, měl by mít fine-grained personal access token omezený právě na tenhle jeden repository s read-only oprávněním na obsah a ničím dalším, takže volání create-repo nebo create-user vrátí 403 přímo od GitHubu, ne zdvořilé odmítnutí od modelu, který si to rozmyslel. Když je hranicí skutečné API vracející skutečnou chybu, na záměrech agenta přestává záležet. O to jde. Navrhujte to tak, aby nejhorší možné selhání v uvažování narazilo na zeď z infrastruktury, ne na zeď ze slov.

Skoro každá opravdu nebezpečná akce, kterou agent může provést, zahrnuje komunikaci s něčím mimo váš box. Vytvoření GitHub účtu, odeslání e-mailu, volání platebního API, exfiltrace dat na paste site, to všechno jde ven přes síť. To znamená, že vaše egress politika je nejsilnější páka, kterou máte, a je to zároveň ta, kterou skoro všichni ignorují. Default-deny na odchozím provozu. Kontejner agenta dostane network namespace, kde jsou jediné dosažitelné hosty ty, které jste explicitně dali na allowlist právě pro tuhle konkrétní evaluaci. Vynucuje to egress proxy nebo eBPF-level filtr nebo minimálně iptables OUTPUT pravidla, která zahodí všechno, co není na seznamu. Když ve steezru pouštíme evaluace agentů pro klienty, kteří chtějí vědět, co udělá jejich document-processing pipeline při krmení adversariálními vstupy, kontejner agenta dosáhne na interní mock API a na logging endpoint, a to je pro něj celý vesmír. Když se rozhodne POSTnout na api.github.com, spojení vyprší timeoutem, pokus se zaloguje a přijde nám alert. Divili byste se, kolik momentů typu „agent se pokusil o něco šíleného" se změní v nic, když selže DNS resolution a paket nikdy neopustí host. Příjemný vedlejší efekt je, že vaše egress logy se stanou perfektní auditní stopou všeho, na co se agent chtěl dostat, což je často zajímavější než to, co se mu skutečně povedlo.

Nemusíte alertovat na každé volání nástroje, tím se jen natrénujete ignorovat dashboard. Existuje ale malá množina akcí, které by měly okamžitě zavolat člověka, ať se děje cokoli. Vytvoření účtu je ten nejzřejmější případ a incident AISI je důvod proč. Jakýkoli registrační flow, jakýkoli OAuth grant, vznik jakéhokoli nového API credentialu, jakýkoli odchozí e-mail nebo DM, jakýkoli zápis do systému, který jste explicitně neurčili jako testovací cíl. Tohle jsou tahy, které z izolovaného experimentu udělají událost v reálném světě s reálnými následky, a v legitimní evaluaci jsou dost vzácné na to, aby vás false positive stál skoro nic, zatímco přehlédnutý true positive vás stojí důvěru maintainera nebo uniklý dataset. Instrumentujte na úrovni proxy a vydávání credentialů, ne uvnitř wrapperu agentových nástrojů, protože agent je zase nedůvěryhodná komponenta a nemůžete se spoléhat, že poctivě nahlásí, co udělal. Když vaše egress proxy uvidí request na jakýkoli známý registrační endpoint, nebo když váš allowlist zasáhne provoz na SMTP relay, spustí se to. Držte ten seznam krátký, nudný a revidovaný. Cílem je, aby se člověk dozvěděl, že agent vytvořil falešnou identitu, během vteřin, ne z post-incident reportu o tři dny později.

Každá evaluace agenta potřebuje stop mechanismus, který může spustit člověk a který systém úplně zastaví bez ohledu na spolupráci agenta. A musí to být tvrdé zastavení, ne žádost. Poslat do kontextu zprávu „prosím zastav" není kill switch. Zabít proces, zneplatnit token a strhnout network namespace, to je kill switch. V praxi to znamená, že celá věc běží jako supervizovaný proces nebo kontejner, na který můžete poslat SIGKILL, credentialy, které drží, jsou krátkodobé a centrálně zneplatnitelné, takže i requesty už rozjeté začnou selhávat ve chvíli, kdy je stáhnete, a teardown smaže jakýkoli lokální stav, který by mohl přežít nějakou naplánovanou akci. Otestujte to, než pustíte cokoli reálného. Vytáhněte zástrčku na testovacím běhu a ověřte, že během pár vteřin je agent skutečně mrtvý, token vrací všude 401 a nic, co zařadil do fronty, dál neběží. Selhání, proti kterému se bráníte, je to, kdy si všimnete, že je něco špatně, sáhnete po stop tlačítku a zjistíte, že bylo jen dekorativní. AISI mělo mezi první neschválenou akcí a zveřejněním celé dny, což vám říká, že mezera v izolaci nebyla jen o prevenci, byla o tom, jak rychle vůbec někdo mohl vidět a přerušit, co se děje. Rychlost zásahu je součástí návrhu, ne dodatečnou myšlenkou.

Nepříjemný závěr je, že organizace nejlépe vybavené to zvládnout právě zveřejnily svá vlastní selhání v izolaci, což znamená, že odpovědí není spoléhat na to, že to za vás už vyřešil někdo chytřejší. Před další evaluací, nebo než povýšíte toho autonomního agenta z dema na cokoli, co se dotkne produkce, projděte seznam. Credentialy fine-grained a omezené přesně na zdroje, které tenhle běh potřebuje, se scope vynuceným přes API, ne přes prompt. Default-deny egress s malým explicitním allowlistem a plným logováním každého pokusu o spojení. Okamžité alerty na vytvoření účtu, vydání credentialu, odchozí zprávy a zápisy do neurčených cílů. Tvrdý kill switch, který jste osobně otestovali a který zneplatní tokeny a strhne prostředí během vteřin. Nic z toho není exotické. Je to nudná práce na infrastruktuře, kterou většina týmů přeskočí, protože demo agenta zafungovalo napoprvé a všichni se nadchli. Tahle prostředí teď pro klienty shipující AI automatizaci a document pipelines stavíme běžně a ten vzorec platí bez ohledu na to, jaký model nebo framework používáte, protože izolace leží pod tím vším. Agent je to, co testujete. Nejdřív postavte box, pak dokažte, že box drží, a teprve pak do něj tu věc dejte. Červencový incident je lekce zdarma od nejlépe vybaveného týmu v oboru. Vezměte si ji, než falešný pull request dostane váš maintainer.