Простая логика policy gate выглядит так: разрешить, заблокировать, попросить уточнение, отправить человеку на approval или выполнить только в read-only режиме. Такая проверка особенно важна для агентов с tool calling, потому что ошибка модели может превратиться в реальное действие во внешней системе.
Policy gate не равен одному системному промпту. Промпт может описывать правила, но контроль лучше выносить в отдельный слой: allowlist действий, schema validation, ACL, проверка ролей, лимиты, контекст клиента, риск действия, статус согласования и audit log. Тогда даже если модель ошиблась или попалась на prompt injection, опасное действие не пройдет автоматически.
Хороший policy gate должен быть понятным и проверяемым. Команда должна знать, какие действия разрешены без подтверждения, какие требуют человека, какие запрещены всегда и какие данные нельзя раскрывать. Для production-агентов такие правила тестируют через evals, red teaming и regression suite.
Примеры
- Агент хочет отправить клиенту письмо с коммерческим предложением, но policy gate требует подтверждение менеджера.
- SQL-агент пытается выполнить UPDATE, а policy gate разрешает только SELECT в read-only режиме.
- Поддержка просит показать персональные данные клиента, и gate проверяет роль пользователя и основание доступа.
- Агент предлагает удалить файл, но действие заблокировано, потому что delete не входит в action allowlist.
- После prompt injection модель пытается вызвать внешний webhook, но policy gate останавливает tool call по домену и типу действия.
Где используется
- Проверять tool calls перед выполнением в CRM, почте, базе данных, файлах или API.
- Разделять действия на разрешенные, запрещенные и требующие approval.
- Защищать агента от prompt injection, tool poisoning и случайных опасных действий.
- Применять ACL, роли, права доступа и ограничения по tenant или клиенту.
- Блокировать действия с высоким риском: удаление, платеж, массовая рассылка, изменение данных.
- Включать read-only mode для чувствительных систем.
- Проверять параметры инструмента через schema validation и allowlist.
- Логировать решения gate в audit log и tool call log.
- Тестировать правила безопасности через evals, red teaming и regression suite.
Связанные термины
ACL
Action allowlist
Agent trace
AI governance
Approval queue
Approval workflow
Audit log
Blocked action
Частые вопросы
Что такое Policy Gate простыми словами?
Это проверка перед ответом или действием агента: можно ли выполнить действие, нужно ли подтверждение человека или его нужно заблокировать.
Зачем policy gate нужен ИИ-агенту?
ИИ-агент может ошибиться или попасться на prompt injection. Policy gate не дает опасному tool call или раскрытию данных пройти только потому, что модель так решила.
Чем policy gate отличается от guardrails?
Guardrails — общий набор ограничений и проверок. Policy gate — конкретная контрольная точка, где принимается решение по действию или ответу.
Какие решения может принимать policy gate?
Обычно: allow, deny, ask for clarification, require approval, run in read-only mode или route to human.
Где хранить правила policy gate?
Лучше хранить их отдельно от обычного промпта: в конфигурации, коде, policy engine, базе правил или сервисе доступа, чтобы их можно было тестировать и аудировать.
