Představme si, že AI agent napíše skript na zpracování firemních objednávek. Vývojář ho spustí v „bezpečném sandboxu“ a jde na kávu. Jenže tohle uklidňující slovo může znamenat malý interpret uvnitř stejného procesu, kontejner sdílející jádro serveru i samostatný virtuální stroj. Pokud nevíme, kterou z těchto hranic náš kód skutečně dostal, bezpečnostní slib nám pomáhá hlavně lépe spát. S ochranou serveru to ještě nemusí mít mnoho společného.
Právě na rozdíl mezi názvem a skutečným provedením míří Plimsoll, projekt, který jsme dnes představili v rychlé zprávě o kontrole izolace AI kódu. Před spouštěcí prostředí staví vrstvu, přes kterou může každá žádost určit nejnižší přijatelnou úroveň ochrany. Podle dokumentace se při nesplnění tohoto minima kód vůbec nespustí. To je podstatně užitečnější pravidlo než prosba agentovi, aby byl opatrný.
Podle nás je na projektu cenná právě tahle změna otázky. Místo „věříme tomuto modelu?“ se ptá „co musí prostředí splnit, než mu dovolíme cokoli vykonat?“. Model může být schopný, dobře vychovaný a stále napsat chybný program. Provozní hranice proto mají stát mimo něj, ne v jeho ujištění na konci odpovědi.
Jedno slovo, čtyři různé zdi
Technika zvaná sandboxing omezuje, kam spuštěný program smí zasahovat. Plimsoll ale nevyrábí vlastní izolační mechanismus. Jak vysvětluje dokumentace úrovní izolace, používá existující prostředí a popisuje jejich hranice čtyřmi stupni: process, container, kernel a vm. Tohle pořadí je klasifikace projektu, nikoli univerzální certifikát bezpečnosti.
Nejslabší varianta spouští JavaScript přes QuickJS a WebAssembly uvnitř procesu služby. Autor ji určuje pro vývoj a výslovně varuje před nepřátelským kódem: chyba umožňující únik z interpretu by se ocitla uvnitř samotné služby. Běžný kontejner už přidává jinou hranici, pořád však sdílí jádro hostitele. Varianta s gVisorem mezi program a hostitelské jádro vkládá další vrstvu; cloudové varianty využívají malé virtuální stroje.
Pro člověka, který kupuje nebo skládá agentickou službu, z toho plyne jednoduchá otázka: které z těchto prostředí používáte pro můj konkrétní běh? Nestačí odkaz na stránku, kde je někde napsáno „izolované“. Plimsoll podle svého popisu vrací úroveň ve výsledku a dovoluje stanovit minimum v každé žádosti. Ve výchozím nastavení bez zvoleného poskytovatele nespouští nic, takže vykonávání kódu musí správce zapnout vědomě.
Ani tato evidence není hardwarově ukotvené kryptografické potvrzení toho, jaký software skutečně běží. Projekt pracuje s konfigurací, informacemi od poskytovatele a provozními kontrolami; u některých prostředí testuje například zákaz síťového provozu a možnosti zápisu. Kompromitovaný správce kontejnerů nebo cloudová řídicí vrstva mohou takové podklady znehodnotit. Tohle omezení není drobným písmem pod reklamou. Rozhoduje o tom, zda nástroj odpovídá rizikům konkrétní firmy.
Nedat programu klíč ještě neznamená zamknout všechny dveře
Druhá zajímavá část je přístup k firemním službám. Podle dokumentace oprávnění pro jednotlivé běhy program může volat vybrané operace přes prostředníka mimo sandbox. Ten kontroluje povolenou cestu a metodu a teprve sám připojí přihlašovací údaj. Kód uvnitř izolovaného prostředí tak nemusí dostat tajný klíč k cílovému API ani obecný přístup na síť.
Představme si opět objednávky. Skript má spočítat, kolik jich čeká na expedici. Potřebuje číst vybraná data, nikoli měnit ceny, rušit objednávky nebo zapisovat do účetnictví. Oddělení přihlašovacího údaje je dobrý začátek, ale skutečnou ochranu určuje seznam operací, které prostředník dovolí. Pokud v něm necháme všechno, odstranili jsme klíč z rukou programu, nikoli jeho moc.
Dokumentace na to upozorňuje u vlastního generátoru pravidel z popisu OpenAPI. Generátor umí připravit seznam dostupných operací, jenže popis služby říká, co služba umí, ne co má smět agent. Správce musí seznam ořezat. Zkopírovat celou nabídku a prohlásit ji za bezpečné oprávnění je administrátorská verze tlačítka „povolit vše“.
Navíc i povolená operace může přenášet data, která přenášet nemá. Bezpečnostní dokumentace Plimsollu výslovně říká, že prostředník kontroluje metodu a cestu, nikoli význam obsahu požadavku. Program může do povoleného volání vložit něco, co předtím přečetl. Zákaz volné sítě tedy není automatickou ochranou před únikem dat přes schválenou službu; rozhodnutí, komu lze která data předat, zůstává na provozovateli.
Chybová hláška není povolení zkusit to znovu
Pro běžnou automatizaci může být nejdůležitější úplně jiná vlastnost: rozlišení mezi „nic neběželo“ a „nevíme, jak daleko běh došel“. Popis výsledků a chyb zavádí zvláštní označení odmítnutí před předáním kódu ke spuštění. Pokud takové označení chybí, dokumentace nepovažuje automatické opakování za bezpečné. Samotný chybový kód nestačí.
Představme si skript, který kromě výpočtu vytváří placenou úlohu v externí službě. Požadavek odejde, odpověď se ztratí a agent dostane chybu. Opakování může vytvořit druhou placenou úlohu, přestože první už běží. Naproti tomu odmítnutí kvůli příliš slabé izolaci před spuštěním znamená jinou situaci: nic z kódu neběželo a požadavek lze podle okolností předat silnějšímu prostředí.
Tento rozdíl jsme už rozebírali v širším komentáři o provozní disciplíně AI agentů. Plimsoll ho přenáší do konkrétního kontraktu mezi klientem a spouštěcí službou. Automatické „zkusím to ještě jednou“ je skvělé při načítání neškodného podkladu. U zápisu, odeslání nebo placeného volání může být právě tím krokem, který z malé provozní poruchy udělá skutečný problém.
Ani kontrolní součet výsledku nedává oprávnění považovat akci za správnou. Dokumentace popisuje obsahové otisky požadavků a výsledků a možnosti jejich ověření či podepisování. Takový záznam pomáhá zjistit, zda máme shodné podklady a zda se nezměnily. Neřekne nám, jestli bylo obchodně správné úlohu objednat, jestli byl výpočet bezchybný nebo zda všechna rizika prostředí opravdu drží pod kontrolou.
Bezpečný běh může vrátit nebezpečnou radu
Izolace chrání okolí před spuštěným programem, ale jeho výstup se často vrací zpět jazykovému modelu. Tam začíná další hranice. Bezpečnostní dokumentace připomíná, že výstup sandboxu je nedůvěryhodný: může obsahovat prompt injection, tedy instrukce vložené do dat s cílem ovlivnit další kroky agenta. Plimsoll výstup v tomto smyslu nezkoumá.
Program může zpracovat cizí dokument a vrátit text, který agenta nabádá k použití silnějšího oprávnění. Skutečnost, že text přišel ze spořádaně izolovaného prostředí, z něj nedělá pokyn správce. Oprávnění pro další běh se nesmějí rozšiřovat jen proto, že si o to řekl výsledek předchozího. Jinak postavíme pevnou zeď kolem programu a vedle ní necháme otevřenou branku v rozhodování modelu.
Stejně je potřeba zacházet se sdílenými relacemi, ve kterých mezi voláními přetrvávají soubory nebo proměnné. Dokumentace je označuje za jeden společný prostor důvěry a upozorňuje, že předchozí kód může ovlivnit další volání. Pohodlnější pokračování práce proto není totéž jako nový čistý běh. U služby pro více zákazníků se jejich relace nesmějí slít do jedné jen proto, že ji obsluhuje společný účet.
Raný projekt, dospělá otázka
Repozitář projektu svůj stav popisuje nezvykle přímo: verze před 1.0, jeden autor a podle jeho aktuálního vyjádření žádní externí uživatelé. Neproběhl nezávislý bezpečnostní audit. Kód má licenci Apache-2.0, což potvrzuje zveřejněný soubor LICENSE, ale otevřená licence není osvědčení pro nasazení k citlivým datům. Tento článek vychází z dokumentace; vlastní provozní nebo penetrační test jsme neprováděli.
Není tedy důvod tvrdit, že Plimsoll vyřešil bezpečnost AI agentů. Je důvod ocenit, že některé sliby převádí na konkrétní pravidla a otevřeně popisuje, kde tato pravidla končí. Odlišuje slabé vývojové prostředí od silnější izolace, tajný klíč od oprávnění provést operaci a záznam běhu od důkazu správnosti. To jsou rozdíly, které bychom měli vyžadovat i od mnohem větších dodavatelů.
V praxi bychom před pilotem chtěli čtyři odpovědi: jakou minimální izolaci každý běh vyžaduje, které operace dostane povolené, kam mohou odejít zpracovaná data a co se stane po nejasném selhání. Ke každé odpovědi patří test odmítnutí, nejen úspěšné demo. A k práci s výsledným kódem patří také běžné ověřování chování; jak jsme psali u vzájemných revizí Claude Code a Codexu, další souhlasné stanovisko modelu nenahrazuje test.
Na AI agentovi nás snadno zaujme, kolik práce zvládne. Na jeho provozní vrstvě by nás mělo zajímat, co mu nedovolí — a zda umí doložit, že mu to skutečně nedovolila. „Běží to v sandboxu“ má být začátek technické debaty, ne její konec. Dokud nevíme, jaké stěny konkrétní běh dostal a které dveře měl povolené otevřít, jen jsme důvěře dali profesionálněji znějící jméno.
