Cisco 在 51 分鐘內 merge 我的 PR：為什麼提示詞防禦會變成新的 SQL Injection
目錄
51 分鐘
那是 Cisco AI Defense 團隊從收到我的 PR 到 merge 進主分支的時間。
873 個 star 的 repo（cisco-ai-defense/mcp-scanner），39 分鐘 approve，再 12 分鐘 merge。我那時候在通勤的捷運上盯著 GitHub 通知，手抖到差點下錯站。
但這篇不是要講那 51 分鐘。
是要講讓那 51 分鐘變成可能的，前面四個月。
起心動念：一次「順手」的掃描
時間倒回 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，51 分鐘
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 提交。
39 minutes later: ✅ Approved
12 minutes later: ✅ Merged
Cisco 是全球最大的網路設備公司之一。他們的 AI Defense 團隊不是隨便 merge 個 PR，他們審查很嚴。能在 51 分鐘內走完 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，PR 送出兩天後合併進 Microsoft 的 AI 治理工具。
被採用（三）：一個上游紅隊測試專案，沉默的 14 天
不是每次都有戲劇性結局。
第三個標的是一個知名的開源 LLM 紅隊測試框架，它的 issue 區正在討論「靜態 prompt 防禦審計」。我寫了四萬字的方法論討論，附上 Python 實作的兩個方案。
那個專案的核心維護者審查風格嚴格：之前審別的 PR 時要求「每個 vector 必須有 trigger、必須有 test、最少 30 個 prompt」。我這次直接把這些都符合了。
留言發出去到現在，14 天，沒有回應。
不一定是壞事，可能是維護者在忙、可能是 issue 不在優先級、可能是他們有別的方向。但這就是開源世界的現實：
你能控制提交品質，但不能控制反應速度。
Cisco 51 分鐘、Microsoft 兩天、第三個專案 14 天沉默。同樣的工具，三種命運。
為什麼這件事重要：趨勢論證
我寫這篇不是要講三個 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 不是因為它酷，是因為它簡單到不該是個問題，但偏偏所有人都漏掉了。
17 個攻擊向量（截至 2026-09-26），純 regex。1 毫秒。零依賴。可以塞進 CI/CD 當 gate。
如果你的產品裡有任何 LLM 相關的 prompt（客服 bot、agent 系統指令、RAG 模板、開發中的 chatbot），花 30 秒掃一下：
npx prompt-defense-audit "你的系統提示貼這裡"
拿到 F 不丟臉。沒拿 F 才丟臉，因為那意味著你連跑都沒跑過。
接下來
prompt-defense-audit 是我接下來兩年的主線之一。截至 2026-04-24 的規劃，下個版本會加：
- 內網企業版：不上傳 prompt，全在客戶 VPC 裡跑
- CI/CD Action：已上 GitHub Marketplace，PR comment 自動帶分數
- vector 擴充：從 12 個擴到 24 個，覆蓋 multi-modal injection（2026-05-08 發布的 v1.4.0 已先從 12 個擴到現在的 17 個）
如果你在企業負責 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