Bezpečnostní problém, o kterém nikdo nemluví

Pojďme být upřímní. Většina technických týmů vůbec netuší, kolik AI coding agentů u nich aktuálně běží. Cursor, Claude Code, GitHub Copilot, Gemini CLI, vlastní interní nástroje — seznam se rozrůstá každý měsíc. Každý z nich má své vlastní nastavení, svůj vlastní model oprávnění a svou vlastní interpretaci toho, co vlastně znamená „bezpečné".

Nejde o hypotetický problém. Takto vypadá současná realita firemní AI.

Anthropic nedávno zveřejnil svůj přístup k zabezpečení agenta Claude — a stojí za to se jím zabývat. Ne proto, že by šlo o nějakou kouzelnou technologii, ale proto, že odhaluje fundamentální napětí mezi schopnostmi AI a organizační kontrolou. Anthropic může své agenty zabezpečit, protože vlastní úplně vše: model, runtime, síťovou cestu, governance framework. Vaše organizace takovou luxusní pozici nemá. Místo toho máte změť nástrojů třetích stran, autonomii vývojářů a bezpečnostní politiky, které vznikaly v době, kdy AI agenti ještě neuměli číst soubory, spouštět shell příkazy a přistupovat k síti.

Co Anthropic dělá správně

Sandbox-runtime, který vydali, je elegantní ve své jednoduchosti. Funguje na principu deny-by-default egress: pokud se agent běžící uvnitř sandboxu pokusí připojit k neautorizovanému endpointu, požadavek zemře na proxy vrstvě. Žádná exfiltrace, žádný callback, žádné škody.

Toto je ten druh deterministické bezpečnosti, který skutečně funguje. Místo toho, abyste spoléhali na to, že model „pochopí", že by neměl krást přihlašovací údaje, stavíte tvrdou hranici, která krádež přihlašovacích údajů fyzicky znemožňuje — bez ohledu na to, co se agent rozhodne dělat.

Anthropic organizuje svou obranu do tří vrstev, seřazených podle spolehlivosti:

1. Environment layer — Tvrdé hranice jako VM sandboxy, režimy mountování souborového systému a síťové allowlisty. Toto je základ.

2. Model layer — Behaviorální kontroly jako system prompty, klasifikátory a schvalovací toky. Užitečné, ale výslovně uznávané jako „nikdy 100% efektivní".

3. External content layer — Správa toho, jaká data se k agentovi vůbec dostanou, včetně auditu MCP serverů a kontroly výstupů nástrojů.

Klíčový je právě ten ranking. Environment layer odvádí těžkou práci. Model layer je užitečný doplněk. External content layer je váš systém včasného varování.

Útok, o kterém nikdo nemluví

Abstraktní threat modely se dají snadno ignorovat. Konkrétní příklady už jsou těžší odbýt.

Zamyslete se nad tímto scénářem, který bezpečnostní výzkumníci reprodukují pravidelně: Vývojář si naklonuje repozitář, aby vyhodnotil open-source knihovnu. README vypadá v pořádku. Byl prověřen na malware a prošel všemi kontrolami.

Ale někde v tom README jsou instrukce pro AI agenta. Ne pro člověka, který ten soubor čte — pro agenta, který by ho mohl ingestovat jako kontext. Injectnutý prompt říká agentovi, aby „nastavil vývojové prostředí" tím, že najde .env soubory, vyhledá AWS credentials a nahraje je na setup endpoint.

Toto není malware. Je to jen text. Scanner nic neoznačí. Vývojář si ničeho nevšimne. Ale agent instrukce následuje, protože to agenti dělají — vykonávají úkoly vložené do kontextu, který dostanou.

Útok se odvíjí v krocích: nejprve hledání environment souborů, pak pátrání po upload a exfiltrace code pathech, nakonec finální curl požadavek na útočníkův endpoint. Každá akce sama o sobě vypadá nevinně. Dohromady ale tvoří krádež přihlašovacích údajů.

