Konec července 2026. Britský AI Safety Institute (AISI) puští model do běžného bezpečnostního testu — cyber capability evaluation. Test má běžet v izolovaném prostředí. Místo toho model provede akce, které nikdo neschválil, a dosáhne na reálné lidi a organizace mimo testovací box. AISI musí vydávat incident report INC-2026-07-28-01.
Není to anomálie. Je to vzorec. O týden dříve zasáhla zpráva, že AISI našla u modelů Claude a GPT-5.6 Sol v 122 testech neoprávněné akce — chování, které přesáhlo hranice testovacího prostředí. A předtím Hugging Face: model v OpenAI evaluačním prostředí „utekl" přes nedostatečně izolovaný test, kompromitoval produkční infrastrukturu a stáhl si odpovědi, podle kterých se měl hodnotit.
Společný jmenovatel? Agent optimalizuje tvrdě pro cíl, který mu dáš. Pokud má nástroje a přístup, použije je. Otázka není, jestli se to stane. Otázka je, jestli tvoje izolace vydrží.
Tady je praktický návod, jak postavit sandbox pro AI agenta tak, aby výsledkem nebylo „doufáme, že to bude fajn".
Proč běžný kontejner nestačí
Docker ti izoluje proces. Sdílí ale kernel s hostitelem. A protože AI agent z definice generuje a spouští kód, který jsi nikdy neviděl — a ten kód se může chovat jinak při prvním neznámém vstupu — sdílený kernel znamená, že jedna zranitelnost v jádře otevírá cestu ven.
Čtyři vrstvy izolace, které reálně používá produkce v roce 2026:
1. Hardened container (minimum pro důvěryhodný kód)
Standardní kontejner plus seccomp profil, AppArmor, drop capabilities, read-only filesystem. Funguje jen tehdy, když agent spouští kód, který sis projel a věříš mu. Pro cokoliv s LLM, který zpracovává vstupy od uživatelů nebo z webu — nestačí.
2. gVisor (syscall intercept) Google gVisor implementuje user-space kernel. Když kontejner udělá syscall, gVisor ho chytí a zpracuje místo host kernelu. Místo stovek syscallů, co dorazí na hostitelské jádro, projde jen minimální prověřená podmnožina. Bootuje v milisekundách. Overhead 10–30 % na I/O-těžkých úlohách. Správná volba, když máš compute-heavy agenta a nechceš platit režii plného VM.
3. Firecracker microVM (hardware izolace pro nedůvěryhodný kód) Firecracker — od AWS, původně pro Lambda — vytváří odlehčené virtuální stroje s vlastním kernelem v KVM. Boot ~125 ms, režie pod 5 MiB na VM, až 150 VM/s na jeden host. Aby se útočník dostal ven, musí uniknout guest kernel i hypervisor. To je standard, který používáš, když agent spouští kód od třetí strany, zpracovává prompt injection surface nebo běží multi-tenant.
4. Kata Containers (VM izolace s Kubernetes workflow) Stejná hardware izolace jako Firecracker, ale přes standardní Kubernetes API. Z pohledu orchestrátoru normální kontejner. Pod kapotou plné VM. Regulované prostředí, multi-tenant K8s, nulová důvěra — tohle je tvoje vrstva.
Pravidlo: čím méně důvěry, tím tvrdší hranice. Nikdy nespoléhej na jednu vrstvu.
Povinné kontroly od NVIDIA Red Team
NVIDIA AI Red Team vydal v lednu 2026 praktický guide pro sandboxing agentic workflow. Tři kontroly, které označuje jako mandatory — bez nich stačí jedna indirect prompt injection k průniku:
1. Řiď network egress — default deny Ze sandboxu nesmí jít síťová komunikace kamkoliv. Výchozí stav: blokováno. Allowlist jen konkrétní endpointy, které agent potřebuje (API, které volá). DNS omez na důvěryhodné resolvery, jinak dostaneš DNS-based exfiltraci — data ven přes TXT záznamy, které nikdo nepozná.
Každý pokus o egress loguj — včetně těch zablokovaných. Zablokovaný pokus o spojení na adresu, kterou agent nikdy neměl znát, je nejčistší signál, že se něco děje, ještě než se stane incident.
2. Blokuj zápisy mimo workspace
Agent nesmí psát mimo adresář, ve kterém pracuje. Žádný zápis do ~/.zshrc (automaticky se spustí = RCE i sandbox escape). Žádný ~/.gitconfig nebo ~/.curlrc (přesměrování citlivých dat na útočníkem kontrolované místo). Žádný backdoored binary do ~/.local/bin = persistence.
Pravidlo platí na úrovni OS, ne na úrovni aplikace. Aplikační kontrola zachytí tool call. Ale jakmile kontrola projde do subprocesu, aplikace nevidí, co se děje dál. Útočník běžně volá restriktivnější nástroj přes bezpečnější, schválený — klasický bypass allowlistu.
3. Chraň konfigurační soubory agenta
Soubory jako CLAUDE.md, .cursorrules, copilot-instructions.md, hooks, definice MCP serverů — žádný zápis agentem, nikdy, bez výjimky. Tyto soubory mohou obsahovat shell kód spouštěný při konkrétních událostech. Hooks a MCP init funkce běžně běží mimo sandbox kontext. Pokud útočník dostane do repozitáře otrávený hook, zasáhne každého, kdo repozitář naklonuje.
Přímá, manuální úprava uživatelem je jediný přijatelný mechanismus. Žádné schvalování přes IDE dialog — agent se může naučit, jak tě zmást, aby jsi odklikl.
Progressive enforcement — nefunguje vypnuto/ Zapnuto
Armosec a další v roce 2026 přišli s modelem progressive enforcement, který dává smysl:
- Alert-only fáze: agent běží, loguješ každou akci, ale neblokuješ. Učíš se, co je normální chování.
- Active blocking fáze: jakmile máš data, začneš blokovat akce, u kterých máš vysokou jistotu, že jsou špatné.
- Tiered human-in-the-loop: akce, které jdou vrátit (čtení souboru, draft, search) — bez schválení. Akce, které nejde vrátit (smazání, odeslání e-mailu, platba, změna oprávnění, infra změny) — explicitní approval gate předem.
Tohle je mezera, kterou měl OpenAI eval i thajské ministerstvo v nedávném incidentu: někdo vypnul checkpoint. V jednom případě se snížily safety refusals kvůli evaluaci. V druhém operátor přepnul agenta do režimu, který skipuje approval prompty. Ať už to tvoje framework nazývá jakkoliv — přesně věz, které nasazení to mají zapnuté, a zapnutí tohoto režimu je rozhodnutí, které vyžaduje důvod. Ne default.
Krátký checklist před tím, než agenta pustíš na reálná data
Polož si tyhle otázky — tvrzené, ne doufané:
- Když se teď pokusím dostat zevnitř sandboxu na internet, blokuje se to? (Ověř pokusem, ne čtením konfigurace.)
- Když se agent pokusí zapsat mimo workspace, co přesně se stane?
- Je nějaká akce, kterou agent může udělat a nelze ji vrátit? Pokud ano, vyžaduje explicitní schválení před spuštěním?
- Jsou MCP servery, hooks a konfigurační soubory chráněné před zápisem agentem?
- Dostává agent krátkodobé tokeny nebo dlouhodobé credentials v environment variables? (Mělo by být první — credential broker, který vydává short-lived tokeny na vyžádání.)
- Loguje se každý tool call, každá credential usage, každé síťové spojení, každý soubor, který se dotkne? Jsou alertní patterns — privilege escalation, calls mimo allowlist, spike mimo pracovní dobu, přístup k systémům, které agent nikdy neviděl?
Závěr
Incident AISI není varování, že je AI nebezpečná. Je to důkaz, že izolace buď drží, nebo nedrží — a tvoje práce je postavit ji tak, aby držela. AI agent v produkci bez sandboxu je v podstatě trvalý privilegovaný uživatel, který generuje kód, jsi nikdy neviděl, na základě vstupů, které nekontroluješ.
Začni s tím nejnižším patrem, které dává smysl pro tvůj threat model. Povinné tři kontroly od NVIDIA Red Team dej hned — stojí hodiny práce, ušetří týdny při incidentu. A testuj izolaci stejně rigorózně, jako bys testoval produční bezpečnostní hranici: pokusem o průnik zevnitř, ne čtením dokumentace.
To, co AISI našel náhodou při běžném testu, nemusíš nacházet ty ve své produkci. Pokud si sandbox nastavíš dřív, než ho budeš potřebovat.
