Runtime enforcement для AI-агентов: как не дать агенту сделать что-то непоправимое
AI-агент решил удалить таблицу в production. Между решением и действием — 0 мс проверки. AlterSpec добавляет прослойку: политики, логирование, блокировка запрещённых операций.
Агент решил отправить email. Промпт был: «Уведоми клиента об изменении статуса заказа.» Агент сформировал письмо, вызвал SendGrid API — и отправил. Всё правильно, всё по задаче. Кроме одного: агент отправил письмо всем 4 200 клиентам в базе, а не одному.
Между решением агента и фактической отправкой не было ни одной проверки. Это фундаментальная проблема: у AI-агентов нет runtime enforcement — прослойки между решением и действием.
Проблема: от решения к действию — 0 мс
LLM решает вызвать инструмент. Фреймворк выполняет. Между ними — ничего. Необратимые действия, масштаб ошибки (тысяча раз с одной ошибкой), уверенность без сомнений, эскалация привилегий.
AlterSpec: firewall между решением и действием
Три компонента: Interceptor (перехват tool call), Policies (правила проверки), Action Logger (аудиторский след).
Типы политик:
- Scope policy — ограничение таблиц, получателей
- Rate limit policy — N действий за период
- Destructive action policy — блокировка DROP TABLE, rm -rf, DELETE без WHERE
- Cost policy — бюджет на сессию
Интеграция с LangChain — три строки. Tools оборачиваются прозрачно, агент видит те же инструменты, но между решением и выполнением стоит enforcement.
Human-in-the-loop для критичных действий: сообщение в Slack, одобрение реакцией, timeout = deny по умолчанию.
Policy-as-Code: политики в YAML, меняются без передеплоя.
Три уровня зрелости
- Логирование (день) — только запись действий
- Enforcement (неделя) — автоблокировка по правилам
- Adaptive policies (месяц) — политики адаптируются к trust score агента
Runtime enforcement для агентов — firewall для действий вместо пакетов. Между решением агента и действием должна быть стена с дверью. Одна строка в policy.yaml — max_email_recipients: 5 — предотвратила бы инцидент с 4200 письмами.