Postman AI 外掛爭議：自動安裝與 hook 自我批准，誰替你決定信任？（2026）

2026 年 10 月 25 日，開發者 indicava 在 GitHub 公開了一份關於 Postman AI 外掛的事件報告，標題指控桌面版自動安裝 Codex／Claude 外掛，且安裝器嘗試信任自己的啟動 hook。這份報告在 11 月 3 日（UTC）的 Hacker News 討論再次受到關注。真正需要拆開的，是安裝整合、允許連線、信任啟動指令，究竟由誰決定。

以下先還原報告的訴求，再對照固定版本的安裝器與宿主官方文件，最後討論產品該怎麼設計同意。AlphaLab 這次做的是公開資料與程式碼查核，未在乾淨 Mac 重跑安裝，也未觀測原回報者的網路傳輸。

一、Postman AI 外掛爭議：先讀清楚作者證明了什麼

報告描述一台 Mac：Postman 桌面版為 12.33.4，Codex 外掛為 1.1.0，Claude 外掛為 2.0.1。作者貼出的 10 月 24 日日誌帶有 auto-existing-upgrade，並記錄兩個 Agent 的安裝結果；他也列出使用者層級設定、啟動 hook、遠端 MCP 與另外出現的 CLI。這些是作者保留下來的單機觀察，不能直接推成所有桌面版使用者都受影響。

it does not claim to establish data exfiltration.

中文：這份報告並未宣稱已證實資料外洩。

indicava，GitHub Issue #14370

作者要求停止替既有使用者自動安裝、把 hook 信任交還宿主中的使用者，並說清楚觸發版本、同意流程及受影響檔案。他還要求完整移除途徑、尊重移除選擇，以及縮小預設指令的適用範圍。重點是控制權，不必先把事件定性成資料竊取，才能討論是否越界。

二、原始碼確認了「嘗試自我批准」，沒有替每一次成功背書

報告把程式碼固定在 6c8e452e0f4237f4bcc0901cb1ac442dec707e49。在該版 Codex 安裝流程中，安裝與重複外掛處理之後，確實會呼叫 approvePostmanHook(system)；這項呼叫可以直接從 Postman 自己的倉儲核對。

Approves only Postman’s current hook after installation

中文：安裝後，只批准 Postman 目前這個 hook。

Postman 安裝器 codex-hooks.ts 的程式註解

對應實作透過 Codex app-server 列出 hooks，找出 Postman 的項目，取得目前雜湊，再用 config/batchWrite 更新 hooks.state 中的 trusted_hash。它會先讀取已安裝的指令檔，並再次確認雜湊未變；若 API 不支援或流程出錯，則記錄提示。

這裡要保留兩個結論。第一，程式確實設計了由安裝器發起的信任寫入嘗試。第二，程式有跳過、失敗與寫入後再確認的分支，因此「有這條路徑」不能替代某台機器的執行證據。即使設定裡有信任紀錄，單看那個欄位也不足以辨認是哪一次操作建立它。

檢查雜湊能降低批准到不同版本的風險；但「確認內容一致」與「確認使用者同意」仍是不同問題。前者回答批准的是哪一份，後者回答誰有權批准。

三、啟動指令改變的是工作入口，不只是多一個工具

該版 hook 定義把命令掛在 SessionStart，匹配 startup|clear|compact；隨附的指令文字則要求一般、非瑣碎的 API 工程工作先載入 Postman 的 api-engineer skill，涵蓋設計、實作、測試、監控與部署等工作。

It is the default entry point and routes to the specific postman skills from there.

中文：它是預設入口，再由這裡導向特定 Postman skills。

Postman session-start-context.md，報告所固定版本

同一份文字也列出例外：純問題與小幅單行修改不必載入；使用者直接要求及專案指令優先。特定意圖也可直接進入相應 skill；已派送的 subagent 則被告知忽略這段總入口指令。這些限制應一起讀，不能把它改寫成「強制劫持所有任務」。然而，讓廣泛 API 工作預設經過某套產品的流程，依然比「使用者叫我用 Postman 時才啟用」涵蓋得更廣。

這與產品定位相符：Postman 官方說明將外掛描述為透過 CLI 建置、測試與管理 API 的入口，並會按任務選擇 CLI 或 MCP。整合有其用途；爭議在於這項選擇如何進入另一個 Agent 的日常工作。

