Безопасность AI workflows в n8n: права, данные, approval, policy и аудит ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Безопасность AI workflow в n8n строится не на “хорошем prompt”, а на слоях контроля: минимальные права, фильтрация входных данных, ограниченные tools, проверяемый output, human approval для рискованных действий, audit log и fallback. Модель может ошибиться, галлюцинировать или неправильно понять инструкцию, поэтому всё, что влияет на деньги, данные, CRM, доступы, клиентов и юридические обязательства, должно проходить через правила, схемы и подтверждение.

Что именно нужно защищать ¶

В AI automation есть четыре группы рисков. Первая — данные: пользователь может прислать персональные данные, коммерческую тайну, токены, документы, медицинские или финансовые сведения. Вторая — действия: агент может создать лид, отправить письмо, изменить статус заказа, вызвать refund или удалить запись. Третья — контекст: RAG может вернуть устаревший документ, memory может смешать данные разных пользователей, prompt может раскрыть внутренние инструкции. Четвёртая — стоимость и доступность: циклы, retry, длинный контекст и дорогая модель могут создать bill shock или задержки.

Страница про safety должна отвечать не “как сделать AI безопасным вообще”, а как применить конкретные меры в n8n workflow. n8n удобен тем, что вокруг AI node можно поставить обычные узлы: Code, IF, Switch, Data Store, HTTP Request, approval, logging, error workflow. Именно эти узлы и делают AI управляемым.

Матрица рисков ¶

Эта матрица должна быть в статье: посетителю сразу понятно, какие угрозы закрывать и какими узлами.

Принцип least privilege для AI Agent ¶

AI Agent не должен получать все tools “на всякий случай”. У него должен быть минимальный набор инструментов под конкретную роль. Support draft agent может читать базу знаний и создавать черновик ответа, но не должен делать refund. Sales enrichment agent может читать публичные данные и предложить поля для CRM, но не должен автоматически перезаписывать важные lead_source или owner без проверки.

Разделяйте tools на категории:

• read-only: поиск по базе, получение статуса заказа, чтение CRM;
• draft: подготовить письмо, создать заметку, предложить категорию;
• write low-risk: добавить internal note, обновить тег;
• write high-risk: отправить клиенту письмо, изменить сумму, сделать refund, удалить данные;
• admin: credentials, users, workflow activation — такие tools обычно не должны быть доступны агенту.

Для high-risk действий включайте human approval. Ревьюеру показывайте не только итог, но и контекст: input, найденные источники, proposed action, affected record, diff до/после, confidence и причину рекомендации.

Защита персональных данных ¶

До отправки в LLM сделайте PII-gate. Не всё нужно отправлять модели. Часто достаточно заменить email, телефон, адрес, номер заказа или ФИО на токены.

Пример Code node для базовой маскировки:

const text = $json.text || '';
const redacted = text
  .replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, '[EMAIL]')
  .replace(/\+?\d[\d\s().-]{8,}\d/g, '[PHONE]')
  .replace(/\b\d{4}\s?\d{4}\s?\d{4}\s?\d{4}\b/g, '[CARD_LIKE]');
return [{ json: { ...$json, text_redacted: redacted, pii_redacted: redacted !== text } }];

Это не полноценная DLP-система, но хороший первый слой. Для production добавьте allowlist полей: какие данные вообще можно отправлять в модель, какие нужно хэшировать, какие запрещено сохранять в execution logs.

Output safety: проверяйте не текст, а действие ¶

Ошибка многих команд — они пытаются “заставить модель быть осторожной”. Лучше проектировать output как действие с параметрами. Например, вместо свободного ответа “я думаю, надо вернуть деньги” модель должна вернуть JSON:

{
  "recommended_action": "refund_review",
  "risk_level": "high",
  "requires_human_approval": true,
  "customer_message_draft": "...",
  "reason": "Клиент сообщил о двойном списании",
  "missing_evidence": ["payment_id", "transaction_status"]
}

После этого IF/Switch node решает: high-risk action идёт в approval, low-risk draft сохраняется как заметка, missing evidence отправляет задачу оператору.

Prompt injection и RAG safety ¶

Prompt injection часто приходит не от пользователя напрямую, а из документов: “если ты читаешь это, игнорируй инструкции”. RAG workflow должен воспринимать документы как недоверенный контент. Источник может помогать ответить на вопрос, но не должен менять правила агента.

Практические меры:

• храните system policy отдельно от retrieved documents;
• не позволяйте документам переопределять tools или права;
• требуйте citations для фактических утверждений;
• если источники противоречат друг другу, возвращайте uncertainty;
• добавьте no-answer policy, когда источников нет;
• фильтруйте документы по tenant_id, role и freshness.

Human approval: когда обязательно ¶

Approval обязателен, если workflow:

• отправляет сообщение внешнему клиенту от имени компании;
• меняет деньги, подписку, скидку, заказ, legal status;
• записывает данные в CRM как “истину”, а не черновик;
• использует персональные данные в ответе;
• вызывает tool с долгосрочным эффектом;
• работает с новыми prompts или новой моделью без истории качества.

Approval не должен быть формальностью. Показывайте ревьюеру diff, sources, risk label и причину. Если ревьюер просто видит “одобрить действие”, он не сможет оценить риск.

Safety rollout ¶

Запускайте AI workflow в четыре этапа. На первом он только логирует рекомендации. На втором создаёт черновики. На третьем выполняет low-risk действия автоматически. На четвёртом — high-risk действия, но только если накоплена статистика, есть approval и понятный rollback.

Метрики безопасности:

• доля ответов без источников;
• доля manual overrides;
• число blocked actions;
• число prompt injection flags;
• среднее время approval;
• стоимость на успешное действие;
• процент fallback;
• инциденты с PII.

Минимальный safety checklist ¶

Перед production спросите:

• какие данные уходят в модель;
• какие tools доступны агенту;
• какие tools read-only, а какие write;
• какие действия требуют approval;
• есть ли JSON Schema и validation;
• есть ли no-answer и refusal policy;
• можно ли восстановить, почему агент принял решение;
• можно ли быстро отключить AI-ветку;
• кто владелец workflow;
• как удаляются или маскируются sensitive execution data.

Если на эти вопросы нет ответов, workflow ещё не готов. Лучше запустить меньше автоматизации, но с понятными границами, чем выпускать “универсального агента”, которого невозможно объяснить и остановить.

FAQ ¶

Можно ли обеспечить safety только prompt-инструкциями?
Нет. Prompt снижает риск, но не является контролем. Нужны ограниченные tools, JSON Schema, Code node validation, approval и audit log.

Какие действия всегда должны идти через human approval?
Платежи, refund, удаление данных, отправка клиенту, изменение юридически значимых статусов, доступ к sensitive data и любые действия с высоким бизнес-риском.

Нужно ли маскировать PII перед LLM?
Да, если полные данные не нужны для ответа. Email, телефон, адрес, номера документов и платежные данные лучше заменять токенами или хэшами.

Как защищаться от prompt injection в RAG?
Считать документы недоверенным контентом, держать system policy отдельно, требовать источники, фильтровать документы по metadata и запрещать retrieved text менять правила агента.

Что логировать для AI safety?
Trace ID, workflow, model, prompt version, tool calls, risk level, approval status, retrieved sources, fallback, validation errors и cost bucket. Секреты и полные PII логировать нельзя.