Пока модель генерирует текст, худшее, что может случиться — неверный ответ. Как только модель начинает действовать, её власть и видимость становятся поверхностью атаки. Инъекция из письма превращается не в плохой ответ, а в выполненный перевод денег.
По отчёту Saviynt 2026 лишь 5% security-лидеров уверены, что смогли бы сдержать скомпрометированного агента. Индустрия к агентным системам не готова, а они уже ходят в ваши внутренние API, создают тикеты и отправляют проекты решений клиентам.
Эта глава — про autonomy plane: как дать агенту делать полезную работу самому, но так, чтобы объём автономии был явно ограничен, необратимые действия согласованы, а опасное поведение перехвачено до последствий.
Бизнес-цель: градуированная автономия
Автономия агента градуирована по риску действия. Обещания бизнесу:
- Агент делает сам то, что дёшево откатить; всё необратимое и дорогое — через человека.
- Инъекция или галлюцинация не превращается в выполненное вредное действие.
- Любую агентную задачу можно остановить, а её незавершённые действия — заморозить.
Драйверы: угроза и регулятор
OWASP анонсировала Top 10 for Agentic Applications на Black Hat Europe 2025: excessive agency, tool misuse, memory poisoning, захват через инъекцию. OWASP LLM ставит проблему жёстче: LLM06 (Excessive Agency) и LLM01 (Prompt Injection как вектор захвата). EU AI Act в Art. 14 требует human oversight для high-risk систем — человек должен мочь вмешаться. А в роевой архитектуре одна ошибка усиливается до системной через каскад агентов.
Архитектурный паттерн: Bounded Autonomy & Policy-Gated Action Loop
Каждое действие агента проходит через детерминированный policy-гейт. Гейт решает: авто-исполнение, требование подтверждения человека или отказ. Автономия — не тумблер «вкл-выкл», а градация по классу риска действия.
Это прямое применение вывода из гл. 3 (out-of-band policy, CaMeL): безопасность действия решается вне модели — детерминированной политикой над происхождением и классом действия, которую нельзя уговорить инъекцией.
agent plan → выбор инструмента
│
▼
[classify action risk] → read | reversible-write | irreversible | financial
│
▼
[OPA policy gate] ── auto ──► execute (least-priv, short-lived creds)
├── HITL ──► approval queue ──► (человек) ──► execute | reject
└── deny ──► block + audit (гл. 4)
▲
[kill-switch flag] ── прерывает цикл немедленно (гл. 8)Инженерный стек
| Слой | Инструмент | Назначение |
|---|---|---|
| Оркестрация | LangGraph, CrewAI или собственный state-machine-раннер | Явные состояния — требование архитектуры |
| Tool-протокол | MCP (Model Context Protocol) | Governance над серверами и скоупами |
| Policy | OPA (Rego) | Гейт действий |
| Kill-switch | Feature-flags | Немедленная остановка цикла |
| HITL | Approval queue + аудит | Подтверждение необратимых действий |
Реализация: шесть шагов
Шаг 1. Каталог действий с классами риска
Каждое tool-действие получает класс и требуемый режим:
actions:
search_customer: {risk: read, mode: auto}
create_ticket: {risk: reversible-write, mode: auto}
update_limit: {risk: irreversible, mode: hitl}
transfer_funds: {risk: financial, mode: hitl, second_approver: true}Четыре класса — четыре режима. Чтение идёт автоматически. Создание тикета — тоже: его можно откатить. Изменение лимита требует человека. Перевод денег требует двух подтверждений.
Шаг 2. Policy-Gated Loop
Перед вызовом инструмента агент спрашивает OPA: можно ли, кому, при каких условиях — сумма, клиент, время, происхождение данных из гл. 3. Вердикт логируется (гл. 4). Политика написана на Rego, детерминирована и не подвержена социальному инжинирингу промпта.
Шаг 3. Least-privilege tools через MCP
MCP-серверы настраиваются с минимальными скоупами, short-lived отзываемыми кредами и allow-list инструментов на роль агента. MCP-серверы попадают в AIBOM (гл. 8) — это компоненты supply chain, и их учёт не отличается от учёта любой сторонней зависимости.
Шаг 4. Human-in-the-loop для необратимого
Необратимое или дорогое уходит в approval queue. Без подтверждения — для financial класса двух подтверждений — действие не исполняется. Это явный переход состояния, зафиксированный в оркестраторе, а не «модель решила, что можно».
Шаг 5. Memory governance
Память агента изолируется и валидируется — защита от memory poisoning из OWASP Agentic. TTL и права на записи. Отравленная память — способ протащить инъекцию между сессиями: агент «вспоминает» инструкцию, которую ему никогда не давали, и действует по ней.
Шаг 6. Лимиты и kill-switch
Лимит шагов и стоимости на задачу (стык с гл. 5); превышение — стоп и эскалация. Kill-switch (гл. 8) прерывает цикл немедленно и замораживает незавершённые действия. Это не аварийный режим — это штатный механизм управления контуром.
Где ломается
HITL-усталость
Слишком много подтверждений — и человек штампует «ок» не глядя. Rubber stamp: oversight формальный, человек в петле есть, контроля нет. Лечится тремя способами: HITL только для реально необратимого, батчинг однотипных запросов, внятный контекст в каждом запросе на подтверждение — чтобы человек видел, что именно одобряет, а не просто нажимал кнопку.
Инъекция обходит гейт логикой задачи
Агент «убеждён», что действие легитимно — indirect injection из данных (гл. 3). Письмо клиента содержит текст, который для модели выглядит как инструкция изменить лимит. Спасает не guard-модель, а провенанс-политика: действие спровоцировано недоверенным источником — deny. Происхождение данных проверяется до того, как действие попадает в гейт, и недоверенный источник не может санкционировать действие любого класса.
Композиция безопасных действий = опасный результат
Каждое действие в цепочке разрешено, цепочка в целом вредна. Гейт отдельного шага этого не видит — шаги по отдельности укладываются в политику. Нужны инварианты на уровне задачи и сессии: не «разрешён ли этот шаг», а «разрешена ли эта последовательность шагов для этого контекста».
Латентность гейтов
Каждый гейт — это задержка. Политики, проверка провенанса, approval queue — всё это ломает «живость» агента. Баланс автономии и контроля: чем больше гейтов, тем медленнее агент и тем меньше смысла в его автономии. Чем меньше гейтов, тем больше поверхность атаки. Решения нет — это инженерный компромисс, который нужно осознанно принимать на каждый класс действий.
Multi-agent
Ответственность размывается по рою. Трассировка причинности (гл. 4) усложняется: какой агент в цепочке принял решение, привёдшее к последствиям? Остановка (гл. 8) усложняется: kill-switch для одного агента не останавливает остальных. Рой требует собственного уровня координации и собственного kill-switch.
Стандарты и маппинг
| Стандарт | Покрытие |
|---|---|
| OWASP Top 10 for Agentic Applications | Excessive agency, tool misuse, memory poisoning, injection |
| OWASP LLM | LLM06 (Excessive Agency), LLM01 (Prompt Injection) |
| EU AI Act | Art. 14 (human oversight), Art. 15 (robustness) |
| ISO/IEC 42001 | Управление операциями и инцидентами ИИ |
| NIST AI RMF | Manage (oversight, intervention) |
Лаба и артефакт
Дать «Ковчегу»-агенту четыре инструмента разного класса риска через MCP. Настроить OPA-гейт, approval queue с двойным подтверждением для financial, step/budget-лимиты, memory-изоляцию и kill-switch. Провести red-team: indirect-инъекция из письма (кейс гл. 3), пытающаяся спровоцировать update_limit или transfer_funds.
Артефакт: каталог действий с классами риска + rego-гейты + журнал HITL + red-team отчёт по OWASP Agentic.
Полная инструкция: https://www.dobryakov.com/howto/ai-governance-agentic-governance.html
Чеклист зрелости
- L1: агент с allow-list инструментов, логирование действий.
- L2: policy-гейт по классам риска, HITL для необратимого, step/budget-лимиты, MCP с least-privilege.
- L3: memory governance, kill-switch с учениями, out-of-band провенанс-политика, защита от композиционных атак, анти-rubber-stamp меры в oversight.
Источники
- OWASP Top 10 for Agentic Applications (Promptfoo)
- CaMeL: Defeating Prompt Injections by Design (MIT/arXiv)
- AI Agent Kill Switches: can you actually stop one in 2026?
- Shadow AI Agents: the insider threat (CSA)
95% security-лидеров не уверены, что сдержат скомпрометированного агента. Если ваш агент уже ходит в API, а у вас нет policy-гейта, approval queue и kill-switch — вы в этих 95%. Посчитайте, сколько действий вашего агента относятся к классу irreversible или financial, и спросите себя: кто разрешает эти действия прямо сейчас — детерминированная политика или языковая модель, которую можно уговорить?