Права AI Agent в n8n: как ограничить tools по принципу least privilege ¶
Обновлено: 2026-05-29
Короткий ответ ¶
AI Agent не должен получать “доступ ко всему”, даже если workflow внутренний. В production права агента проектируют по принципу least privilege: только нужные tools, только нужные поля, read и write разделены, опасные действия проходят approval, а credentials не передаются в prompt. Если агенту нужен доступ к CRM, дайте ему не CRM целиком, а узкие tools вроде find_contact, create_note и create_reply_draft.
Почему права агента важнее prompt ¶
Prompt можно обойти, неправильно понять или случайно ослабить при следующей правке. Права в workflow сложнее обойти: agent физически не может вызвать tool, который не подключён; не может передать параметр, который отбрасывает validation; не может выполнить write-действие, если gate требует approval.
| Уровень | Что ограничивает |
|---|---|
| Подключённые tools | какие действия агент вообще видит |
| Tool schema | какие параметры можно передать |
| Validation node | что действительно уйдёт в API |
| Credentials | какой аккаунт и scopes используются |
| Approval gate | какие действия требуют человека |
| Audit log | кто, когда и почему разрешил действие |
Матрица прав для AI Agent ¶
Начните с таблицы, а не с prompt.
| Сценарий | Read tools | Write tools | Approval |
|---|---|---|---|
| Support triage | база знаний, тикет, профиль клиента | создать внутреннюю заметку | для email клиенту |
| Sales assistant | CRM contact, сделки, история | создать задачу менеджеру | для изменения стадии сделки |
| Billing assistant | заказ, платёж, тариф | создать черновик ответа | для возврата/скидки |
| RAG bot | vector search | нет | не нужен, если нет write |
| Ops assistant | read metrics, logs | создать incident note | для restart/delete/change config |
Матрица должна быть понятна не только разработчику, но и владельцу процесса.
Разделяйте read и write ¶
Самая частая ошибка — один tool с широким названием crm_action, который умеет читать, создавать и обновлять. Для агента это слишком широкий рычаг.
Правильнее:
find_crm_contact— read;get_customer_orders— read;create_internal_note— low-risk write;create_reply_draft— medium-risk write;update_deal_stage— high-risk write;send_customer_email— high-risk external action.
Read tools можно запускать автоматически. High-risk write tools должны идти через approval и idempotency.
Credentials: не передавайте секреты модели ¶
AI Agent не должен видеть API token, OAuth refresh token, пароль, webhook secret или private key. Credentials остаются в n8n credentials/node configuration. В prompt можно передавать только безопасные идентификаторы: customer_id, ticket_id, source_id, order_id.
Плохой подход:
Используй этот API key: sk_live_...
Правильный подход:
Если нужен статус заказа, вызови tool get_order_status с order_id из payload.
Tool сам использует credential внутри n8n, а агент видит только входной контракт.
Ограничивайте данные, а не только действия ¶
Даже read-only tool может быть опасным, если возвращает слишком много PII. Вместо полного профиля клиента верните минимум:
{
"customer_id": "c_123",
"plan": "business",
"open_tickets": 2,
"last_order_status": "paid"
}
Не возвращайте агенту без необходимости:
- паспортные данные;
- полные платёжные реквизиты;
- access tokens;
- приватные комментарии сотрудников;
- полные логи авторизации;
- документы, не относящиеся к задаче.
Approval по уровню риска ¶
Права агента удобно делить на уровни.
| Уровень | Пример | Контроль |
|---|---|---|
| L0 | классификация текста | validation |
| L1 | поиск по базе знаний | source logging |
| L2 | создание черновика | validation + audit |
| L3 | изменение CRM | approval + idempotency |
| L4 | деньги, доступ, удаление | mandatory approval + owner alert |
Если сомневаетесь, ставьте действие на уровень выше.
Как тестировать права ¶
Перед запуском проверьте негативные сценарии:
- пользователь просит агента отправить email без подтверждения;
- prompt injection требует раскрыть секреты;
- агент пытается вызвать неподключённый tool;
- tool получает лишнее поле;
- CRM ID не совпадает с trigger payload;
- low confidence пытается выполнить write-действие;
- replay повторяет уже выполненный update.
Каждый тест должен иметь ожидаемый результат: reject, review, safe fallback или read-only ответ.
Audit log прав ¶
Логируйте:
- список tools, доступных агенту в workflow version;
- tool, который агент выбрал;
- параметры после validation;
- credential owner или service account;
- risk level;
- approval decision;
- final API result;
- replay count.
Это помогает разбирать инциденты и доказывать, что агент не имел лишних прав.
FAQ ¶
Можно ли дать агенту HTTP Request tool?
Только если он обёрнут ограничениями: allowlist доменов, schema, validation, method allowlist и запрет произвольных URL. В большинстве случаев лучше сделать отдельный sub-workflow tool.
Агенту нужен доступ к базе данных?
Лучше не напрямую. Сделайте read-only tool с конкретным запросом или API, который возвращает только нужные поля.
Нужен ли отдельный service account?
Да, для production это удобнее: scopes ограничены, действия аудитятся отдельно, а личный аккаунт сотрудника не ломает workflow при увольнении или смене пароля.