Se você está criando fluxos de trabalho de IA que processam mensagens de clientes, envios de formulários ou qualquer texto gerado pelo usuário, você está a apenas uma entrada bem elaborada de vazar dados, expor seu prompt do sistema ou deixar alguém sequestrar seu agente.
Este fluxo de trabalho oferece uma camada de segurança funcional que você pode testar em 5 minutos.
O que ele faz
- Verifica o texto em busca de PII (emails, números de telefone) e os oculta com placeholders seguros
- Detecta tentativas de injeção de prompt usando análise de palavras-chave, correspondência de padrões estruturais e pontuação heurística — sem chamada de LLM, sem latência de LLM, sem custo de IA por varredura
- Inclui 10 testes de ataque adversarial real (um de cada categoria) com resultados de aprovação/falha mostrados diretamente na saída do fluxo de trabalho — sem credenciais necessárias para executar
- Retorna uma decisão clara:
allow, review ou block com códigos de razão
Configure em menos de 5 minutos — importe o fluxo de trabalho, clique em “Execute Workflow” e veja o escudo detectar um ataque de amostra. Em seguida, troque por seus próprios inputs de teste.
Construído para produção, não para demos
- Verificações determinísticas — a mesma entrada sempre produz a mesma decisão
- Sem dependências externas — funciona inteiramente dentro dos nós de Código n8n
- Sem credenciais necessárias para a demo — apenas importe e clique
- Falha fechada por padrão — se algo inesperado acontecer, ele bloqueia em vez de permitir
10 categorias de ataque testadas:
injeção direta, injeção indireta, extração de prompt do sistema, exfiltração de segredos, vazamento de PII, representação de função, ofuscação de codificação, instruções ocultas, URLs suspeitas, bypass de escopo de negócios
Precisa de mais? A versão Pro adiciona:
- Validação de saída (detecta sua IA vazando dados, instruções ou fabricando entidades)
- Sinalizadores de risco de alucinação (verificação de canário, fundamentação de fonte, detecção de contradição)
- 66 testes de ataque adversarial com um fluxo de trabalho de execução automática e relatório de aprovação/falha
- Registro de letra morta do Google Sheets (trilha de auditoria que você pode compartilhar com clientes)
- Alertas do Telegram em inputs bloqueados/suspeitos
- Política configurável: ações por tipo de PII, limites de injeção, regras de escopo de negócios
- Documento de resumo de segurança voltado para o cliente
- Documentação do modelo de ameaça
→ AI Security Shield Pro — n8n Workflow Template
Lite: 10/10 testes incorporados aprovados. Suite de regressão Pro: 66/66 verificados. Sem credenciais no arquivo de fluxo de trabalho Lite.
Download workflow JSON (GitHub Gist) GRATUITO
1 curtida
O estado review é a adição mais útil aqui - é fácil ignorá-lo, mas conectar essa ramificação a uma etapa com intervenção humana (um nó Wait + retomada de webhook, ou apenas uma notificação no Slack/Telegram com botões de aprovar/negar) transforma isso de uma camada de detecção em um pipeline de moderação completo. Uma coisa que eu também adicionaria: uma verificação de rate-limit no ponto de entrada - decisões block repetidas do mesmo ID de usuário em uma janela curta é um sinal forte de sondagem ativa, vale a pena registrar separadamente dos bloqueios pontuais.
Duas coisas que valem a pena adicionar a esse padrão:
Log de auditoria para Google Sheets. Encaminhe cada decisão de block e review para uma linha de append no Sheets — timestamp, ID do usuário, decisão, padrão correspondente, score bruto. Duas razões: (1) auditorias de conformidade querem um registro à prova de adulteração fora do app, e (2) após uma semana de tráfego real você pode ajustar seus limites com dados reais em vez de adivinhar. O nó Google Sheets torna isso uma adição de 2 minutos.
Bypass de lista de permissões para chamadores confiáveis. Se seu workflow também é chamado por serviços internos ou integrações conhecidas, adicione uma etapa Check inicial antes do scanner de PII/injeção: se o header X-Internal-Token corresponder a um valor com hash em uma Variável do n8n, pule para a lógica principal. Isso evita que suas próprias ferramentas sejam bloqueadas e mantém a camada de segurança focada apenas em entrada não confiável.
Combinadas, o fluxo completo fica: verificação de chamador confiável → redação de PII → score de injeção → permitir/revisar/bloquear → log de auditoria. Cada etapa é um sub-workflow separado para que você possa testá-las e atualizá-las independentemente.
Boa forma. Eu tornaria o registro de auditoria tão explícito quanto a decisão: versão da política, códigos de motivo, ator ou id do usuário, hash da entrada bruta ou amostra censurada, e qual ação downstream foi bloqueada ou enviada para revisão.
Isso torna o branch de revisão útil depois, não apenas um gate de aprovação/rejeição.
1 curtida
Exactly — the review branch is meant to be the hook for a human-in-the-loop step, and a Wait node + webhook resume is the cleanest way to do it (Slack/Telegram approve/deny works too). The rate-limit idea is good: repeated block decisions from the same source in a short window is a strong active-probing signal, worth counting separately from one-off blocks — a burst is someone mapping your filters, a single block is usually just a bad input. I keep that aggregation out of the detection layer itself (so the scan stays deterministic and stateless) and put it in a thin counter step after the decision. Thanks for the thoughtful add.
Both of these are the right moves. The Sheets append-row audit log is a great low-friction start — timestamp, decision, matched pattern, and score give you enough to tune thresholds from real traffic instead of guessing. One caution: redact or hash the raw input before it lands in the sheet, otherwise the audit log becomes its own PII store. The trusted-caller bypass is smart too — gating on a hashed X-Internal-Token in an n8n Variable keeps the layer pointed at untrusted input and stops your own tooling from tripping it. And yes, splitting it into sub-workflows (trusted-caller → redact → score → decide → log) is how I’d structure it — each stage stays independently testable. Appreciate the detailed writeup.
Completely agree — a bare allow/block is fine at runtime but useless in a post-incident review. Logging the policy version, reason codes, actor id, a hash (or redacted sample) of the input, and which downstream action was gated turns the review queue into something you can actually triage. The policy-version field especially — once you start tuning thresholds you want to know which ruleset made a given call. That’s the difference between a filter and an auditable control. Good addition.