Простая аналогия: у стажера есть список задач, которые он может делать сам: создать черновик письма, добавить комментарий, поставить задачу. Но он не может сам отправить договор, удалить сделку, изменить цену или списать деньги. Для таких действий нужен отдельный допуск или подтверждение человека.
В AI-агентах action allowlist особенно важен для tool calling. Модель может выбрать инструмент и предложить аргументы, но backend должен проверить не только формат вызова, а сам тип действия. Например, разрешены create_task, add_note и draft_email, но запрещены delete_contact, send_payment, change_contract_terms и update_price без approval.
Allowlist отличается от denylist. Denylist перечисляет запрещенное: «нельзя удалять», «нельзя отправлять деньги». Allowlist безопаснее: разрешено только то, что явно указано. Все неизвестные, новые или неправильно названные действия блокируются по умолчанию. Для AI-агентов это обычно надежнее, потому что модель может сформулировать опасное действие неожиданным способом.
Action allowlist не заменяет права доступа. Даже если действие есть в списке, нужно проверить пользователя, роль, ACL, scope интеграции, лимиты, статус объекта и контекст. Например, create_task может быть разрешен, но только в своем workspace и только с безопасными полями. Update CRM deal может быть разрешен только как draft или после human-in-the-loop.
Хорошая реализация хранит action name, tool, allowed scopes, поля, лимиты, условия, риск-уровень, необходимость approval, правила rollback и audit log. Для read-only действий правила мягче. Для write actions, отправки сообщений, изменения денег, договоров, персональных данных и доступа нужны более жесткие проверки.
Главные ошибки: полагаться только на системный промпт, давать агенту универсальный API-ключ, разрешать wildcard actions, не разделять read и write tools, не логировать вызовы, не проверять аргументы действия и не пересматривать allowlist после изменения бизнес-процесса.
Примеры
- В CRM-агенте разрешены create_task, add_note и draft_email. Изменение суммы сделки и удаление контакта запрещены без отдельного approval.
- В агенте поддержки разрешено искать по базе знаний и готовить черновик ответа, но отправка письма клиенту включается только после подтверждения оператора.
- В финансовом агенте read_invoice_status разрешен, а pay_invoice заблокирован по умолчанию и требует отдельного workflow с human-in-the-loop.
- В n8n workflow узел проверяет action_type. Если модель вернула неизвестное действие вроде export_all_clients, сценарий останавливается и пишет событие в audit log.
- В агенте для документов разрешено comment_on_contract, но запрещено approve_contract, если пользователь не юрист и нет записи в approval workflow.
Где используется
- ограничение tool calling в AI-агентах
- разделение read-only и write-действий
- безопасная интеграция агента с CRM, почтой, задачами и ERP
- защита от prompt injection и неожиданных команд пользователя
- проверка действий перед вызовом API
- human-in-the-loop для рискованных операций
- sandbox-режим для новых агентных сценариев
- audit log всех разрешенных и заблокированных действий
- rollback-план для действий, которые можно отменить
- go/no-go проверка агента перед запуском в продакшен
Связанные термины
Частые вопросы
Что такое action allowlist простыми словами?
Это список действий, которые агенту разрешено выполнять. Все, чего нет в списке, блокируется по умолчанию. Так агент не сможет случайно или по вредной инструкции сделать опасное действие.
Чем allowlist лучше denylist для AI-агента?
Denylist запрещает известные опасные действия, но пропускает неизвестные варианты. Allowlist разрешает только заранее описанные действия, поэтому новые, странные или неправильно сформулированные команды не выполняются автоматически.
Можно ли заменить action allowlist системным промптом?
Нет. Системный промпт полезен как инструкция для модели, но реальная проверка должна быть в коде или workflow. Модель может ошибиться, попасть под prompt injection или неверно выбрать tool.
Что должно быть в allowlist действия?
Минимум: название действия, tool или API, разрешенные поля, роли или scopes, лимиты, риск-уровень и правило approval. Для write-действий также полезны audit log, rollback и проверка владельца объекта.
Какие действия стоит требовать подтверждать человеком?
Подтверждение нужно для действий с деньгами, договорами, персональными данными, массовыми рассылками, удалением, изменением прав доступа, публичными публикациями и любыми операциями, которые трудно откатить.
Как тестировать action allowlist?
Нужно проверить разрешенные действия, запрещенные действия, неизвестные action_type, неправильные аргументы, чужие объекты, превышение лимитов и prompt injection. Важно убедиться, что блокировка происходит до вызова API.
