Custom AI Agent：把 MCP 接進 Burp Suite 的 Kotlin 擴充套件，與 1.0.0 修掉的那兩個漏洞
Burp Suite extension that adds built-in MCP tooling, AI-assisted analysis, privacy controls, passive and active scanning and more
秒懂
- 它是什麼？
- 這個專案在 Burp Suite 裡塞進 12 種 AI 後端、59 個 MCP 工具與 62 類弱點掃描，讓外部 AI 客戶端能反過來驅動 Burp。真正的看點不是功能清單，而是 0.9.x 那兩個被實際執行程式碼確認的缺陷，以及 1.0.0 如何把授權判斷挪到路由之前。
- 適合誰用？
- 已經在 0.9.0 到 0.9.2 之間跑過這個擴充套件的人，第一件事不是升級，而是照 SECURITY.md 的指示輪替 MCP token 與可能被送出的 session cookie，因為 PRIV-05 讓 cookie 以未經前綴遮蔽的 name=value 形式抵達 AI 後端。要用的人請從 Releases 取 1.0.0 的 JAR，或自行以 JDK 21 執行 ./gradlew clean shadowJar；只想在 BApp Store 生態內使用的人得再等，README 說 submission 自 2026 年 1 月起仍開著。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 13 天前。
- 用什麼語言寫的？
- 主要是 Kotlin（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是 Burp 與外部 AI 之間的搬運問題
手動測試的節奏常被工具切斷。你在 Burp 裡看到一個可疑的參數，複製到瀏覽器分頁、貼進某個 AI 對話框、等回覆、再把結論手動搬回 Repeater。Custom AI Agent 想消掉的就是這段搬運：它是一個載入 Burp Suite 的擴充套件，把 AI 後端、提示詞庫與掃描結果留在同一個視窗裡。README 對自己的定位寫得很直白，說它是 Burp Suite 與現代 AI 之間的橋。
目標讀者是已經在用 Burp 做滲透測試或漏洞獎金的人，而不是想找一個自動掃描器來取代人工判斷的團隊。這個差別在功能取捨上看得出來：它提供 62 類弱點的 AI 被動與主動掃描器，但被動掃描器是以 Burp 的 PassiveScanCheck 形式運作，也就是需要 Burp Pro。社群版仍可載入擴充套件，但少了這一塊。
名稱本身需要先講清楚，否則很容易裝錯東西。這個擴充套件在 BApp Store 的正式名稱是 Custom AI Agent，舊名 Burp AI Agent。改名的理由是 PortSwigger 的命名規範，同時避免與 Burp Suite 內建的 Burp AI 供應商混淆。GitHub 倉庫路徑、文件站網域與設定目錄 ~/.burp-ai-agent/ 都保留了舊識別字。你在 Extensions 清單與 Suite 分頁看到的名字會是 Custom AI Agent。
MCP 是主線：讓外部 AI 客戶端反過來操作 Burp
這個擴充套件最實質的設計是把 Burp 當成 MCP 伺服器端。README 說有 59 個 MCP 工具，讓 Claude Desktop 或任何 MCP 客戶端能自主驅動 Burp；其中 8 個是擴充套件原生的 AI 工具，只出現在 store 建置裡，full 建置才給滿 59 個。這個數字差異不是版本號的裝飾，而是兩種發佈管線的分歧，後面會再談。
資料流的方向值得停下來想一下。傳統用法是你坐在 Burp 前面，把請求丟給 AI 看。MCP 模式反過來：外部 AI 客戶端透過工具呼叫去讀寫 Burp 的狀態，Burp 變成被驅動的一方。這個反向關係帶來一個新問題，就是範圍控制。README 提到 Scoped MCP Access，可以選擇把每一個 MCP 工具限制在你設定的 in-scope 主機內，理由是外部 AI 客戶端不該藉由 Burp 觸及範圍外的目標。對照 0.9.x 的 SEC-04 來看，這條界線原本守得不牢：MCP 的存取控制檢查沒有在已解析的路由上執行，外部存取開啟時，監聽器會接受未經認證的工具呼叫。1.0.0 的修法是把判斷移到路由之前。
工具呼叫的來源也被分開處理。從模型輸出解析出來的工具呼叫，在 1.0.0 之前會直接抵達 Burp；現在需要你核准。分級是 fail closed 的：唯讀且有界線的工具靜默執行，其餘一律先彈出核准卡片，遇到不認識的工具名稱則每次都確認，不會默默放行。這個設計會拖慢自動化流程，尤其是你原本期待 AI 連續跑十幾個步驟的時候。它是刻意選了慢。
12 種後端與 3 種隱私模式，但遮蔽邏輯有個具體的破口
後端清單很長：Burp AI 內建、Anthropic、Ollama、LM Studio、NVIDIA NIM、Perplexity、通用 OpenAI 相容端點，以及 Gemini CLI、Claude CLI、Codex CLI、OpenCode CLI、Copilot CLI 這幾個命令列工具。對不想把請求送出本機的人，Ollama 與 LM Studio 是文件裡明確列出的本地選項。
隱私模式分 STRICT、BALANCED、OFF 三級，宣稱在資料離開 Burp 之前先做遮蔽。這裡必須講清楚 0.9.x 發生了什麼，因為它直接說明遮蔽層的脆弱程度。PRIV-05 被列為 high：session cookie 在 STRICT 與 BALANCED 模式下未經遮蔽就送到 AI 後端。成因寫得很細，被動掃描器把 cookie 輸出成裸的 name=value，丟掉了前綴資訊，而遮蔽邏輯正是靠前綴在比對；結果只有名字剛好叫 session 的 cookie 會被攔下。也就是說，一個叫 SESSIONID 或 auth_token 的 cookie 會直接通過。
這件事的教訓不在於「記得開 STRICT」，而是遮蔽是建立在字串特徵上的，特徵一旦在管線中途被改寫就失效。1.0.0 修好了這個特定路徑，但同一個模式值得你在採用後自己驗證：找一個非標準命名的 cookie，送一次請求，看 AI 後端實際收到什麼。README 沒有提供這類自我驗證的操作步驟，這是文件偏薄的地方。
從原始碼建置：full 與 store 是兩條不同的產物
安裝路徑有兩條。最省事的是從 Releases 下載 JAR，README 明說這個專案不在 BApp Store 上，submission 自 2026 年 1 月起一直開著。想自己編譯的話，需要 Java 21：
git clone https://github.com/six2dez/burp-ai-agent.git cd burp-ai-agent JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar
預設是 full 建置，產出 build/libs/Custom-AI-Agent-full-<version>.jar，內含全部 59 個 MCP 工具。加上屬性切到 store 建置：
JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar -PstoreBuild=true
此時產物是 build/libs/Custom-AI-Agent-<version>.jar，只留 8 個擴充套件原生的 AI MCP 工具。兩個檔案名稱不同，full 帶 -full 後綴，這點在寫自動化腳本時要小心，否則很容易載到錯的那個。
載入方式是 Burp 的標準流程：Extensions > Installed > Add，型別選 Java，指向 JAR。首次執行時擴充套件會把內附的 agent profile 自動裝到 ~/.burp-ai-agent/AGENTS/，之後你只要把額外的 *.md 檔丟進這個目錄就能新增自訂 profile。設定目錄沿用舊的 burp-ai-agent 名稱，與擴充套件顯示名稱不一致，這是刻意的延續性安排，但也意味著你日後在檔案系統裡找設定時要用舊名字去找。
0.9.x 使用者面對的不是升級，而是憑證輪替
README 開頭放了一個顯眼的警告框：如果你正在跑 0.9.0、0.9.1 或 0.9.2，升級前先讀 SECURITY.md 的安全公告。兩個缺陷都由實際執行出貨程式碼確認，影響每一個已發佈的 0.9.x 版本，其中一個要求輪替可能已經外洩給第三方的憑證。兩者都在 1.0.0 修好，而且沒有 CVE 或 GHSA 編號，README 直接說不要去找。
SEC-04 被標為 critical。除了前面提到的未認證工具呼叫，本地模式下 Origin、Host、User-Agent 檢查與安全回應標頭在已匹配的路由上同樣形同虛設。第二個缺陷 SEC-07 講的是 MCP token 在埠接管情境下外洩：本機行程搶佔 MCP 埠並回送身分標頭，就能收割一個擁有完整 MCP 工具權限的 token。1.0.0 的作法是讓接管客戶端改為提出 HMAC 持有證明，並在 TLS 下把伺服器憑證固定到自己的 keystore。
同一批修補還包括 SsrfGuard 對替代 IP 記法的分類，例如 http://2852039166/ 這種 169.254.169.254 的十進位寫法，不再只因為寫法不同就繞過私有與 link-local 警告，而且分類過程完全不做名稱解析。命令列參數改為依白名單加引號，關掉了一條從設定匯入到命令執行的路徑，針對的是 foo;id、$(cmd) 這類不含空白卻帶中介字元的值。另外工具執行、後端 HTTP 與 MCP 的 stop() 都移出了 Swing 的事件分派執行緒。
這裡有個判斷上的分歧點。這些修補是被外部審查逼出來的，而 1.0.0 是第一個穩定版。把這解讀成「已經成熟」或解讀成「品質堪憂」都不準確；準確的說法是，這個專案的攻擊面包含一個會接收外部工具呼叫的本機監聽器，而它花了到 1.0.0 才把授權判斷放到正確的位置。
測試覆蓋率與 detekt 基準線透露的維護訊號
README 對 1.0.0 的驗證給了具體數字：測試從 660 個成長到 1131 個，橫跨 158 個類別，專案行覆蓋率從 34% 升到 58%，detekt 基準線從 1096 縮到 1040 而不是變大。
58% 這個數字要放在正確的位置看。它比 34% 好得多，但仍有四成左右的行沒有被測試涵蓋，而這個擴充套件處理的是憑證、cookie 與外部工具呼叫。如果你打算在正式環境或客戶專案裡用它，這個覆蓋率意味著你最好自己驗證關鍵路徑，而不是把測試數字當成安全保證。detekt 基準線縮小這件事倒是個正向的維護訊號：多數專案的靜態分析基準線只會膨脹，願意把它壓下來代表有人真的在還技術債。
版本節奏也值得注意。v0.9.1 與 v0.9.2 都發佈在 2026 年 7 月 29 日，相隔約半小時，v1.0.0 則在 8 月 22 日。這種密集的補丁發佈通常對應到剛發現的問題，而 0.9.x 那兩個缺陷正好落在這個區間。倉庫最後一次推送是 2026 年 9 月 2 日，比 1.0.0 晚。授權是 MIT，這對商業滲透測試工作相對友善，但 README 沒有談第三方相依套件的授權，這部分需要你自己在採用前確認，我無法從現有材料判斷。
什麼時候不該用它：拿它跟純 MCP 橋接方案比
如果你的需求只是「讓 Claude Desktop 能呼叫 Burp」，Burp Suite 本身與 MCP 生態裡有更輕的選擇：一個只做工具暴露的 MCP 伺服器，把請求與掃描結果轉成工具介面，不碰 AI 後端、不做隱私分級、不內建提示詞庫。兩者的差別在於責任邊界。純橋接方案把「要不要遮蔽、要不要核准」留給外部客戶端與你自己的流程；Custom AI Agent 把這些決定收進擴充套件內部，用 STRICT/BALANCED/OFF 與核准卡片來表達。
這個收攏有好處也有代價。好處是設定集中，你不用在每個 MCP 客戶端重複實作遮蔽規則。代價是當遮蔽邏輯出錯時，錯誤的影響範圍也集中，PRIV-05 就是這個形狀：一個前綴比對的假設被上游的格式化改寫打破，結果在兩個號稱會遮蔽的模式下都失效。純橋接方案不會有這個特定缺陷，因為它根本沒有內建遮蔽層，但你得自己處理。
另一種不該用的情境是高度自動化的批次流程。模型吐出的工具呼叫需要人工核准，未知工具名稱一律 fail closed，這對互動式手動測試是合理的摩擦，對無人值守的管線則是阻礙。README 沒有描述任何繞過核准的設定鍵，所以如果你的流程需要 AI 連續執行數十個工具呼叫而不中斷，這個擴充套件目前的設計方向與你的需求相反。
最後是 Burp 版本。被動掃描器依賴 PassiveScanCheck，這是 Burp Pro 才有的介面。社群版使用者仍能載入擴充套件並使用聊天與 MCP 部分，但 62 類弱點的被動掃描這一塊拿不到。README 沒有逐一列出哪些功能在社群版可用，這是我在材料裡找不到答案的地方，採用前值得自己確認。
編輯結論
已經在 0.9.0 到 0.9.2 之間跑過這個擴充套件的人，第一件事不是升級，而是照 SECURITY.md 的指示輪替 MCP token 與可能被送出的 session cookie，因為 PRIV-05 讓 cookie 以未經前綴遮蔽的 name=value 形式抵達 AI 後端。要用的人請從 Releases 取 1.0.0 的 JAR，或自行以 JDK 21 執行 ./gradlew clean shadowJar；只想在 BApp Store 生態內使用的人得再等，README 說 submission 自 2026 年 1 月起仍開著。決定採用前先確認三件事：你的 Burp 是否為 Pro（被動掃描器依賴 PassiveScanCheck）、你要的是 full 還是 store 建置（兩者 MCP 工具數是 59 對 8）、以及你能不能接受模型吐出的工具呼叫需要人工逐次核准。
社群筆記