Si vous créez des workflows d’IA qui traitent des messages clients, des soumissions de formulaires ou tout texte généré par l’utilisateur, vous n’êtes qu’à une entrée bien construite de fuites de données, d’exposition de votre prompt système ou de laisser quelqu’un détourner votre agent.
Ce workflow vous offre une couche de sécurité fonctionnelle que vous pouvez tester en 5 minutes.
Ce qu’il fait
- Analyse le texte à la recherche d’informations personnelles (emails, numéros de téléphone) et les remplace par des espaces réservés sûrs
- Détecte les tentatives d’injection de prompt à l’aide d’analyses par mots-clés, de correspondances de motifs structurels et de scoring heuristique — pas d’appel LLM, pas de latence LLM, pas de coût IA par scan
- Inclut 10 tests d’attaque adversaire réels (un de chaque catégorie) avec résultats de réussite/échec affichés directement dans la sortie du workflow — aucune credential requise pour l’exécuter
- Retourne une décision claire :
allow, review, ou block avec des codes de raison
Configuré en moins de 5 minutes — importez le workflow, cliquez sur « Execute Workflow », et voyez le bouclier arrêter une attaque d’exemple. Ensuite, intégrez vos propres entrées de test.
Construit pour la production, pas pour les démos
- Vérifications déterministes — la même entrée produit toujours la même décision
- Aucune dépendance externe — s’exécute entièrement dans les nœuds Code n8n
- Aucune credential requise pour la démo — il suffit d’importer et de cliquer
- Fermé par défaut en cas d’échec — si quelque chose d’inattendu se produit, il bloque plutôt que d’autoriser
10 catégories d’attaque testées :
injection directe, injection indirecte, extraction de prompt système, exfiltration de secrets, fuite d’informations personnelles, usurpation de rôle, obfuscation par encodage, instructions cachées, URLs suspectes, contournement du périmètre métier
Vous en voulez plus ? La version Pro ajoute :
- Validation de sortie (capture votre IA qui fuit des données, des instructions, ou fabrique des entités)
- Indicateurs de risque d’hallucination (vérification par canari, ancrage de source, détection de contradictions)
- 66 tests d’attaque adversaire avec un workflow auto-runner et un rapport de réussite/échec
- Journalisation Google Sheets pour les messages non traités (piste d’audit que vous pouvez partager avec vos clients)
- Alerting Telegram sur les entrées bloquées/suspectes
- Politique configurable : actions par type d’information personnelle, seuils d’injection, règles de périmètre métier
- Document récapitulatif de sécurité destiné aux clients
- Documentation du modèle de menace
→ AI Security Shield Pro — n8n Workflow Template
Lite : 10/10 tests intégrés réussis. Suite de régression Pro : 66/66 vérifiés. Aucune credential dans le fichier de workflow Lite.
Télécharger le JSON du workflow (GitHub Gist) GRATUIT
1 « J'aime »
L’état review est l’ajout le plus utile ici - c’est facile à oublier, mais en connectant cette branche à une étape humaine (un nœud Wait + reprise webhook, ou juste une notification Slack/Telegram avec des boutons d’approbation/refus), cela transforme ceci d’une couche de détection en un pipeline de modération complet. Une autre chose que j’ajouterais : une vérification de limite de débit au point d’entrée - des décisions block répétées du même ID utilisateur sur une courte période constituent un signal fort de sondage actif, méritant d’être enregistré séparément des blocages ponctuels.
Deux choses qui méritent d’être ajoutées à ce pattern :
Journal d’audit vers Google Sheets. Envoyez chaque décision block et review vers une ligne d’ajout dans Sheets — horodatage, ID utilisateur, décision, pattern correspondant, score brut. Deux raisons : (1) les audits de conformité veulent un enregistrement inviolable en dehors de l’app, et (2) après une semaine de trafic réel, vous pouvez ajuster vos seuils avec des données réelles au lieu de deviner. Le nœud Google Sheets rend cela une addition de 2 minutes.
Contournement de liste blanche pour les appelants de confiance. Si votre workflow est également appelé par des services internes ou des intégrations connues, ajoutez une étape Check précoce avant le scanner PII/injection : si l’en-tête X-Internal-Token correspond à une valeur hachée dans une Variable n8n, passez à la logique principale. Cela empêche vos propres outils d’être bloqués et garde la couche de sécurité axée sur les entrées non fiables uniquement.
Combinés, le flux complet devient : vérification appelant de confiance → redaction PII → score d’injection → allow/review/block → journal d’audit. Chaque étape est un sous-workflow séparé pour que vous puissiez les tester et les mettre à jour indépendamment.
Belle forme. Je rendrais l’enregistrement d’audit aussi explicite que la décision : version de la politique, codes de raison, identité de l’acteur ou de l’utilisateur, hachage de l’entrée brute ou exemple masqué, et quelle action en aval a été bloquée ou envoyée en révision.
Cela rend la branche d’examen utile ultérieurement, pas seulement une porte de validation binaire.
1 « J'aime »
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.