Cisco 在 39 分鐘內 merge 我的 PR — 為什麼提示詞防禦會變成新的 SQL Injection
39 分鐘
那是 Cisco AI Defense 團隊從收到我的 PR 到 merge 進主分支的時間。
873 個 star 的 repo（cisco-ai-defense/mcp-scanner），27 分鐘 approve，再 12 分鐘 merge。我那時候在通勤的捷運上盯著 GitHub 通知，手抖到差點下錯站。
但這篇不是要講那 39 分鐘。
是要講讓那 39 分鐘變成可能的，前面四個月。
起心動念：一次「順手」的掃描
時間倒回 2026 年 1 月。
我在開發 UltraProbe — 一個 AI 安全掃描器。產品的核心邏輯之一，是檢查 LLM 系統提示有沒有對抗 prompt injection 的基本防禦。
那時我心想：「我自己 dogfooding 一下吧，掃個一兩百個公開的提示詞看看。」
結果掃完後，我盯著螢幕看了五分鐘。
78% 拿 F。
不是「設計得不夠好」的 F，是完全沒有任何防禦語句的 F。沒有 role-escape 防禦，沒有 output manipulation 防禦，沒有 input validation 邊界宣告，什麼都沒有。
包括我自己之前隨手寫的那些 prompt。
那一刻的感覺很複雜。一方面意識到 OWASP 把 Prompt Injection 列為 LLM 應用的第一大威脅，是真的有原因的 — 不是學術擔憂，是現場現實。另一方面，我開始想：
如果連用 AI 做產品的人都沒在做，那一般企業客服 bot、內部 agent、自動化流程裡的提示詞，會是什麼樣子？
這個問題後來變成了我接下來四個月的主軸。
研究：把掃描器變成 npm 套件
第一個版本很粗暴：把 UltraProbe 裡的掃描邏輯抽出來，包成 CLI。
12 個攻擊向量，純 regex，零依賴，1 毫秒跑完。
npx prompt-defense-audit "You are a helpful assistant."
# Grade: F (8/100, 1/12 defenses)
我刻意不用 LLM 來檢查 LLM。原因很簡單：
- 可重現 — regex 給定相同輸入永遠給同一個結果。LLM 不行。
- 零成本 — 跑一萬次跟跑一次一樣便宜。
- 可審計 — 每個 finding 都能溯源到一行 regex pattern。
- 靜態分析友善 — 可以當成 CI/CD gate，不用網路、不用 API key。
把它丟上 npm（prompt-defense-audit），然後做了一件我以為沒人會在意的事：用它去掃市面上的開源 AI 工具。
掃了 modelcontextprotocol/servers 的 7 個官方 server — 6 個拿 F。 掃了 LangChain 的範例 prompt — 大部分 D 或 F。 掃了我自己 OpenClaw fleet 的 SOUL.md — 50/100，D 級，6/12 防禦。
數據開始有重量了。
被採用（一）：Cisco — 39 分鐘
2026 年 4 月初。
我在 Cisco AI Defense 的 mcp-scanner repo 裡看到一個 issue 在討論「如何系統化檢查 MCP server 的 prompt 暴露面」。
我看完想了三件事：
- 我有現成的工具
- 他們的 codebase 是 Python，我的是 TypeScript
- 那就用 Python 重寫一遍，當作 PR 提交
花了一個下午把 12 個 vector 翻成 Python，寫了 23 個 unit test，讓它符合他們現有的 Analyzer interface。PR #146 提交。
27 minutes later: ✅ Approved
12 minutes later: ✅ Merged
Cisco 是全球最大的網路設備公司之一。他們的 AI Defense 團隊不是隨便 merge 個 PR — 他們審查很嚴。能在 39 分鐘內走完 review + merge，意思是：
他們本來就在等這個東西。
只是市場上沒有。所以我寫了一個，正好。
被採用（二）：Microsoft — 主動指派
幾天後，我在 Microsoft 的 agent-governance-toolkit repo 留了一個 issue #821，提議加入一個 PromptDefenseEvaluator 元件。
不是 PR，是 issue。我寫了問題、提了 12-vector 框架、附上 prompt-defense-audit 的設計理念，然後就去吃晚餐了。
回家打開信箱：
Hi! Thanks for the proposal. I'm assigning this to you. Please proceed with a draft PR.
— imran-siddique（Microsoft Engineering Architect, Bellevue）
Microsoft 工程主管主動把 issue 指派給一個外部貢獻者。
我接下來一週寫了 1,110 行程式碼、58 個測試，遵循他們現有的 SupplyChainGuard 設計模式，用 black / ruff / mypy --strict 全綠，Draft PR #854 提交。
它不是隨手 merge — 大公司流程慢，現在還在 review。但它在那裡，是 Microsoft AI 治理工具中的一個官方提案。
被採用（三）：NVIDIA — 沉默的 14 天
不是每次都有戲劇性結局。
NVIDIA garak（LLM 紅隊測試工具）在 issue #1666 討論「靜態 prompt 防禦審計」。我寫了四萬字的方法論討論，附上 Python 實作的兩個方案。
leondz（核心 maintainer）的回覆風格嚴格 — 之前審 PR #1668 時要求「每個 vector 必須有 trigger、必須有 test、最少 30 個 prompt」。我這次直接把這些都符合了。
留言發出去到現在，14 天，沒有回應。
不一定是壞事 — 可能是 maintainer 在忙、可能是 issue 不在優先級、可能是他們有別的方向。但這就是開源世界的現實：
你能控制提交品質，但不能控制反應速度。
Cisco 39 分鐘、Microsoft 一週、NVIDIA 14 天 silence。同樣的工具，三種命運。
為什麼這件事重要 — 趨勢論證
我寫這篇不是要講三個 PR 的故事。是要講接下來兩到三年會發生什麼事。
一、AI Agent 與客服正在指數成長
2024 年，企業裡的 LLM 應用主要是 chatbot。 2025 年，多數企業開始部署 RAG。 2026 年，Agent + 工具呼叫變成新基線。
每一個 agent 都需要一個系統提示。每一個客服 bot 都需要一個系統提示。每一個內部自動化流程都需要一個系統提示。
而 78% 的生產環境提示詞，連一行防禦都沒有。
這個比例不會自己變好。因為：
二、模型更新速度遠快於人類學習速度
GPT-4 → GPT-4o → GPT-5。 Claude 3 → Claude 4 → Claude Opus 4.7。 Gemini 1.5 → 2.0 → 2.5。
每三到六個月，底層模型的行為就被洗掉一次。你針對某個版本調好的 prompt，下個版本可能整個崩潰。
但攻擊者不需要重學。Prompt injection 的核心模式（role escape、instruction override、context confusion）跨模型通用，因為它們利用的是 LLM 的本質結構，不是某個版本的 quirk。
這個不對稱會越來越嚴重。防禦端要持續適應新模型，攻擊端只要知道一招就夠用。
三、企業是 AI 的優先採用者
不是個人開發者。不是新創。是企業。
因為他們有：
- 預算 — API 成本不是問題
- 流程 — 已經有客服中心、業務系統、內部知識庫，套 LLM 是天然延伸
- 動機 — 一個 agent 可以取代 30% 的初階人力
但企業也有：
- 資安壓力 — 一旦出事，董事會罵的力道是 startup 的十倍
- 合規需求 — GDPR、HIPAA、SOC2 全都在重新框架 LLM 風險
- 聲譽風險 — 客服 bot 講錯話，新聞會寫一週
換句話說，企業是最在意防禦、但也最沒時間自己做防禦的客戶。
四、底層防禦會變成新的 SQL Injection
回想 2005 年。SQL Injection 是當時最常見的網站攻擊。但解法很簡單：parameterized query。問題是大部分開發者不知道、或寫得太趕沒做。
OWASP 把它列在 Top 10 第一名整整十年，業界才慢慢補完。
Prompt Injection 在 2026 年的位置，跟 SQL Injection 在 2005 年很像：
- ✅ 攻擊向量已知
- ✅ 防禦模式已知
- ✅ 工具已經有
- ❌ 大部分人還沒做
差別是 — Prompt Injection 的後果可能更嚴重。SQL Injection 大不了 dump 資料庫；Prompt Injection 可以讓 agent 做出它有權限執行的任何動作：發 email、刪檔案、轉帳、外洩內部對話。
所以呢
我做 prompt-defense-audit 不是因為它酷，是因為它簡單到不該是個問題，但偏偏所有人都漏掉了。
12 個 regex pattern。1 毫秒。零依賴。可以塞進 CI/CD 當 gate。
如果你的產品裡有任何 LLM 相關的 prompt — 客服 bot、agent 系統指令、RAG 模板、開發中的 chatbot — 花 30 秒掃一下：
npx prompt-defense-audit "你的系統提示貼這裡"
拿到 F 不丟臉。沒拿 F 才丟臉，因為那意味著你連跑都沒跑過。
接下來
prompt-defense-audit 是我接下來兩年的主線之一。下個版本會加：
- 內網企業版 — 不上傳 prompt，全在客戶 VPC 裡跑
- CI/CD Action — 已上 GitHub Marketplace，PR comment 自動帶分數
- vector 擴充 — 從 12 個擴到 24 個，覆蓋 multi-modal injection
如果你在企業負責 AI 安全 / 合規 / 採購，歡迎在 Discord 或 GitHub 找我。我們需要更多現場 case 來驗證 vector 設計。
四個月前，我只是想 dogfood 一下自己的工具。
四個月後，三家美國科技巨頭的 repo 裡有我的 commit。
中間沒有什麼天才時刻。就是看到一個明顯的洞，剛好沒人在補，剛好我有工具能補。
AI Agent 普及前，提示詞防禦是個冷門題目。普及後，它會變成基礎設施。
而基礎設施的窗口，正在打開的這幾個月，是最安靜也最關鍵的時刻。
相關資源
- 工具：prompt-defense-audit on GitHub / npm
- CI 整合：GitHub Action
- 案例研究：我們審計了 7 個官方 MCP server，6 個拿 F
- 線上掃描：UltraProbe
- 社群：Ultra Lab Discord