Защо AI инфраструктурата се нуждае от доказателства, а не само от права

Още преди няколко години промените в инфраструктурата изглеждаха по-просто. Администраторът влизаше директно на сървъра и изпълняваше команди, разчитайки на документацията. Днес AI агентите поемат сложни задачи – миграции, мащабиране, security ъпдейти. И въпросът вече не е „има ли права“, а „защо тази промяна е безопасна точно сега“.

Традиционните модели за контрол вече не стигат.

RBAC не отговаря на въпросите на AI ерата

Повечето компании все още разчитат на RBAC и GitOps. Първият казва „този потребител може да пише в production“, вторият определя „какво състояние искаме“. Но нито едното, нито другото обяснява защо конкретната промяна е безопасна в дадения момент.

Когато човек изпълнява команда, той носи контекст и опит. При AI агент липсва точно това – обяснението зад действието. Това е особено рисковано при stateful операции като database миграции или промени в конфигурацията, където всяка стъпка е необратима и зависи от предишните.

Доказателствата като нов слой за сигурност

По-добрият подход е всяка промяна да се обгърне с криптографско доказателство преди изпълнение. Това не е просто permission check, а цялостна валидация.

Процесът изглежда така:

1. Агентът предлага промяната с подробно описание
2. Системата генерира доказателство за безопасност
3. Policy engine проверява дали промяната отговаря на правилата
4. Проверява се дали подписите са валидни
5. Промяната се изпълнява само ако всичко мине
6. Създава се пълен запис на действието и причината

Доказателството включва dry-run резултати, проверка за drift, security сканиране, SBOM, image digests и прогноза за влияние върху SLO.

Реален пример: миграция от Oracle към PostgreSQL

Представете си миграция на Oracle/APEX система към PostgreSQL в Kubernetes – с живи данни и нулев толеранс към грешки. Това включва десетки стъпки: проверка на клъстера, freeze на източника, експорт на данни, създаване на restore точки, shadow таблици, row-by-row валидация и финално пренасочване на трафика.

Когато AI агент поиска да изпълни тази последователност, proof gate-ът събира 23 проверки, 20 flight events и 20 proof artifacts. Всичко се подписва с ed25519 ключ и може да се верифицира по всяко време.

Двойна защита: proof + policy

Дори когато доказателството е налице, системата изисква и изрично разрешение. В тестове агентът е бил отказан два пъти – веднъж защото липсва allow-list, втори път защото подписът е бил манипулиран. Това е defense in depth за AI инфраструктурата.

Защо това става важно сега

GitOps инструментите като Argo CD и Crossplane са създадени преди AI агентите да станат част от ежедневната работа. Те могат да кажат кой има права и какво е желаното състояние, но не могат да обяснят защо дадена промяна е безопасна.

С разрастването на AI-assisted deployments, autonomous scaling и compliance-тежки workloads, инфраструктурата трябва да предоставя криптографски доказателства за всяка production промяна.

Какво да направите

Ако работите с Kubernetes и сложни миграции, започнете с четири неща:

• Proof generation – дали системата може да създава криптографски доказателства
• Policy as code – ясни allow-lists за агентски операции
• Audit trails – подписани записи на всяка мутация
• Gate scoring – количествена оценка за безопасност

Инфраструктурата се движи към автономни операции. Вашият change control трябва да се промени заедно с нея – от „има ли права“ към „ето доказателството, че е безопасно“.