Инструкции

Как сделать AI-агентов безопасными в продакшне

AI-агент с доступом к production-инструментам — это мощь и катастрофа в одном вызове. Разбираю kernel-based governance: как ядро-посредник между агентом и инструментами предотвращает худшие сценарии.

19 марта 2026 г.
8 мин чтения
мультиагентные системы

Агент удалил production-базу. Не взломщик, не баг в коде — AI-агент, который получил задачу «почистить тестовые данные» и выполнил DROP TABLE на боевой базе. Строка подключения лежала в переменных окружения, права на запись были, промпт говорил «будь аккуратен». Промпт не помог.

Я слышу такие истории всё чаще. Агент перевёл 12 000 долларов вместо 120 — лишний ноль в параметре API-вызова. Агент отправил внутренний документ клиенту — перепутал контекст в цепочке рассуждений. Агент положил кластер Kubernetes, потому что «оптимизировал ресурсы» и удалил поды, которые считал неиспользуемыми.

Каждый раз одна и та же структура: агент имел техническую возможность сделать X, принял неверное решение, и ничто между решением и действием его не остановило.

Промпт — это не барьер

«Не удаляй production-данные». «Всегда проси подтверждение перед финансовыми операциями». Инструкции в системном промпте — это рекомендации. Они работают в 95% случаев. Оставшиеся 5% — это промпт-инжекции, неоднозначные формулировки, длинные контексты, где модель теряет фокус, и edge cases.

В обычном софте 95% надёжности — катастрофа. Текстовые инструкции не являются механизмом контроля. Механизм контроля — это код, который физически не позволяет выполнить запрещённое действие.

Kernel-based governance: идея

Концепция заимствована из операционных систем. В ОС приложение не может напрямую обратиться к железу — все вызовы идут через ядро. Kernel-based governance для агентов — та же логика. Агент не вызывает инструменты напрямую. Между агентом и каждым инструментом стоит kernel, который:

  1. Проверяет, разрешено ли это действие согласно политикам
  2. Логирует вызов со всеми параметрами
  3. Блокирует или запрашивает подтверждение, если действие превышает порог риска
  4. Передаёт вызов инструменту только после прохождения всех проверок

Три компонента kernel

Политики доступа

Правила записываются в коде, не в промпте. Декларативные, версионируемые, тестируемые.

По инструменту. Whitelist разрешённых инструментов. Принцип наименьших привилегий.

По операции. Агент может читать из таблицы orders, но не может в неё писать. Может отправлять email внутри домена, но не на внешние адреса.

По данным. Агент видит имена клиентов, но не видит номера карт.

По контексту. «В нерабочее время любые write-операции требуют подтверждения». «Финансовые транзакции до 50 долларов — автоматически. Свыше 500 — блокировка до подтверждения».

Аудит

Каждый вызов записывается: какой агент, какой инструмент, какие параметры, какая политика сработала, результат. Это разбор инцидентов, обнаружение аномалий и compliance в одном пакете.

Circuit breaker

Автоматическая остановка агента при аномальном поведении: превышение rate limit, повторные попытки обойти блокировку, каскадные вызовы, превышение бюджета сессии.

Human-in-the-loop, который работает

Плохая реализация: агент спрашивает «Разрешить?» перед каждым действием. Через день оператор автоматически жмёт «Yes».

Хорошая реализация: подтверждение запрашивается редко и по делу. Полный контекст, явные последствия, оценка обратимости. Оператор принимает информированное решение.

Пять сценариев — до и после

Удаление данных. Kernel видит DELETE на production → блокировка.

Финансовый перевод с ошибкой. Kernel останавливает транзакцию свыше порога, оператор замечает лишний ноль.

Утечка данных через prompt injection. Политика запрещает экспорт PII за пределы домена. Блокировка.

Каскадное разрушение инфраструктуры. Kernel проверяет граф зависимостей terraform destroy → блокировка.

Бесконтрольный расход бюджета. Circuit breaker при достижении бюджета сессии.

С чего начать: минимальный governance за день

Обёртки вокруг опасных функций. Whitelist вместо blacklist. Логирование каждого вызова. Лимиты на сессию.

Governance — не тормоз, а условие масштабирования

Без governance вы вынуждены ограничивать агента искусственно. С governance вы можете дать агенту доступ к production — с политиками, которые предотвращают деструктивные действия. Governance не ограничивает агента. Governance позволяет ему делать больше — безопасно.

Мы не выпускаем API без аутентификации. Не деплоим без тестов. Выпускать агентов без governance — такой же архитектурный промах.

Автор: Алик Завалишев

Эксперт по ИИ и автоматизации процессов

Больше статей