Wenn du KI-Workflows aufbaust, die Kundennachrichten, Formulareingaben oder benutzergenerierten Text verarbeiten, bist du nur eine geschickt formulierte Eingabe entfernt davon, Daten preiszugeben, dein System-Prompt offenzulegen oder jemanden deinen Agent hijacken zu lassen.
Dieser Workflow bietet dir eine funktionierende Sicherheitsschicht, die du in 5 Minuten testen kannst.
Was er tut
- Scannt Text nach PII (E-Mails, Telefonnummern) und ersetzt sie durch sichere Platzhalter
- Erkennt Prompt-Injection-Versuche mithilfe von Keyword-Analyse, strukturellem Pattern Matching und heuristischer Bewertung — kein LLM-Aufruf, keine LLM-Latenz, keine KI-Kosten pro Scan
- Enthält 10 echte adversariale Attack-Tests (einer aus jeder Kategorie) mit Pass/Fail-Ergebnissen direkt in der Workflow-Ausgabe — keine Anmeldedaten erforderlich
- Liefert eine klare Entscheidung:
allow, review oder block mit Grund-Codes
In weniger als 5 Minuten einrichten — importiere den Workflow, klicke auf „Execute Workflow
1 „Gefällt mir“
Der review-State ist die nützlichste Ergänzung hier – er ist leicht zu übersehen, aber das Verschalten dieses Zweigs mit einem Human-in-the-Loop-Schritt (ein Wait-Node + Webhook-Resume oder einfach nur eine Slack-/Telegram-Benachrichtigung mit Approve/Deny-Buttons) wandelt dies von einer Erkennungsebene in eine vollständige Moderations-Pipeline um. Eine Sache, die ich noch hinzufügen würde: eine Rate-Limit-Prüfung am Einstiegspunkt – wiederholte block-Entscheidungen von derselben User-ID in einem kurzen Zeitfenster sind ein starkes Zeichen für aktives Probing und sollten separat von einmaligen Blocks protokolliert werden.
Zwei Dinge, die zu diesem Muster passen:
Audit-Log zu Google Sheets. Leite jede block- und review-Entscheidung an eine Sheets-Zeile weiter — Zeitstempel, Benutzer-ID, Entscheidung, gefundenes Muster, Rohwert. Zwei Gründe: (1) Compliance-Audits benötigen einen manipulationssicheren Datensatz außerhalb der App, und (2) nach einer Woche echtem Traffic kannst du deine Schwellenwerte mit echten Daten anpassen, anstatt zu raten. Der Google Sheets Node macht das zu einer 2-Minuten-Ergänzung.
Allowlist-Bypass für vertrauenswürdige Aufrufer. Wenn dein Workflow auch von internen Services oder bekannten Integrationen aufgerufen wird, füge einen frühen Check-Schritt vor dem PII-/Injection-Scanner hinzu: Wenn der X-Internal-Token-Header einem gehashten Wert in einer n8n-Variable entspricht, springe zur Hauptlogik. Dies verhindert, dass dein eigenes Tooling blockiert wird, und hält die Sicherheitsschicht auf nicht vertrauenswürdige Eingaben konzentriert.
Insgesamt wird der vollständige Flow zu: Vertrauenswürdiger-Aufrufer-Check → PII-Redaktion → Injection-Bewertung → zulassen/überprüfen/blockieren → Audit-Log. Jeder Schritt ist ein separater Sub-Workflow, sodass du sie unabhängig voneinander testen und aktualisieren kannst.
Gute Form. Ich würde den Audit-Datensatz genauso explizit wie die Entscheidung gestalten: Policy-Version, Reason-Codes, Actor oder User-ID, Raw-Input-Hash oder reduziertes Sample und welche nachgelagerte Aktion blockiert oder zur Überprüfung weitergeleitet wurde.
Das macht den Review-Branch später wirklich nützlich, nicht nur ein Pass/Fail-Gate.
1 „Gefällt mir“
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.