Блокировка отличается от ошибки tool. Ошибка tool означает, что действие пытались выполнить, но API вернул проблему: timeout, 403, 500 или неверные аргументы. Blocked action обычно останавливается раньше: политика, guardrail, ACL, action allowlist, approval workflow или risk engine не разрешили выполнять действие.
Для пользователя важно объяснять blocked action спокойно и понятно: не "я сломался", а "это действие требует подтверждения", "у меня нет прав на изменение сделки", "политика запрещает отправлять такие данные" или "нужен человек для проверки".
Хороший blocked action должен попадать в audit log и agent trace. Там полезно хранить action candidate, причину блокировки, правило, risk level, пользователя, объект, tool, timestamp, trace_id и следующий безопасный шаг: запросить approval, предложить read-only вариант, создать задачу человеку или отказаться.
Blocked actions помогают не только защищать систему, но и улучшать агента. Если блокировок слишком много, возможно, правила слишком жесткие, prompt провоцирует лишние actions или agent workflow плохо различает read-only и write-действия.
Примеры
- Агент хочет удалить файл из Google Drive, но action allowlist разрешает только чтение. Действие блокируется.
- CRM-агент пытается изменить сумму сделки без approval. Workflow отправляет действие в очередь согласования вместо выполнения.
- Пользователь просит отправить персональные данные в внешний чат. Guardrail блокирует действие и предлагает безопасный summary.
- AI-агент DevOps предлагает rollback production, но политика требует подтверждение дежурного инженера.
- Агент поддержки хочет выдать компенсацию выше лимита. Действие блокируется и эскалируется руководителю.
- Tool call к API не запускается, потому что у пользователя нет ACL на этот объект.
Где используется
- защита write-actions AI-агента
- guardrails для CRM, документов, почты и API
- human approval для рискованных действий
- разделение read-only и write-tools
- контроль доступа через ACL и роли
- блокировка prompt injection и опасных инструкций
- audit log действий, которые агент не выполнил
- безопасный fallback вместо выполнения действия
- мониторинг частоты блокировок и причин отказа
- тестирование агента перед production-запуском
Связанные термины
Частые вопросы
Blocked action - это ошибка агента?
Не обязательно. Часто это правильное поведение: система остановила рискованное действие до выполнения. Ошибка начинается, если агент не объясняет причину или не предлагает безопасный следующий шаг.
Чем blocked action отличается от failed tool call?
Blocked action не выполняется из-за политики, прав, лимита или отсутствия approval. Failed tool call уже был отправлен в tool или API, но завершился ошибкой: timeout, 403, 500, validation error.
Что показывать пользователю при блокировке?
Короткое объяснение и следующий шаг: запросить подтверждение, обратиться к владельцу доступа, выполнить безопасный read-only вариант или уточнить данные. Не нужно показывать внутренние guardrail-правила полностью.
Что писать в audit log для blocked action?
Action candidate, tool, объект, пользователь, причина блокировки, rule id, risk level, timestamp, trace_id, статус и предложенный next action. Секреты и персональные данные нужно маскировать.
Можно ли автоматически разблокировать действие?
Только по явным правилам. Например, после human approval или если действие оказалось низкорисковым. Нельзя позволять модели самой обходить guardrails или менять allowlist.
Что делать, если blocked actions слишком много?
Разберите причины: возможно, агенту даны слишком широкие задачи, tools плохо описаны, правила слишком жесткие или не хватает read-only альтернатив. Метрика блокировок полезна для настройки workflow.