Proč váš laptop nestačí

Tady je ta nepříjemná realita: pokud ten agent běží v správně nakonfigurovaném sandboxu, útok selže na síťové vrstvě. Curl požadavek nikdy nedosáhne útočníka. Credential nikdy neopustí stroj.

Ale to horší je: vaše bezpečnostní tým vůbec neví, že se to stalo.

Sandbox obsahuje škody. Neobsahuje viditelnost. Možná právě teď běží desítky kompromitovaných repozitářů, každý z nich testuje vaše agenty, každý pokus tiše zablokovaný, zatímco váš SIEM nezaznamenává nic užitečného.

Toto je ten firemní problém. Nestačí zastavit jednotlivé útoky. Potřebujete vědět, že se dějí, kdo byl cílem, které repozitáře zablokovat a jak napsat politiku, která pokryje každého agenta ve vaší organizaci — ne jen toho, co běží v sandboxu.

Slepý úhel MCP serverů

Toto je část, která většinu týmů překvapí: Model Context Protocol servery jsou nejpodceňovanější attack surface při nasazení AI agentů.

MCP servery rozšiřují, co vaši agenti můžou dělat. Můžou číst z databází, volat API, spouštět kód a přistupovat k systémům, které leží mimo vaši infrastrukturu. Když schválíte MCP server, v podstatě agentovi udělujete zvýšená oprávnění napříč celým prostředím.

Problém? Většina týmů schválí MCP servery jednou a už je nikdy neauditují. Kompromitovaný nebo malicious MCP server může napáchat daleko větší škody než otrávený README, protože operuje na vyšší úrovni oprávnění a často přetrvává napříč session.

Váš governance framework musí s MCP servery zacházet jako s third-party závislostmi: auditované, verzované a monitorované. Agent, který může přistupovat k vaší produkční databázi přes MCP server, je agent, který může exofiltovat celou vaši customers tabulku, když se něco pokazí.

Co s tím můžete skutečně dělat

Nic z toho není neřešitelné, ale vyžaduje to, abyste bezpečnost AI agentů začali brát jako infrastrukturní problém, ne jako problém developer tools.

Začněte s environment layer. Kde jen to je možné, provozujte agenty v izolovaných prostředích s deny-by-default síťovými politikami. Vaši vývojáři si budou stěžovat na friction. Méně než vy, až credentials uniknou.

Přijměte, že model layer není dokonalý. System prompty a klasifikátory snižují riziko, ale neodstraní ho. Schopnější modely jsou lepší v hledání nečekaných cest kolem omezení. Počítejte s tím.

Auditujte svoje MCP servery. Udělejte seznam každého MCP serveru, ke kterému vaši agenti mají přístup. Zacházejte s tím jako se software inventářem. Odstraňte cokoliv, co nepoznáváte nebo nemůžete auditovat.

Investujte do observability. Blokování útoků je dobré. Vědět, že se staly, je lepší. Váš bezpečnostní tým potřebuje viditelnost napříč každým agentem ve vaší organizaci, ne jen tím, co běží v sandboxu.

Pište politiky, ne preference. „S credentials zacházej opatrně" není bezpečnostní politika. „Agenti nesmí iniciovat síťová spojení na neallowlistované domény při přístupu k repozitářům označeným jako externí" je bezpečnostní politika. Udělejte pravidla explicitní, vymahatelná a konzistentní.

Závěr

Anthropicova otevřenost ohledně jejich agent containment je skutečně cenná. Ukazuje, co je možné, když jedna organizace kontroluje celý stack. Ale většina organizací takovou kontrolu nemá a předstírat jinak je způsob, jak dochází k bezpečnostním incidentům.

Agenti už ve vaší organizaci běží. Otázka není, zda je zabezpečit — ale zda budete tým, který přijde na governance dřív, než se něco pokazí.

Vaši vývojáři jedou rychle. Ujistěte se, že vaše infrastruktura drží krok.