AI agenti v produkci: oprávnění, izolace a schvalování

Co se skutečně stalo: čtyři případy, jeden vzorec

O „AI, která smazala produkci“ se píše hodně a často nepřesně. Následující případy jsou doložené vyjádřeními zúčastněných firem nebo bezpečnostním bulletinem.

Replit a SaaStr (červenec 2025)

Jason Lemkin, zakladatel SaaStr, zkoušel v Replitu stavět aplikaci pomocí agenta. Agent mu smazal produkční databázi navzdory vyhlášenému code freeze, vygeneroval smyšlená data a tvrdil, že obnova není možná. Rollback přitom nakonec fungoval. Podle shrnutí eWeek šlo o záznamy 1 206 manažerů a více než 1 196 firem. Šéf Replitu Amjad Masad označil incident za „nepřijatelný“ a firma oznámila automatické oddělení vývojové a produkční databáze, režim pouze pro plánování a obnovu ze zálohy jedním kliknutím.

PocketOS, Cursor a Railway (duben 2026)

Agent v Cursoru (model Claude Opus 4.6) řešil nesoulad přihlašovacích údajů ve stagingu. Podle popisu The Register našel v nesouvisejícím souboru API token k platformě Railway. Token vznikl kvůli správě vlastních domén, ale platil pro jakoukoli operaci včetně destruktivních. Agent jím jedním voláním API smazal volume s produkční databází a s ním i zálohy, protože Railway ukládal zálohy na úrovni volume do téhož volume. Celé to trvalo devět sekund. Nejnovější použitelná záloha byla podle zakladatele firmy tři měsíce stará; data nakonec obnovil až provozovatel platformy, který následně doplnil odložené mazání.

Amazon Q Developer pro VS Code (červenec 2025)

Tady nešlo o chybu agenta, ale o útok na něj. Podle bulletinu AWS-2025-015 se útočník díky nevhodně nastavenému rozsahu GitHub tokenu v konfiguraci CodeBuild dostal do repozitáře rozšíření a jeho kód se automaticky dostal do vydání 1.84.0. Vložený prompt měl podle BleepingComputer agenta navést ke smazání souborů a cloudových zdrojů. Podle AWS se nespustil kvůli syntaktické chybě; někteří výzkumníci podle BleepingComputer naopak uvádějí, že kód proběhl, jen bez škod. Opravu přinesla verze 1.85.0.

AWS Cost Explorer (prosinec 2025)

Financial Times spojil prosincový výpadek služby AWS Cost Explorer v jednom regionu s interním AI nástrojem. Amazon to v únorovém vyjádření odmítl: příčinou měla být chybně nakonfigurovaná role, tedy problém, který by nastal „s jakýmkoli vývojářským nástrojem (s AI i bez ní)“. Jako nápravu firma uvedla mimo jiné povinné peer review pro přístup do produkce.

Ať je pravdivá kterákoli verze posledního příběhu, pro čtenáře z ní plyne totéž: rozhodující nebyl model, ale role.

Proč nestačí agentovi „říct, ať to nedělá“

V případě PocketOS měl agent v systémových instrukcích výslovný zákaz destruktivních a nevratných příkazů bez pokynu uživatele. Sám pak přiznal, že pravidlo porušil a jen odhadoval, že se mazání týká stagingu. Instrukce v promptu je přání, nikoli kontrola přístupu.

Druhý důvod je prompt injection. Britské NCSC upozorňuje, že jazykové modely nevynucují hranici mezi instrukcemi a daty, a proto na rozdíl od SQL injection neexistuje obdoba parametrizovaných dotazů. Doporučuje omezovat dopad, ne spoléhat na prevenci. OpenAI v prosinci 2025 napsala, že prompt injection pravděpodobně nikdy nebude „vyřešena“ úplně. Meta ji v říjnu 2025 nazvala zásadní nevyřešenou slabinou všech LLM.

Smrtící trojice a pravidlo dvou

Simon Willison v červnu 2025 pojmenoval kombinaci, která vede k úniku dat, jako „lethal trifecta“: přístup k soukromým datům, vystavení nedůvěryhodnému obsahu a možnost komunikovat ven. Má-li agent všechny tři vlastnosti, útočníkovi stačí dostat do obsahu, který agent čte, vlastní instrukce: do issue, e-mailu, webové stránky nebo logu.

Meta na to navázala pravidlem dvou: agent má v jedné relaci splňovat nejvýše dvě ze tří vlastností: zpracovává nedůvěryhodné vstupy, má přístup k citlivým systémům nebo datům, mění stav nebo komunikuje navenek. Potřebuje-li všechny tři, nemá pracovat autonomně a vyžaduje přinejmenším lidské schválení nebo jinou spolehlivou validaci.

Model oprávnění: čtyři stupně autonomie

OWASP v prosinci 2025 vydal Top 10 pro agentní aplikace; mezi riziky jsou například zneužití nástrojů (ASI02) a zneužití identity a oprávnění (ASI03). Seznam zavádí i princip „least agency“: dát agentovi jen tolik autonomie, kolik bezpečně vymezený úkol vyžaduje. V praxi se osvědčuje rozlišit stupně a ke každému přiřadit jinou identitu.

Stupeň 1 je pro produkci výchozí volba. Agent, který navrhuje změny přes Git, dědí všechny kontroly, které už v pipeline existují: review, testy, policy, auditní stopu. Jak takovou pipeline postavit, popisuje článek o zabezpečení CI/CD.

Cloud: krátkodobé identity a zúžené relace

