Proč AI v infrastruktuře potřebuje důkazy, ne jen oprávnění

Ještě nedávno stačilo, když zkušený admin přes SSH spustil pár příkazů a spoléhal se na to, že dokumentace je aktuální. Dnes už ale AI agenti řeší složité úkoly – migrace databází, úpravy kapacity nebo bezpečnostní záplaty. A tady se ukazuje, že klasický přístup k zabezpečení už nestačí.

Problém RBAC v době AI agentů

Většina firem stále spoléhá na dvě věci:

• RBAC říká, kdo smí měnit produkci
• GitOps definuje, jak by měl systém vypadat

Ani jedno ale neodpovídá na otázku: Proč je právě tato změna teď bezpečná?

Když změnu provádí člověk, přináší s sebou kontext a zkušenosti. AI agent ale žádný takový vhled nemá. Klasické oprávnění jen zkontroluje, jestli má právo něco měnit. Neřeší, jestli je samotný postup rozumný.

To je obzvlášť riskantní u operací, které nelze vrátit zpět – například migrace schématu nebo přesun dat mezi systémy.

Jak by měla vypadat evidence-based kontrola změn

Lepší přístup spočívá v tom, že každá navrhovaná změna dostane kryptografický důkaz o své bezpečnosti. Princip je jednoduchý:

1. Agent navrhne změnu včetně zdůvodnění
2. Systém vygeneruje důkaz – například dry-run proti skutečné infrastruktuře
3. Policy engine zkontroluje, jestli změna odpovídá pravidlům
4. Ověří se integrita podpisů
5. Změna se spustí, jen pokud vše projde
6. Vše se zaznamená do auditu s možností pozdějšího přehrání

Součástí důkazu bývají detekce driftu, kontrola image, SBOM nebo predikce dopadu na SLO.

Příklad z praxe: migrace z Oracle do PostgreSQL

Představte si přesun Oracle/APEX aplikace do PostgreSQL v Kubernetes. Nejde o testovací prostředí, ale o reálnou migraci s živými daty. Taková operace zahrnuje desítky kroků – od zamrznutí zdroje přes export dat až po ověření integrity po přepnutí.

Když takovou sekvenci navrhne AI agent, systém vygeneruje důkaz obsahující 23 validačních kontrol, 20 událostí a 20 samostatných artefaktů. Výsledek? 100% release score a podpis klíčem ed25519.

Důkaz i politika – obojí je potřeba

Zajímavé je, že i při platném důkazu může být změna zamítnuta. V testech se stalo, že agent dostal dvakrát odmítnutí:

• Poprvé chybělo explicitní povolení v seznamu
• Podruhé byl důkaz zfalšován – podpis neprošel

To ukazuje, proč nestačí spoléhat jen na jedno opatření.

Co to znamená pro vaši infrastrukturu

Nástroje jako Argo CD nebo Crossplane vznikly dřív, než se AI agenti stali běžnou součástí provozu. Stále mají smysl, ale neřeší otázku, proč je konkrétní změna bezpečná.

Pokud plánujete AI-asistované nasazení, autonomní škálování nebo složité migrace přes více cloudů, potřebujete systém, který dokáže každou změnu vysvětlit kryptograficky.

Co s tím dělat

Začněte tím, že se podíváte na čtyři oblasti:

• Generování důkazů při každé změně
• Politiky jako kód s explicitními pravidly pro agenty
• Podepsané a přehratelné auditní záznamy
• Hodnocení rizika změny před jejím spuštěním

Infrastruktura se mění směrem k autonomním operacím. I kontrola změn se musí posunout – od „má oprávnění“ k „tady je důkaz, že je to bezpečné“.