四、官方信任機制與外洩指控，分兩張證據表

截至 2026 年 11 月 4 日查閱，OpenAI 外掛文件明確區分安裝／啟用與 hook 信任：外掛所附的非受管 hook，要經使用者審閱、信任後才執行。官方 Hooks 文件說明信任綁定目前雜湊，並提供 CLI 的 /hooks 檢查入口。這是目前文件描述的規則，不是本文對事件當時所有 Codex 版本的重現結果。

另一個宿主也有明確的能力提醒：Anthropic 的外掛安全文件指出，已安裝外掛可用目前使用者權限執行程式，應先審閱內容。這支持把外掛安裝當作權限決定；不能反過來當作 Postman 在該事件中已執行某項資料存取的證據。

在固定版本的 MCP 設定中，遠端端點是 https://mcp.postman.com/mcp。端點設定回答「準備連去哪裡」；作者所貼的認證錯誤回答「該次初始化碰到什麼問題」。要證實資料外洩，還得辨認傳送內容、目的地、時間與接收結果，這份設定與錯誤訊息不能代答。

因此，本文不沿用討論串較強烈的「所有 API 資料被分享」推論，也不把認證失敗解讀成整套工具絕對沒有其他網路活動。安裝、授權、指令載入與資料傳送，各自需要自己的證據。

五、AlphaLab 的判讀：方便連動，應該留下可以拒絕的邊界

安裝器可以代辦，批准者仍要清楚

一個入口替多套工具裝好整合，確實能省去重複設定。合理的代辦應先列出會動哪些宿主、安裝到哪一層、啟用哪些遠端服務，以及哪些步驟涉及執行指令。把這些選項合成一次模糊的同意，使用者就難以理解自己授權的總量。

讀得到設定，不等於得到跨工具的同意

桌面程式與 Agent 若以同一個作業系統帳號執行，檔案可寫入範圍可能重疊。我的判斷是：產品不能只用「技術上能修改」當作修改別人工具設定的理由。同意介面應讓人知道接下來會影響哪一個宿主，並讓該宿主對啟動指令保留可辨認的批准步驟。

預設入口本身，也是值得治理的資源

外掛不只增加工具清單，也能改變模型先讀哪套流程、優先用哪個服務。這會影響使用者注意力、排錯成本與團隊依賴。當整合的價值來自「更常被選到」，產品就更應把觸發條件做窄，讓使用者主動擴張，而不是靠廣泛啟動指令取得日常入口。

我同意作者把跨工具安裝與 hook 自我批准視為需要嚴肅回答的同意問題：公開程式碼已讓後者成為可檢查的設計。我存疑的是從單機報告直接推論普遍受害範圍、惡意動機或資料竊取。要求改正控制邊界，不需要補上證據尚未支持的罪名。

六、下一步：先留下變更清單，再決定保留哪些整合

若你擔心自己的環境受影響，先保存版本、安裝時間與設定備份，再以宿主的管理介面檢查 Postman 外掛、hooks 與 MCP 項目。Codex 可依上述官方文件開啟 /hooks，審閱來源及目前信任狀態；Claude Code 則先按官方外掛安全與移除說明確認來源、內容和移除範圍。避免把網路留言中的整段清理腳本直接交給日常帳號執行。

私人檢查表可以只留五欄：哪個工具、何時改動、影響哪層設定、誰作了同意、如何撤銷。需要保留 API 測試整合，不表示也要保留它對所有 API 工作的預設指示；不想使用遠端連線，也應能單獨表達這個選擇。不要整份刪除共用設定檔，連其他工具的有效設定一起抹掉。

若你真正要查的是資料有沒有送出，另做 AI Coding Agent 出站資料盤點；若想先理解模型外圍誰管工具與執行，可讀 Agent Harness 的分工。把「有沒有動設定」和「有沒有傳內容」拆開，才會知道下一份證據該去哪裡找。

後續值得追的，是可核對的產品改變：逐宿主的明確選擇、hook 信任是否由宿主中的使用者決定、移除後是否尊重選擇，以及文件是否完整列出設定變更。若要驗證新版，應在已備妥、獲授權的乾淨測試環境，比較安裝前後；一次測例也只替它自己的版本與條件作證。