Jak chránit data před AI agentem, než ti smaže disk
AI agent ti může smazat celý disk i databázi. Ukazuju, jak chránit data před AI agentem přes kontejner, minimální oprávnění a zálohy mimo blast radius.
Obsah článku 8 sekcí
V kostce
- Codex s GPT-5.6 Sol v červenci 2026 smazal téměř všechny soubory na Macu Matta Shumera, přičemž vinné bylo podle článku prostředí, ne model.
- Agenta spouštěj v Docker kontejneru s připojeným jen adresářem projektu a nedávej mu produkční token ani přístup k zálohám.
- Zálohy drž mimo dosah agenta, v jiném účtu nebo regionu, ideálně jako immutable snapshot, jinak je agent smaže spolu s daty.
- Destruktivní operace nech schvalovat ručně a práci agenta veď ve vlastní git větvi s častými commity.
Když Matt Shumer, zakladatel startupu OthersideAI, dal v červenci 2026 svému AI asistentovi Codex rutinní úkol, nečekal, že model označovaný jako GPT-5.6 „Sol" během chvíle smaže téměř všechny soubory na jeho Macu. Když se Shumer zeptal, co se vlastně stalo, agent odpověděl suše: „I caused a serious data-loss incident." Nic se nevrátilo. OpenAI to připisovalo příliš agresivnímu chování verze 5.6 — jenže redaktor newsletteru AI Secret měl soubory smazané stejným způsobem už na předchozím modelu GPT-5.5. Když to samé udělá i starší verze, vinný není model. Vinné je prostředí.
A přesně v tu chvíli by tě mělo zajímat, jak chránit data před AI agentem, kterého sis pustil na vlastní stroj. Incident nebyl o jednom rozladěném modelu, ale o architektuře: agent běžel lokálně, na reálném počítači, mimo jakýkoliv sandbox, jeden špatný příkaz od celého disku. V tomto článku ti ukážu, proč ti lepší model nepomůže, a jak nastavit agenta tak, aby to nejhorší, co dokáže udělat, bylo smazání kontejneru, který přestavíš za pár sekund.
Problém není model, ale blast radius
OpenAI po incidentu záplatovalo instrukce modelu. Jenže to je reakce na symptom, ne na příčinu. Jak upozorňuje technická analýza na eon.io, většina firemních záloh leží ve stejném tzv. blast radius jako samotný agent — tedy ve stejné sadě oprávnění, na stejném disku nebo pod stejným cloudovým účtem. Když agent dostane příliš široká práva, smaže nejen data, ale i zálohy, které by tě měly zachránit.
Klíčový princip zní: nejhorší věc, kterou může agent udělat, musí být omezená na prostředí, které si dovolíš ztratit. Cloudový agent běžící v kontejneru dostane vlastní jednorázové prostředí, a to nejhorší, co smaže, je kontejner, který přestavíš. Lokální agent běžící na tvém pracovním stroji může smazat celou tvou digitální historii — a žádný upgrade modelu s tím nepomůže.
Paralelní případ z České republiky je ještě výmluvnější. Jak popisuje český bezpečnostní portál czechcyber.tv, AI agent poháněný modelem Claude vymazal za devět sekund produkční databázi firmy i její zálohy — protože k tomu měl platné přihlašovací údaje a nikdo ho u rizikové operace nezastavil. Nešlo o chybu modelu. Šlo o příliš široká oprávnění.
Zdroj incidentu s Codexem: AI Secret, „Codex Wiped Entire Machines", 20. července 2026.
Kde se agenti nejčastěji zřítí
Nejčastější destruktivní scénáře nejsou žádná sci-fi. Podle českého rozboru na lock.pub vypadají překvapivě banálně:
- „Vyčisti projekt" → agent smaže soubory, které považuje za nepotřebné, včetně důležitých konfigurací.
- „Optimalizuj databázi" → agent odstraní tabulky nebo smaže data, která pokládá za nadbytečná.
- Špatně zadaná cesta → jeden nepřesný příkaz typu
rm -rfs chybou v cestě smaže adresář, který smazat nechtěl. - Platné, ale příliš silné přihlašovací údaje → agent s produkčním tokenem provede operaci, na kterou neměl mít vůbec právo.
Společný jmenovatel je vždycky stejný: agent má příliš široká oprávnění a nikdo ho při rizikové akci nezastaví. Proto než začneš řešit složité věci, pojmenuj si tyhle čtyři pasti a nauč se je rozpoznat. Schválně si projdi posledních pět úkolů, které jsi agentovi zadal — kolik z nich mohlo skončit jednou z nich?
Jak chránit data před AI agentem: 5 principů
Tady je konkrétní návod, jak nastavit agenta tak, aby ti nemohl zničit práci. Pravidla platí stejně pro Claude Code, Codex, Cursor i Windsurf.
Běž v kontejneru, nikoliv na živém stroji
Nejjednodušší a nejúčinnější změna: nespouštěj agenta přímo na svém Macu nebo na produkčním serveru. Dej ho do Docker kontejneru nebo devcontaineru a namontuj do něj jen adresář konkrétního projektu — ne celý domovský adresář a hlavně ne root. Podrobný postup sandboxu a izolace jsem popisoval v článku o bezpečném spouštění AI coding agenta. Tím, že omezíš, co agent vůbec vidí, snížíš blast radius na jeden jediný projekt.
Princip nejmenších oprávnění
Dej agentovi přístup jen k tomu, co skutečně potřebuje. Produkční token? Nikdy. Přístup k zálohám? Vůbec. Pokud agent pracuje v jednom repozitáři, nepotřebuje vidět databázi, fakturační systém ani obsah ~/.ssh. Tentýž princip platí i opačným směrem: pokud zároveň řešíš, aby agent tvá data nevytěžoval a neuniklo ti know-how, podívej se na návod, jak chránit firemní data v AI před únikem. Dvě různá rizika — únik a zničení — řešíš tou samou disciplínou: minimálními oprávněními.
Zálohy mimo blast radius
Tady se většina týmů zraní. Pokud máš zálohy na stejném disku, ve stejném AWS účtu nebo pod stejným tokenem jako běží agent, agent je smaže spolu s daty. Pravidlo zní: záloha musí být mimo dosah agenta — jiný účet, jiný region, ideálně jiný mechanismus, třeba immutable snapshot, který nejde smazat jediným API voláním. Když czechcyber.tv popisuje případ, kdy agent smazal databázi i zálohy, přesně tohle se stalo: zálohy ležely ve stejném blast radius.
Schvalovací brána pro destruktivní operace
Nastav si pravidlo, že každá operace, která maže, přepisuje nebo posílá data ven, vyžaduje tvé potvrzení. V Claude Code na to slouží hooks a schvalovací brány, v Codexu a Cursoru permission systémy. Agent se zeptá „chceš smazat tento adresář?" a ty klikneš ano. Zní to jako zdržování, ale přes tato potvrzení tě agent naučí respektovat. A pokud řešíš opačný problém — že agent utrácí příliš mnoho peněz — podívej se, jak nastavit limity výdajů AI agenta. Je to stejná myšlenka: agent nesmí mít neomezenou moc, ať už jde o data nebo o peníze.
Git a verzování jako záchranná síť
I když se něco pokazí, verzování tě zachrání. Práci agenta dělej vždy ve vlastní větvi, commiťuj často a nikdy nespouštěj agenta na větvi, kterou si nemůžeš dovolit resetovat. Pokud agent přepíše nebo smaže soubory, git checkout vrátí všechno zpět. Verzování je tvoje poslední linie obrany — a na rozdíl od modelu nikdy neselže.
Signály, že má tvůj agent moc velkou moc
Než se pustíš do nastavování, projdi si rychlý self-check. Pokud platí kdekoliv ano, agent má dnes příliš široká oprávnění:
- Agent běží přímo na tvém pracovním stroji, ne v kontejneru.
- Agent vidí adresáře, které s aktuálním úkolem nemají nic společného (celý home,
~/.ssh, složka s fakturami). - Má uložený produkční token nebo přístup k živé databázi.
- Tvoje zálohy sdílí účet, disk nebo token s prostředím, kde agent běží.
- Agent může spustit
rm,git push --forcenebo mazací API volání bez tvého potvrzení. - Pracuje na hlavní větvi místo vlastní feature větve.
Stačí jedno ano a máš blast radius, který přesahuje jeden projekt. Právě tady se rodí incidenty jako ten Shumerův — ne ze zlého úmyslu modelu, ale z toho, že mu nikdo nenastavil mantinely.
Rychlé nastavení pro tři nástroje
Abys neodešel s teorií, tady jsou konkrétní startovací body pro nejběžnější nástroje:
- Claude Code: zapni
--dangerously-skip-permissionsjen v kontejneru, nikdy na živém stroji. V produkci použij permission systém sdenypravidly prorm -rf,git push --forcea přístup mimo adresář projektu. - Cursor: v
settingsomez agenta na workspace edit a vypni run terminal commands bez potvrzení. Pravidla agenta (.cursor/rules) explicitně zakazuj mazání mimo repozitář. - Codex: spouštěj výhradně v
codex sandboxs read-only mountem domovského adresáře a read-write jen pro adresář projektu. Produkční přihlašovací údaje do prostředí vůbec nedávej.
Před a po: jak se změní tvůj workflow
Rozdíl mezi agentem, který ti smaže disk, a agentem, který ti maximálně rozbije kontejner, není v modelu. Je v nastavení.
| Situace | Před (rizikové) | Po (bezpečné) |
|---|---|---|
| Kde agent běží | Na tvém Macu, plný přístup | V kontejneru, jen adresář projektu |
| Oprávnění | Produkční token, root | Jen repozitář, žádné zálohové tokeny |
| Zálohy | Stejný disk / účet | Jiný účet, immutable snapshot |
| Mazání | Agent maže bez ptaní | Každá destruktivní akce vyžaduje potvrzení |
| Verzování | Agent píše do hlavní větve | Vlastní větev, časté commity |
Když si tohle nastavíš jednou, další nasazení agenta je otázka minut. A co je hlavní — když se agent zblázni, zásah tě vůbec nemine, protože dopad je uzavřený v kontejneru.
Časté otázky
Může se to stát i se sandboxem?
Sandbox riziko drasticky snižuje, ale neodstraňuje ho úplně. V červenci 2026 výzkumníci z Pillar Security v poznámce Cloud Security Alliance z 22. července 2026 popsali úniky ze sandboxů (tzv. sandbox escapes) u čtyř široce používaných AI coding agentů. Proto sandbox vždycky kombinuj s dalšími vrstvami — minimálními oprávněními, schvalovacími bránami a verzováním. Jedna vrstva ochrany nikdy nestačí.
Který nástroj je nejbezpečnější — Claude Code, Codex nebo Cursor?
Bezpečnost nezávisí primárně na nástroji, ale na tom, jak ho nakonfiguruješ. Všechny tři nabízejí sandbox, permission systémy a schvalovací brány. Rozdíl dělá, jestli je skutečně zapneš. Před nasazením si udělej audit bezpečnosti AI agentů — sedm kontrol, které odhalí díry dřív, než je najde útočník nebo agent sám.
Co když agent potřebuje přístup k databázi?
Dej mu přístup jen ke čtení, nebo k vývojové databázi, nikoliv k produkci. Pokud potřebuje zapisovat, ať zapisuje přes schválené API s limity, ne přes přímý administrátorský token. A přihlašovací údaje drž mimo agenta — přes credential gateway, která tokeny vydává za běhu a nikdy je agentovi nedá celé.
Stojí sandboxování nějaký výkon?
V kontejneru je režie zanedbatelná — startup trvá o pár sekund déle. To je nic ve srovnání s hodinami, které ztratíš obnovou smazaných souborů. Bezpečnost tady není trade-off, je to investice s jistým výnosem.
Závěr: lepší prevence než obnova
Incident s Codexem i případ smazané databáze z ČR nejsou výjimky. Jsou ukázkou toho, co se stane, když dáváš agentovi neomezenou moc na místě, kde si nemůžeš dovolit prohrát. Modely se budou zlepšovat, ale řešení je architektonické: nikdy nenech agenta stát na stroji, který si nemůžeš dovolit ztratit.
Pět principů — kontejner, minimální oprávnění, zálohy mimo blast radius, schvalovací brány a verzování — ti dá agenta, který je užitečný, aniž by byl nebezpečný. Nastav si je ještě dnes, než to za tebe vyzkouší realita.
Chceš jít dál? Spoj si sandbox s auditem bezpečnosti AI agentů a budeš mít agenta, který nejen pracuje rychle, ale taky nepřipraví o víkend tým, který ho nasadil.
Kontejner jako první linie
Nejhorší, co může agent udělat, musí být omezené na prostředí, které si dovolíš ztratit. Cloudový kontejner přestavíš za pár sekund, smazaný disk ne.
Záloha mimo blast radius
Pokud zálohy sdílí účet, disk nebo token s agentem, agent je smaže spolu s daty. Drž zálohy v jiném účtu jako immutable snapshot.
Claude AI zdarma 
OpenCode zdarma 
Cursor zdarma 
Codex zdarma 
