Почему для AI-инфраструктуры нужны доказательства, а не просто права

Ещё недавно правки в продакшене выглядели просто: инженер заходил по SSH и выполнял команды. Сейчас задачи всё чаще перекладывают на AI-агентов — от миграций до обновлений безопасности. И тут уже недостаточно просто «разрешить доступ».

RBAC больше не справляется

Обычная модель доступа строится на двух вещах:

• RBAC говорит, что пользователь может менять продакшен
• GitOps описывает желаемое состояние

Но ни один из этих подходов не отвечает на главный вопрос: почему это изменение безопасно именно сейчас?

Когда команду запускает человек, у него есть опыт и понимание контекста. AI-агент такого контекста не имеет. Он просто запрашивает выполнение. А если речь идёт о миграции базы или обновлении инфраструктуры, где ошибки стоят дорого, проверка одних только прав доступа выглядит недостаточной.

Особенно это заметно в stateful-операциях. Схема, данные, зависимости, тайминги — всё это не описывается в YAML. А система контроля доступа об этом ничего не знает.

Как выглядит контроль на основе доказательств

Идея простая: перед выполнением любое изменение должно пройти криптографическую проверку. Это не замена политик, а дополнительный слой защиты.

Процесс выглядит так:

1. Агент предлагает изменение с обоснованием
2. Система формирует доказательство — криптографический набор данных
3. Политика проверяет, разрешена ли такая операция
4. Проверяется целостность подписи
5. Если всё в порядке — выполняется мутация
6. Создаётся подписанная запись о том, что произошло и почему

В доказательство входят dry-run, проверка drift, security-сканы, SBOM, image digests, SLO-прогнозы и цепочка событий.

Пример: миграция с Oracle на PostgreSQL

Представьте реальную миграцию Oracle/APEX в PostgreSQL в Kubernetes. Это не просто «применить манифест». Здесь десятки шагов: проверка кластера, заморозка источника, экспорт данных, shadow-таблицы, пост-валидация и аудит.

AI-агент, который запускает такую последовательность, должен пройти через 23 проверки, оставить 20 событий и сгенерировать 20 артефактов. Всё подписывается ed25519-ключом и может быть проверено позже.

Политика и доказательство работают вместе

Даже если доказательство прошло проверку, система всё равно требует явного разрешения. В тестах один и тот же запрос отклоняли дважды: сначала из-за отсутствия записи в allow-list, потом — из-за повреждённой подписи. Это и есть защита в глубину.

Что делать дальше

Если вы уже используете Kubernetes и планируете AI-операции, стоит подумать о:

• генерации криптографических доказательств
• policy as code с явными allow-list
• подписанных audit-трейлах
• количественной оценке безопасности изменений

GitOps и RBAC по-прежнему полезны, но они не дают ответа на вопрос «почему это безопасно». А для автономных агентов именно этот ответ становится критически важным.