Si estás construyendo flujos de trabajo con IA que procesan mensajes de clientes, envíos de formularios o cualquier texto generado por usuarios, estás a solo una entrada elaborada de filtrar datos, exponer tu prompt del sistema o permitir que alguien secuestre tu agente.
Este flujo de trabajo te proporciona una capa de seguridad funcional que puedes probar en 5 minutos.
Qué hace
- Escanea el texto en busca de PII (correos electrónicos, números de teléfono) y los redacta con marcadores de posición seguros
- Detecta intentos de inyección de prompts usando análisis de palabras clave, coincidencia de patrones estructurales y puntuación heurística — sin llamadas de LLM, sin latencia de LLM, sin costo de IA por escaneo
- Incluye 10 pruebas reales de ataques adversariales (una de cada categoría) con resultados de aprobación/fallo mostrados directamente en la salida del flujo de trabajo — no se necesitan credenciales para ejecutar
- Devuelve una decisión clara:
allow, review o block con códigos de motivo
Configuración en menos de 5 minutos — importa el flujo de trabajo, haz clic en «Execute Workflow» y observa cómo el escudo detiene un ataque de muestra. Luego, canjea tus propias entradas de prueba.
Construido para producción, no para demostraciones
- Verificaciones determinísticas — la misma entrada siempre produce la misma decisión
- Sin dependencias externas — se ejecuta completamente dentro de los nodos de código n8n
- Sin credenciales requeridas para la demostración — solo importa y haz clic
- Falla de forma cerrada por defecto — si algo inesperado ocurre, bloquea en lugar de permitir
10 categorías de ataque probadas:
inyección directa, inyección indirecta, extracción de prompt del sistema, exfiltración de secretos, filtración de PII, suplantación de identidad, ofuscación de codificación, instrucciones ocultas, URLs sospechosas, evasión del alcance comercial
¿Necesitas más? La versión Pro añade:
- Validación de salida (detecta si tu IA filtra datos, instrucciones o fabrica entidades)
- Banderas de riesgo de alucinación (verificación canaria, fundamentación de fuentes, detección de contradicciones)
- 66 pruebas de ataques adversariales con un flujo de trabajo ejecutor automático e informe de aprobación/fallo
- Registro de letra muerta en Google Sheets (pista de auditoría que puedes compartir con clientes)
- Alertas de Telegram en entradas bloqueadas/sospechosas
- Política configurable: acciones por tipo de PII, umbrales de inyección, reglas de alcance comercial
- Documento de resumen de seguridad orientado al cliente
- Documentación del modelo de amenaza
→ AI Security Shield Pro — n8n Workflow Template
Lite: 10/10 pruebas integradas aprobadas. Suite de regresión Pro: 66/66 verificadas. Sin credenciales en el archivo de flujo de trabajo Lite.
Descargar JSON del flujo de trabajo (GitHub Gist) GRATIS
1 me gusta
El estado review es la adición más útil aquí - es fácil pasarlo por alto, pero conectar esa rama a un paso de intervención humana (un nodo Wait + reanudación por webhook, o simplemente una notificación de Slack/Telegram con botones de aprobar/rechazar) transforma esto de una capa de detección a un pipeline de moderación completo. Otra cosa que también añadiría: una verificación de límite de velocidad en el punto de entrada - decisiones block repetidas del mismo ID de usuario en una ventana corta es una señal fuerte de sondeo activo, que merece ser registrada por separado de los bloqueos ocasionales.
Dos cosas que vale la pena añadir a este patrón:
Registro de auditoría en Google Sheets. Canaliza cada decisión de block y review a una fila de Sheets — marca de tiempo, ID de usuario, decisión, patrón coincidente, puntuación sin procesar. Dos razones: (1) los auditorios de cumplimiento quieren un registro a prueba de manipulaciones fuera de la aplicación, y (2) después de una semana de tráfico real puedes ajustar tus umbrales con datos reales en lugar de adivinar. El nodo de Google Sheets hace que esto sea una adición de 2 minutos.
Omisión de lista blanca para llamadores de confianza. Si tu flujo de trabajo también es llamado por servicios internos o integraciones conocidas, añade un paso Check temprano antes del escáner de PII/inyección: si el encabezado X-Internal-Token coincide con un valor hasheado en una Variable de n8n, salta a la lógica principal. Esto evita que tu propio tooling sea bloqueado y mantiene la capa de seguridad enfocada en entrada no confiable solamente.
Combinados, el flujo completo se convierte en: verificación de llamador de confianza → redacción de PII → puntuación de inyección → permitir/revisar/bloquear → registro de auditoría. Cada paso es un sub-flujo separado para que puedas probar y actualizar cada uno de forma independiente.
Buena estructura. Yo haría que el registro de auditoría fuera tan explícito como la decisión: versión de la política, códigos de razón, identificador del actor o usuario, hash de la entrada sin procesar o muestra redactada, y qué acción descendente se bloqueó o se envió a revisión.
Eso hace que la rama de revisión sea útil más adelante, no solo una compuerta de aprobación/rechazo.
1 me gusta
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.