Bezpečnost AI coding agentů: chraňte kód i API klíče

Izolujte prostředí, ve kterém agent běží

Pravidlo číslo jedna: agent nikdy nesmí vidět všechno. Ideálně pracuje v izolovaném prostředí, které obsahuje jen to, co skutečně potřebuje.

Co funguje v praxi:

• Docker Dev Container nebo GitHub Codespace — agent vidí jen obsah kontejneru, ne celý disk.
• Vestavěné sandboxy nástrojů. Claude Code dnes umí OS-level sandbox kolem shellových příkazů (macOS Seatbelt, Linux bubblewrap): zápis jen do pracovního adresáře a tmp, síťový provoz výhradně přes lokální proxy s allowlistem domén (network.allowedDomains, ve výchozím stavu prázdný — tedy žádný egress). Codex CLI má síť ve výchozím nastavení úplně vypnutou a v režimu workspace-write chrání .git jen pro čtení.
• Samostatný uživatelský účet na lokálním stroji — bez přístupu k SSH klíčům, prohlížeči nebo osobním dokumentům.
• Omezení sítě — kontejner by neměl volat kamkoli mimo nutná API a registry.

Jednoduchý příklad: pracujete-li na webové aplikaci, vytvořte devcontainer s adresářem projektu, Node.js a testovací databází. Agent neuvidí ~/.ssh, ~/.aws ani historii prohlížeče. I kdyby se něco pokazilo, exfiltrace bude minimální.

Hlubší rozbor sandboxů pro týmy najdete v článku Jak bezpečně nasadit Claude agenty: Sandboxy a MCP tunely.

Tajemství držte mimo dosah agenta

Nejčastější zranitelnost není v agentovi, ale v tom, co mu dáte k dispozici. API klíče, databázová hesla a tokeny nesmějí být v promptu, v kódu ani v souborech, které agent čte.

Základní pravidla:

• Reálné klíče nepatří do .env souborů v projektu. Použijte secrets manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault) nebo 1Password Secrets Automation.
• Claude Code umí nově chránit credentials na úrovni sandboxu: sandbox.credentials s režimy deny (proměnnou agent vůbec nevidí) a mask (agent vidí zástupný sentinel a skutečnou hodnotu dosadí proxy jen směrem k povolené doméně). Tato nastavení se ale čtou jen z uživatelských a firemních settings — repozitář je nemůže přepsat.
• Každý klíč by měl mít minimální práva (least privilege) a sloužit jednomu účelu.
• Klíče pravidelně rotujte — ideálně každých 90 dní, u kritických služeb častěji.

Na veřejném GitHubu se přitom pravidelně objevují tisíce uniklých tokenů v MCP konfiguračních souborech. Není to statistika, ale denní riziko pro každý tým — proto další dva kroky.

Omezte oprávnění agenta a nastavte deny rules

Claude Code, Cursor i Codex nabízejí různé úrovně autonomie. Výchozím režimem by měl být ten nejpřísnější, jaký váš workflow unese.

Claude Code (stav podzim 2026):

• Režimy oprávnění: default (ptá se na každý zásah), acceptEdits, plan, nový dontAsk (vše nepovolené se zamítá) a bypassPermissions. Novinkou je režim Auto, kdy o schválení akcí rozhoduje klasifikační model místo člověka — je nově výchozím režimem interaktivních relací. Pro firemní prostředí si ho rozmyslete: klasifikátor je pohodlný, ale nezná vaši politiku.
• Deny rules (permissions.deny) platí v každém režimu, včetně bypassPermissions. To je správné místo, kam zapsat .env*, *.pem, id_rsa*, credentials/ — ne existuje žádný .claudeignore;deny rules jsou oficiální mechanismus.
• Režimy auto a bypassPermissions nelze zapnout z .claude/settings.json v repozitáři (nedůvěryhodný soubor) — jen z uživatelských nebo managed settings. Firma může oba zakázat centrálně.

Codex CLI: schvalovací politika untrusted byla vypnuta; dnes se kombinují režimy sandboxu (read-only, workspace-write, danger-full-access) s politikou schvalování (on-request, never). Pro firemní agenty začněte na read-only + on-request.

Cursor: ve firemním prostředí vypněte Yolo režim a pravidla pro agenta (.cursorrules) nastavte tak, aby do kódu neukládal tajemství. U GitHub Copilota využijte enterprise politiky.

Auditujte MCP servery a externí nástroje

MCP servery rozšiřují schopnosti agentů, ale zároveň zvyšují útočnou plochu. Agent může skrze MCP server volat externí API, číst soubory nebo měnit produkci. Zvlášť nebezpečné jsou servery z nedůvěryhodných zdrojů — mohou obsahovat skrytou logiku pro exfiltraci (tool poisoning) nebo změnit chování poté, co si jednou nainstalujete (rug pull).

Co ověřit před instalací:

• Je zdrojový kód veřejný a udržovaný?
• Jaká oprávnění server požaduje? Komunikuje seznam nástrojů transparentně?
• Existují recenze nebo bezpečnostní audit?

Specifikace MCP se mezitím posouvá správným směrem: revize z července 2026 zjednodušila handshake, zavedla povinné hlavičky Mcp-Method/Mcp-Name u streamingu a servery musí vracet HTTP 403 u neplatných Origin hlaviček. Starší dobře známá zranitelnost CVE-2025-49596 (RCE) přitom týkala jen vývojářský nástroj MCP Inspector, ne samotné SDK — přesto platí: všechno, co agentovi připojíte, auditujte.

Detailní rozbor máme v návodu MCP servery v produkci: Jak ochránit AI agenty před útokem.

Kontrolujte, co agent vytvoří — včetně screenshotů a nových repozitářů

Lidský review zůstává povinný, zvlášť u autentizace, oprávnění a přístupu k datům. PixelLeak ale ukázal, že nestačí kontrolovat diff: agent může vytvořit nový veřejný repozitář a nahrát do něj interní screenshoty.

Automatizovaná kontrola:

• Secret scanning v pre-commit i CI — gitleaks (aktuálně 8.30) nebo TruffleHog (3.99, aktivní týdenní cadence vydání). Zapněte GitHub Push Protection — blokuje push s tajemstvím ještě před zveřejněním.
• SAST/SCA — Semgrep, CodeQL, Dependabot či Snyk pro závislosti.
• Politika pro repozitáře: agent nesmí zakládat veřejné repozitáře. gh repo create patří do deny rules a firemní skenery by měly kontrolovat i osobní účty vývojářů s firemním kódem (právě tam PixelLeak našel 93 % úniků).
• Policy-as-code — merge se blokuje, když PR obsahuje hardcoded secrets nebo high-severity zranitelnost.

Pro týmy, které agenty nasazují plošně, máme návod AI coding governance: pravidla pro tým, který používá Copilot, Cursor a Claude Code.

Mějte plán na incident

I při nejlepší prevenci může dojít k úniku. Důležité je vědět, co dělat během prvních minut.

Postup při podezření na kompromitaci:

1. Okamžitě odvolejte postižený API klíč nebo token.
2. Izolujte prostředí, ve kterém agent běžel.
3. Zkontrolujte logy použití klíče a fakturaci u poskytovatele.
4. Prohledejte repozitář na uniklá tajemství — git-filter-repo nebo BFG Repo-Cleaner je odstraní z historie.
5. Vygenerujte nové klíče a nasaďte je bezpečně mimo Git.
6. Zdokumentujte incident a aktualizujte interní pravidla.