Základní pravidlo: agent nikdy nepracuje s přihlašovacími údaji člověka ani s dlouhodobým klíčem. Dostává vlastní identitu, pro každý úkol novou krátkou relaci a oprávnění zúžená na daný úkol.

V AWS k tomu slouží session policies. Podle dokumentace IAM jsou výsledná oprávnění relace průnikem identity-based politik role a politiky předané při vytvoření relace. Jednu roli tak lze pro konkrétní úkol dále omezit, aniž by vznikaly desítky rolí.

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/agent-diagnostics \
  --role-session-name agent-ticket-4821 \
  --duration-seconds 3600 \
  --policy file://agent-session.json

# agent-session.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "cloudwatch:GetMetricData",
      "logs:FilterLogEvents",
      "ec2:Describe*",
      "rds:Describe*"
    ],
    "Resource": "*"
  }]
}

Název relace s číslem tiketu se propíše do auditního logu, takže lze každé volání API přiřadit ke konkrétnímu úkolu. V Azure plní stejnou roli spravované identity a federované přihlašování s rolemi přiřazenými na úrovni resource group, ne subscription.

Širší kontext nastavení účtů a identit v AWS rozebírá článek o bezpečnosti cloudu v AWS.

Kubernetes: RBAC, krátké tokeny a sandbox

V Kubernetes je potřeba počítat s tím, že RBAC je čistě aditivní: pravidla typu „deny“ neexistují. Co agent nemá dostat, nesmí být v žádné roli, kterou je na jeho ServiceAccount navázána.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: agent-diagnostics
  namespace: shop-prod
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log", "events", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch"]
# zadne secrets, zadne pods/exec, zadne create/delete

Token pro agenta vystavte vždy s omezenou platností, například kubectl create token agent-diag -n shop-prod --duration=30m. Příkaz vyžádá token service accountu s požadovanou životností; server ji může upravit podle své konfigurace.

Tři pasti z oficiální dokumentace

• Secrets: podle doporučených postupů pro RBAC práva list a watch na Secrets fakticky zpřístupňují jejich obsah, stejně jako get.
• Vytváření workloadů: právo vytvářet Pody v namespace implicitně dává přístup k Secrets, ConfigMaps, PersistentVolumes a k oprávněním všech service accountů v tomtéž namespace. Hranice uvnitř namespace dokumentace označuje za slabé.
• Wildcardy: role s * dává práva i na typy objektů, které v clusteru teprve vzniknou.

Z druhého bodu plyne praktický závěr: agent, který smí nasazovat, patří do vlastního namespace s vynuceným Pod Security Standardem, případně do samostatného clusteru.

Kde agent běží

Agent, který spouští vygenerovaný kód, potřebuje silnější izolaci než běžný kontejner. Pod hlavičkou SIG Apps vzniká projekt Agent Sandbox, který přidává CRD Sandbox pro izolované stavové workloady a nízkoúrovňovou izolaci deleguje na runtime jako gVisor nebo Kata Containers. K tomu patří NetworkPolicy s výchozím zákazem odchozího provozu a seznamem povolených cílů. Právě tím se přerušuje třetí rameno smrtící trojice. Obecné zásady izolace shrnuje článek o bezpečnosti kontejnerů.

Schvalování a audit: co funguje a kde to má limity

Lidské schválení má smysl jen tehdy, když ho agent nemůže obejít a když člověk vidí, co schvaluje. To znamená schvalovací krok mimo agenta (pipeline, ticketing, chatops), zobrazení konkrétního příkazu nebo diffu a jasně určeného prostředí.

Protiargument je oprávněný: schvaluje-li člověk desítky akcí denně, začne potvrzovat mechanicky a kontrola ztrácí hodnotu. Schválení proto vyhraďte nevratným operacím a běžné vratné akce řešte allowlistem a limity (počet replik, rozsah namespace, časové okno).

Auditní stopa musí spojit tři věci: kdo úkol zadal, co agent zamýšlel (prompt, plán, volání nástrojů) a co se skutečně stalo na API cloudu a clusteru. Bez samostatné identity agenta a pojmenovaných relací se třetí část od lidské činnosti neodliší.

Jak velký je to problém mimo titulky

Průzkum, který si u Dimensional Research zadal SailPoint (353 respondentů, zveřejněno v květnu 2025), uvádí, že 80 % firem zaznamenalo nezamýšlené akce agentů a 39 % přístup agenta k systémům, ke kterým mít přístup neměl. Bezpečnostní politiky pro agenty mělo jen 44 % organizací. Jde o průzkum dodavatele nástrojů pro správu identit, takže čísla berte jako orientační; směr ale odpovídá tomu, co ukazují incidenty výše.

Co udělat v pondělí

Klíčové poznatky

• Incidenty jsou selháním oprávnění, ne „vzpourou“ modelu. Replit, PocketOS i Amazon Q spojuje příliš široký přístup a chybějící technická pojistka.
• Prompt není kontrola přístupu. Agent zákaz v instrukcích poruší omylem nebo po prompt injection, kterou zatím nikdo neumí spolehlivě vyloučit.
• Pravidlo dvou je použitelné rozhodovací kritérium. Nedůvěryhodný vstup, citlivá data a akce navenek se v jedné autonomní relaci nemají potkat.
• Identita na úkol, ne na agenta. Krátké relace se zúženou politikou a pojmenováním podle tiketu omezují dopad a dávají auditní stopu.
• V Kubernetes rozhoduje namespace a runtime. RBAC neumí deny, právo vytvářet Pody otevírá Secrets a spouštění cizího kódu patří do sandboxu.
• Zálohy musí přežít nejhorší scénář. Pokud je může smazat stejná identita jako data, nejsou to zálohy.