如果你正在構建處理客戶訊息、表單提交或任何使用者生成文本的 AI 工作流程，你距離洩漏資料、暴露系統提示詞或讓某人劫持你的代理只有一個精心設計的輸入之遙。
這個工作流程為你提供了一個可以在 5 分鐘內測試的有效安全層。
功能
- 掃描文本中的 PII（電子郵件、電話號碼），並用安全占位符進行編修
- 使用關鍵字分析、結構型態匹配和啟發式評分來檢測提示詞注入嘗試 — 無需 LLM 呼叫、無 LLM 延遲、無每次掃描 AI 成本
- 包含 10 個真實的對抗性攻擊測試（每個類別各一個），工作流程輸出中直接顯示通過/失敗結果 — 無需憑證即可執行
- 返回明確決策：
allow、review 或 block，附帶原因代碼
在 5 分鐘內設定 — 匯入工作流程，點擊「Execute Workflow」，看防護層捕捉範例攻擊。然後改用你自己的測試輸入。
為生產環境打造，不是為了示範
- 確定性檢查 — 相同輸入總是產生相同決策
- 無外部依賴 — 完全在 n8n Code 節點內執行
- 示範無需憑證 — 只需匯入並點擊
- 預設 fail_closed — 如果發生意外狀況，會阻止而不是允許
測試的 10 個攻擊類別：
直接注入、間接注入、系統提示詞提取、機密資料竊取、PII 洩漏、角色冒充、編碼混淆、隱藏指令、可疑 URL、業務範圍繞過
需要更多功能？ Pro 版本新增：
- 輸出驗證（捕捉你的 AI 洩漏資料、指令或偽造實體）
- 幻覺風險標誌（金絲雀驗證、來源接地、矛盾檢測）
- 66 個對抗性攻擊測試，配備自動執行器工作流程和通過/失敗報告
- Google Sheets 死信日誌（你可以與客戶共享的稽核軌跡）
- 針對被阻止/可疑輸入的 Telegram 警報
- 可配置政策：每個 PII 類型的操作、注入閾值、業務範圍規則
- 客戶端安全摘要文件
- 威脅模型文件
→ AI Security Shield Pro — n8n Workflow Template
Lite：10/10 內建測試通過。Pro 迴歸套件：66/66 已驗證。Lite 工作流程文件中無憑證。
下載工作流程 JSON（GitHub Gist） 免費
1個讚
應用 review 狀態是這裡最實用的補充——容易被忽視，但將該分支連接到人工環節（一個等待節點 + webhook 恢復，或只是一個帶有核准/拒絕按鈕的 Slack/Telegram 通知）就能將其從檢測層轉變為完整的內容審核管道。另一件我也想補充的事：在入口點添加速率限制檢查——來自同一使用者 ID 的重複 block 決策在短時間內出現，是主動探測的強烈信號，值得與一次性屏蔽分開記錄。
此模式還值得新增兩項功能：
**稽核日誌到 Google Sheets。**將每個 block 和 review 決策導入 Sheets 附加列 — 時間戳記、使用者 ID、決策、符合的模式、原始分數。有兩個原因：(1) 合規稽核需要應用程式外部的防篡改紀錄，(2) 經過一週的實際流量後，你可以用實際資料調整臨界值，而不是猜測。Google Sheets 節點讓這項工作只需 2 分鐘就能完成。
**受信任呼叫者的允許清單略過。**如果你的工作流程也由內部服務或已知整合呼叫，請在 PII/注入掃描器之前新增早期 Check 步驟：如果 X-Internal-Token 標頭符合 n8n 變數中的雜湊值，則跳過到主要邏輯。這可防止自己的工具被封鎖，並讓安全層僅專注於不受信任的輸入。
結合兩者，完整流程變為：受信任呼叫者檢查 → PII 編輯 → 注入分數 → 允許/檢查/封鎖 → 稽核日誌。每個步驟都是獨立的子工作流程，以便你可以獨立測試和更新它們。
不錯的設計。我會讓稽核記錄和決策一樣明確：政策版本、原因代碼、執行者或使用者 ID、原始輸入雜湊或編輯過的樣本，以及哪個下游動作被阻擋或送去審查。
這樣的話，審查分支之後就會很有用，不只是個通過/失敗的關卡。
1個讚
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.