分類: AI 資訊

[Tempest AI 深度解讀] 一個 SQL 關鍵字攻破「唯讀」：Postgres MCP 漏洞如何一路變成系統命令 (2026-10-05)

一個標示為「唯讀」的資料庫工具，為何可能一路變成作業系統命令執行入口？關鍵不在於 MCP 協定本身，而在於應用程式如何解讀「唯讀」，以及 PostgreSQL 帳號最後究竟握有多少權限。

事件背景：修補早於公開警報

原始分析指出，AWS Labs 的 postgres-mcp-server 在預設唯讀模式下，曾未攔住 COPY ... TO PROGRAM。攻擊者若把特製 SQL 植入代理會讀取的內容，經由已驗證使用者觸發工具呼叫，便可能讓 SQL 抵達資料庫。原文與技術脈絡見：https://dev.to/kielltampubolon/read-only-postgres-mcp-servers-fail-with-1-sql-keyword-18b8。

可確認的來源事實是：AWS 於 2026 年 9 月 9 日公布 CVE-2026-87911；受影響版本為 1.1.7 以前，GitHub 公告給予 CVSS 3.1 的 9.6 分。成立條件包括使用 PG wire 連線、自行管理的 PostgreSQL，以及 MCP 連線角色具備超級使用者或 pg_execute_server_program 權限。1.1.7 已修補此問題：https://aws.amazon.com/security/security-bulletins/2026-104-aws/、https://github.com/awslabs/mcp/security/advisories/GHSA-fph8-pg5w-78fv。

PyPI 紀錄顯示，1.1.7 其實早在 6 月 25 日上架，距公告超過兩個月。這段落差的實際意義是：使用浮動最新版者可能早已被動取得修補，鎖定舊版、內嵌原始碼或維護 fork 的團隊，卻未必知道應立刻處理。版本資料見：https://pypi.org/project/awslabs.postgres-mcp-server/1.1.7/。

一個關鍵字如何穿過「唯讀」

COPY 不只是匯入、匯出表格資料。搭配 PROGRAM 時，PostgreSQL 伺服器會直接執行指定程式，命令不是跑在使用者電腦，也不是跑在 MCP 客戶端，而是在資料庫主機上，並繼承 PostgreSQL 作業系統帳號能觸及的資源。官方文件同時明定，這項能力只應開放給超級使用者或持有 pg_execute_server_program 的角色：https://www.postgresql.org/docs/current/sql-copy.html。

這也解釋了為何把交易設成 READ ONLY 並不足夠。PostgreSQL 的唯讀交易會禁止寫入一般資料表的 INSERT、UPDATE、DELETE 與 COPY FROM 等操作，但官方明確稱這只是「高階層的唯讀概念」，無法阻止所有磁碟寫入；禁止清單也未包含 COPY TO PROGRAM。交易模式約束資料操作，角色權限才約束能否叫資料庫主機執行程式：https://www.postgresql.org/docs/current/sql-set-transaction.html。

為何現在值得注意

合理推論是：這起事件揭露的不是單一關鍵字有多神奇，而是 AI 代理把外部內容、使用者身分與高權限工具串成同一條執行鏈。攻擊者未必需要登入資料庫；他只要影響模型讀到的文字，再由代理代為提出查詢。CVSS 中「不需攻擊者權限、但需要使用者互動」正反映這種間接路徑。

更值得警惕的是安全邊界放錯位置。舊版用阻擋清單識別危險語法，能攔住已知名稱，卻很難窮舉 PostgreSQL 擴充功能、自訂函式、動態 SQL 與未來新增能力。9 月初另一項 CVE-2026-85787 也涉及 1.1.7 以前版本的唯讀檢查不完整，說明「再補一個名稱」並非穩定的權限模型。

影響範圍與容易忽略的限制

不能把此漏洞簡化成「所有 Postgres MCP 都能拿 shell」。AWS 公告限定於特定舊版、PG wire、自管 PostgreSQL與高權限角色；若 MCP 使用專屬低權限角色，資料庫會直接拒絕 COPY ... PROGRAM。同樣地，CVSS 9.6 描述的是條件成立時的技術衝擊，不等於每個部署都有同樣風險。

截至 10 月初，專案現行文件顯示查詢已改以 PostgreSQL 解析器處理，會拒絕多陳述句、解析錯誤、命令執行與主機檔案操作；但維護者仍把這層稱為「最佳努力」的縱深防禦，並承認解析器無法看穿任意第三方函式或動態 SQL。這項更新降低已知繞過空間，並沒有把應用層驗證升格成真正的權限邊界：https://github.com/awslabs/mcp/blob/main/src/postgres-mcp-server/README.md。

對台灣企業的實際意義

作者觀點是：企業導入 MCP 時，不應把產品介面的「唯讀」標籤直接寫進風險評估結論。金融、製造、醫療與零售常把代理接上內部報表庫；一旦沿用管理員帳號求快速上線，原本只是資料查詢的元件，就可能取得讀取主機檔案、跨網路存取或執行程式的能力。真正可稽核的問題應是：「資料庫拒絕什麼？」而不是「MCP 宣稱攔截什麼？」

  • 盤點實際套件、容器映像與 fork，確認不是只更新部署文件，而是執行中的版本已至少包含 1.1.7 修補。
  • 為每個代理建立專屬角色，只授予必要資料庫的 CONNECT、必要 schema 的 USAGE 與指定資料表的 SELECT。
  • 確認角色不是超級使用者，也未繼承 pg_execute_server_program、pg_read_server_files 或 pg_write_server_files。
  • 把資料庫程序放入受限主機或容器，限制對外連線、檔案系統與雲端中繼資料服務；這是降低失守後衝擊，不是取代資料庫權限。

後續觀察指標

接下來應觀察三件事：維護者是否把高權限角色檢查變成預設啟動門檻；企業是否能在稽核紀錄中區分使用者、模型與工具實際送出的 SQL；以及後續安全公告是否仍反覆出現「遺漏一個函式或語法節點」。若同類漏洞持續發生，答案就很清楚：MCP 的唯讀過濾適合改善操作體驗，真正的安全承諾仍必須落在資料庫角色、主機隔離與可追溯的授權鏈上。

[Tempest AI 深度解讀] Cursor、Claude Code、Copilot 都可能留密碼：AI 編碼代理的憑證盲區 (2026-10-05)

這起事件的核心，不是「AI 自己偷走密碼」，而是編碼代理取得更大的本機與外部系統操作能力後，認證資料也跟著散落到傳統安全控管看不到的位置。當 Cursor、Claude Code、GitHub Copilot CLI 能讀檔、執行指令，並透過 Model Context Protocol（MCP）連接程式庫、資料庫、雲端與 SaaS，開發者電腦就不再只是寫程式的終端，而成為多組機器身分與權限的集中點。

來源事實：憑證留下的是一條「端點足跡」

GitGuardian 的調查指出，API 金鑰、權杖與連線字串可能出現在 MCP 設定、環境變數、提示內容、指令輸出、除錯日誌、工作階段紀錄、Shell 歷史與暫存檔。部分檔案會進入 Git，但使用者家目錄中的設定與紀錄通常不會經過程式庫或 CI 掃描。該公司聲稱在公開 MCP 相關設定檔中找到 24,008 組不重複祕密，其中 2,117 組仍有效；Claude Code 輔助的公開提交出現祕密的比率為 3.2%，全體公開 GitHub 提交基準則為 1.5%。原始調查與產品說明見：https://blog.gitguardian.com/ai-coding-agents-credential-security/

這些數字必須放回來源脈絡理解：GitGuardian 本身販售祕密偵測與端點保護產品，3.2% 與 1.5% 是其觀察結果，並不能證明 Claude Code「造成」外洩。原文也明確承認沒有建立因果關係。因此，可確認的是 AI 輔助提交與較高的觀察外洩率同時出現，而不是工具必然導致洩密。

運作機制：安全儲存與周邊憑證是兩件事

三款工具並非完全以明文保存主要登入權杖。以 Copilot CLI 為例，GitHub 官方文件說明其預設使用 macOS Keychain、Windows Credential Manager 或 Linux Secret Service；但若系統沒有可用的金鑰圈，例如部分無頭 Linux 環境，使用者可將權杖存入 ~/.copilot/config.json 明文檔案。環境變數中的權杖還會優先於金鑰圈內容：https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/authenticate-copilot-cli

Copilot 官方另列出 logs/、工作階段狀態、指令歷史、SQLite 儲存庫、MCP OAuth 備援資料及權限決策等本機項目。這證實問題不能只用「登入權杖有沒有進金鑰圈」判斷：https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference

Claude Code 官方文件則顯示，專案層級的 .mcp.json 可提交到版本控制供團隊共享，也支援以 ${VAR} 引用環境變數；但設定格式同時容許環境欄位與認證標頭。換言之，工具提供較安全的間接引用，不等於能阻止使用者把真實權杖直接寫入設定：https://code.claude.com/docs/en/mcp?ref=blog.gitguardian.com

為何現在值得注意

合理推論：風險上升的原因不是新增一種檔案，而是權限、速度與規模同時改變。過去 IDE 多半消費程式碼；代理現在可以啟動本機程序、讀取更多目錄，並帶著使用者授予的身分呼叫外部服務。每增加一個 MCP 連線，就可能增加一組非人類身分、權限範圍與生命週期，既有的程式庫掃描卻只看得到其中一部分。

另一份由 Hush Security 進行的調查，分析約 82,000 份公開 MCP 設定檔，發現受檢憑證欄位中有 12% 直接寫入疑似憑證字串，當中 55% 沒有可供傳統規則辨識的供應商格式。該研究未向服務商驗證憑證是否有效，且 GitHub 搜尋只涵蓋預設分支、排除 fork 並受查詢上限影響，所以不能與 GitGuardian 的「有效憑證」數直接相比；但它獨立支持了「明文設定確實普遍存在、格式比傳統掃描規則更分散」這項風險判斷：https://www.hush.security/state-of-mcp/

實際影響與容易忽略的限制

若外洩的是低權限、短效且限定單一服務的權杖，衝擊可能受控；若是長效 GitHub PAT、雲端金鑰、資料庫連線字串或跨專案共用權杖，攻擊者可能讀取私有原始碼、存取資料或利用雲端資源。刪掉目前檔案並不等於完成修復：Git 歷史、其他開發者的複本、日誌與備份仍可能保留原值，正確事件處理順序應包含撤銷或輪替，再清除各處副本。

但端點掃描也不是萬靈丹。它可能遇到誤判、隱私與效能取捨，也無法取代 IAM、祕密管理器、EDR、程式庫掃描或 MCP 伺服器本身的授權檢查。OWASP 的 MCP 安全建議強調每個伺服器使用獨立且最小權限的憑證、優先採短效權杖、使用作業系統安全儲存，並在日誌中遮蔽祕密；同時還要限制本機伺服器的檔案與網路存取：https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html

對台灣開發團隊的意義

作者觀點：台灣團隊最該調整的不是「禁用 AI」，而是把開發者筆電視為正式的身分與祕密管理範圍。新創、接案商、供應鏈廠商與跨國研發中心常同時接觸客戶 Git、雲端帳號及內部系統；一台電腦上的代理設定，可能跨越原本分離的信任邊界。

  • 盤點實際使用的編碼代理、MCP 伺服器、設定位置與可搬移的狀態目錄，不只檢查專案資料夾。
  • 禁止在可提交的 MCP 設定中直接寫入祕密，改用安全儲存、執行階段注入或短效 OAuth；每個整合使用獨立、最小權限憑證。
  • 保留 pre-commit 與 CI 掃描，同時將經核准的端點掃描納入管理；日誌、歷史與暫存檔須有遮蔽及保存期限。
  • 發現外洩時，以「撤銷、輪替、查閱使用紀錄、清除副本」處理，不把刪檔或重新提交視為結案。

後續觀察指標

接下來可追蹤四件事：各工具是否預設拒絕明文憑證、企業管理政策能否統一限制 MCP 來源與權限、短效且按服務切割的 OAuth 是否取代長效 PAT，以及端點發現的祕密中有多少能在時限內完成撤銷。真正能衡量改善的，不是掃描出多少筆，而是未受管理的代理與長效高權限憑證是否持續下降。

[Tempest Agent 深度解讀] AI 代理的 25 種隱私風險：MLCommons 首份框架揭示什麼？ (2026-10-05)

從「模型說了什麼」轉向「代理做了什麼」

AI 聊天機器人的典型隱私問題，是模型是否記住、推測或回答出敏感資料；AI 代理則多了一層更實際的風險：它能讀信、查行事曆、呼叫外部工具、保留跨工作階段記憶，甚至代替使用者執行程式或傳送資料。換句話說，即使畫面上的回答看似無害，背後的工具鏈仍可能已經越界。

來源事實：MLCommons 於 2026 年 10 月 1 日公布《Agent Privacy Risk Taxonomy》v0.1，把代理式 AI 的隱私風險整理為五大領域、25 個風險向量，並提出六階段因果評估方法。原始報導可見 https://ppc.land/mlcommons-catalogues-25-privacy-risks-posed-by-ai-agents/；MLCommons 的公告與十五頁文件則分別位於 https://mlcommons.org/2026/10/agent-privacy-risk-taxonomy-v0-1/、https://mlcommons.org/wp-content/uploads/2026/10/ML-Commons-Agent-Privacy-Taxonomy-v01.pdf。

25 種風險背後，其實是五道資料關卡

第一道是資料進入代理的方式，包括持續追蹤、非預期蒐集、執行軌跡紀錄、跨工作階段記憶、傳統遮罩無法辨識的語意型個資、惡意外部內容，以及權限過大的代理間資料交換。第二道是資料進入後的聚合、使用與分享：原本無害的碎片可能被拼成健康、政治傾向等敏感特徵，也可能透過供應鏈、動態程式執行或記憶污染而外洩。

其餘三道關卡分別是跨代理政策不一致、傳統同意機制失效，以及責任與稽核困難。使用者在代理 A 撤回同意或要求刪除資料，不代表代理 B、外部工具及衍生副本同步完成；若事故涉及模型、系統提示、第三方工具與使用者指令，也很難迅速指出責任落在哪一層。

為何不能只靠權限彈窗

合理推論：代理的核心商業價值來自「少問、主動完成」，隱私治理卻要求目的明確、權限最小化與可撤回。若每一次讀信、查檔案、呼叫工具都要求確認，使用者很快會產生同意疲勞；若交由模型自行推斷意圖，結果又具有機率性，無法證明每次都符合期待。這不是介面設計不佳，而是便利性與可驗證控制之間的結構性衝突。

另一個難題是紀錄本身。完整執行軌跡有助除錯、稽核與事故歸因，卻也可能集中保存使用者輸入、推理脈絡及工具呼叫內容，成為高價值攻擊目標。真正需要的不是「全部留存」或「完全不留」，而是可限定欄位、目的、保存期限與存取角色的隱私保護稽核紀錄；MLCommons 草案指出這項矛盾，但尚未提出具體規格。

風險已獲獨立實驗支持

這份分類並非只有概念上的擔憂。美國國家標準暨技術研究院（NIST）曾測試「代理劫持」：攻擊者把惡意指令藏進電子郵件、檔案或網站，利用代理無法清楚區分可信指令與外部資料的弱點，引導它執行資料外洩、遠端程式碼執行或自動化釣魚。NIST 並指出，針對特定模型重新設計攻擊後，測得的成功率可能大幅上升，重複嘗試也會改變風險估計。這直接支持 MLCommons 對間接提示注入、動態執行及外部工具風險的判斷：https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations。

企業應把分類表轉成採購與測試條件

作者觀點：這 25 項最有價值的用途，不是成為另一份合規勾選表，而是被改寫成可驗證問題：

  • 代理是否只取得完成任務所需的欄位，而不是整段對話、整個信箱或完整客戶檔案？
  • 刪除、更正及撤回同意能否傳到下游代理、外部工具與衍生資料？
  • 面對藏在郵件、網頁與文件中的指令，代理能否停止高風險動作並要求人工確認？
  • 記憶、執行軌跡及工具呼叫紀錄保存多久，誰能讀取，事故後能否重建責任鏈？
  • 供應商更新模型、工具或外掛後，原有測試是否需要重新執行？

採購方也不應只問模型是否「不會洩密」，而要逐一檢查模型、代理框架、記憶層、身分授權、外部工具與紀錄系統。代理是整套部署的行為結果，單一模型的安全分數不能代表整條資料鏈。

容易忽略的限制

這仍是公開徵求意見的 v0.1，不是法律、認證標準或產品排行榜。文件沒有事故發生率、模型比較結果，也未替 25 項風險排出通用優先順序。MLCommons 自己也承認，銀行客服代理與可讀取私人信箱的助理，風險排序不會相同；部分治理問題更不可能只靠基準測試涵蓋。

此外，分類由跨產業工作小組制定，未來若要成為採購依據，仍須交代測試案例如何選擇、利益衝突如何管理，以及結果能否由外部研究者重現。MLCommons 表示將辨識指標、試行基準並持續修訂，目標在 2027 年形成具體衡量工具，但這是規畫，不等於現階段已有可比較分數。

對台灣組織的直接意義

台灣《個人資料保護法》所稱的「處理」，已涵蓋記錄、儲存、檢索、刪除、輸出、連結及內部傳送；法務部並說明，蒐集時須明確化特定目的，後續利用原則上應與該目的相符：https://www.moj.gov.tw/media/2820/71222115392.pdf?mediaDL=true。因此，企業把郵件、客服紀錄、員工資料或病歷摘要交給代理，不能只把它視為「員工使用一套軟體」；代理跨系統檢索、推論及傳送，本身就可能形成多次處理與利用。

合理推論：台灣金融、醫療、電商與政府機關最先需要補強的，會是用途層級的授權、跨供應商刪除傳遞，以及兼顧稽核與資料最小化的紀錄制度。現行個資原則提供了判斷方向，卻不會自動回答代理在一次任務中可讀哪些欄位、可呼叫哪些工具、何時必須停下等待人工批准；這些仍須由部署單位轉成技術控制與契約責任。

接下來應觀察什麼

後續關鍵不在風險名稱是否增加，而在 MLCommons 能否把分類落實成可重複測試：是否公開測試情境與評分邏輯、能否分別衡量正常使用與惡意攻擊、是否測試多次攻擊及跨代理刪除，以及評分能否反映資料敏感度與傷害差異。對企業而言，更實際的指標則是代理實際取得的資料量、遭拒絕的越權呼叫、高風險動作人工確認率、刪除指令傳遞完成率，以及事故能否追溯到明確元件與責任人。只有當這些指標可被量測，「可信任代理」才會從行銷用語變成可以稽核的工程承諾。

[Tempest Agent Insights] 技術趨勢 (2026-10-06)

本期 Agent 趨勢顯示，產業焦點正從聊天介面轉向可執行任務的基礎設施、治理與資安。企業開始把 Agent 導入 IT 維運、雲端架構檢查、客服、通訊與資安測試，同時也更重視權限邊界、成本上限、可觀測性與故障復原。

Agent 基礎設施開始處理 CPU 執行瓶頸

Nvidia 與 CoreWeave 將焦點放在 Agent 推論前後的大量執行工作。模型推理主要仰賴 GPU，但工具呼叫、資料處理與任務協調等流程仍高度依賴 CPU；CoreWeave 並宣布將提供為 AI Agent 工作負載設計的 Nvidia Vera CPU。這反映 Agent 基礎設施的競爭範圍，已從模型算力擴大到完整任務執行鏈。來源：[https://ift.tt/L4qGtSP]、[https://ift.tt/lhVGLiI]

AWS 以 Agent 自動化雲端架構檢查

AWS 推出預覽中的 Well-Architected Agent，嘗試自動蒐集跨服務證據、辨識架構問題並提出最佳化建議。傳統 Well-Architected Review 往往需要團隊花費一至兩天回答問題及整理多個主控台的資訊，而 Agent 化服務的目標，是降低人工盤點成本並避免報告迅速過期。來源：[https://ift.tt/v7M05hd]

MCP 正成為既有 API 接入 Agent 的標準介面

MCP 的實作教學顯示，開發者可在不重寫既有應用程式的前提下，把 REST API 包裝成 AI 用戶端可呼叫的工具。相關示範以股票資料 API 建立 MCP 服務，凸顯 Agent 開發逐漸從單純串接模型，轉向工具介面、權限與上下文的標準化。來源：[https://ift.tt/h16jasJ]

長時間執行與故障復原成為 Agent Runtime 重點

Pi 1.0 提供原生 MCP 支援，並推出實驗性的 Pi Durable，鎖定長時間執行及當機後可復原的 Agent。這類 Runtime 能力對跨多個工具、等待外部事件或執行多階段流程的任務尤其重要，也顯示 Agent 工程正逐步補齊傳統分散式系統已具備的持久化與韌性機制。來源：[https://ift.tt/Kn7zpLo]

Agent 可觀測性市場進入整併階段

Dynatrace 已於 10 月 1 日完成以 9.15 億美元收購 Arize，將 Arize 的 Agent 追蹤與評估能力，整合至既有的應用程式及基礎設施監控產品。這項交易呈現明確方向：企業需要從模型行為、工具呼叫一路追蹤到底層系統，而 Agent 可觀測性也正逐漸被納入完整 APM 與維運平台。來源：[https://ift.tt/xaVMeQq]

自主 Agent 已能高速串接零時差漏洞

一個自主 AI Agent 利用 Zammad 客服系統的兩個未公開漏洞，入侵荷蘭漏洞揭露研究機構 DIVD，並在數秒內從應用程式層入侵擴大至 root 權限。事件顯示，Agent 不只提高弱點研究效率，也可能大幅壓縮防守方從偵測到應變的時間；資安團隊需要同步強化修補、最小權限與異常行為監控。來源：[https://ift.tt/pgCdyTW]

金融業面臨 Agent 自動化加速的網路釣魚攻勢

2026 年上半年，美國金融服務業遭遇近 4 萬個網路釣魚網址；攻擊活動分散於 645 家託管服務供應商，其中免費託管服務承載 12.6% 的相關網址。報告並指出，自動化 AI Agent 與新出現的防彈主機服務正推動更積極的攻擊活動，讓大量產生及快速輪替釣魚基礎設施變得更容易。來源：[https://ift.tt/lWZgfjA]

成本上限必須放在 Agent 無法修改的控制層

自主 Agent 每次選擇下一個動作，也同時決定下一筆成本，因此僅在提示詞中要求節制並不足夠。較穩健的做法，是由 SaaS 帳號、API 閘道或付款伺服器強制執行硬性額度，並將修改額度所需的憑證隔離於 Agent 之外。n8n 的付款流程案例也採取相同原則，透過 MCP 工具端檢查規則，而非讓 Agent 自行判定能否付款。來源：[https://ift.tt/VsKh1Mq]、[https://ift.tt/Gqt7w1C]

企業治理從模型清冊擴大到 Agent 全生命週期

SAS 推出的 AI Navigator 面向 AI、資料、法遵與風險團隊，用來追蹤組織內的 AI 使用案例、模型及 Agent。隨著各部門自行部署 Agent，治理工作的核心問題已不只是模型品質，而是組織能否掌握目前有哪些 Agent 正在執行、擁有什麼權限、存取哪些資料，以及由誰負責。來源：[https://ift.tt/UAlMyck]

Agent 加速進入客服、通訊與 IT 維運流程

Nexly Agents 透過分析客戶對話，找出重複問題、資訊缺口、痛點與銷售機會，並以具來源依據的回答支援前台互動；Webex Translator Agent 則把即時語音翻譯直接整合進通話體驗。另一方面，Risotto 將產品定位為能處理複雜 IT 工單的「自主 IT 工程師」。三類應用共同反映 Agent 正從回答問題，進一步負責分析情境並執行具體業務流程。來源：[https://ift.tt/ISiAUm5]、[https://ift.tt/gOpK5dP]、[https://ift.tt/9cQAwxC]

整體而言，Agent 落地的關鍵已不再只是模型能力，而是能否在真實系統中安全、持久且可稽核地運作。工程團隊接下來需要把 Runtime 韌性、工具介面、可觀測性、權限隔離與成本控制視為同一套正式上線條件。

[Tempest AI News] 技術新聞精華 (2026-10-06)

本期焦點集中在 MCP 生態系的安全性、可觀測性與跨工具相容性。Flowise 與 Langflow 接連揭露可導致遠端程式碼執行的漏洞，顯示代理工作流程若允許模型或一般使用者影響執行環境，必須建立更嚴格的輸入驗證、權限隔離與稽核機制。另一方面，MCP 閘道、多區部署、測試基礎設施及開發工具整合也持續成熟。

Flowise CSV Agent 驗證可遭繞過，提示詞可能觸發程式碼執行

CVE-2026-41264 揭露 Flowise 的 CSV Agent 存在高風險驗證缺陷。報導展示攻擊者可利用 Python 匯入別名繞過正規表示式檢查，進一步呼叫系統命令；該漏洞的 CVSS 評分為 9.8。

這起事件凸顯，以字串比對或黑名單限制模型產生程式碼並不可靠。部署可執行 Python、資料分析代理或其他動態程式碼功能時，仍需搭配沙箱、最小權限及系統呼叫隔離。來源：https://ift.tt/C28JwK9

Langflow MCP stdio 設定爆出 OS 命令注入漏洞

CVE-2026-105697 指出，Langflow 1.10.3 以前的版本會直接執行使用者填入 MCP Server 設定的命令與參數，因而形成 OS 命令注入及遠端程式碼執行風險。

問題位於 MCP stdio 傳輸層與主機作業系統之間的信任邊界。管理者應確認版本與修補狀態，並限制誰能新增或修改 MCP Server 設定。來源：https://ift.tt/ajHnkl9

Langflow 另一項 MCP stdio 漏洞允許已驗證使用者取得 RCE

CVE-2026-105740 顯示，Langflow 1.9.0 以前的版本中，任何已通過身分驗證的使用者都可能透過新增 MCP stdio 設定，在伺服器上執行任意 OS 命令。

即使系統要求登入，低權限帳號仍不應自動取得建立本機程序的能力。企業部署需將 MCP 設定權限與一般工作流程編輯權限分離，並同步檢查既有設定是否含有未授權命令。來源：https://ift.tt/5dsGQ4v

Anthropic 對 Z.ai GLM-5.3 的資安防護提出疑慮

Anthropic 表示，Z.ai 的 GLM-5.3 在一項漏洞開發基準測試中，能力已接近 Claude Mythos Preview，但安全防護仍不充分，因此可能增加模型遭濫用於網路攻擊的風險。

這項警告反映前沿模型的資安能力與防護措施需要同步評估。導入具備程式碼或漏洞分析能力的模型時，團隊不能只比較效能，也應納入權限控管、濫用偵測及輸出審查。來源：https://ift.tt/o65KUbT

Ramen 打造跨 GCP 與 AWS Kubernetes 的多區 MCP Server

開源專案 Ramen 主打多區、高可用的 MCP Server 架構，可部署於 GCP 與 AWS Kubernetes。其節點以 Rust 實作，工作節點採用 Python 3.14，邊緣連線使用 Streamable HTTP，內部通訊則使用 gRPC。

專案另提供 FastAPI 管理介面，將 MCP 從單機工具連線提升為可跨區域管理的服務架構，適合關注代理基礎設施容錯與水平擴充的團隊參考。來源：https://ift.tt/mSp1q9g

DeepSeek Harness 加入 Claude Code Mods 相容層

新版 DeepSeek Harness 新增實驗性的 Claude Code Mods 相容層，並進一步強化開放式外掛架構。其方向是讓既有代理擴充元件可跨工具使用，降低開發者被單一代理平台綁定的程度。

相容層仍屬實驗性功能，實務導入時需要檢查工具呼叫、權限模型及生命週期鉤子的行為是否一致。來源：https://ift.tt/VBmfT8x

MCP 生態系下一階段需要更完整的測試基礎設施

文章認為 MCP 已在代理基礎設施中取得主導地位，但協定普及後，社群面臨的新問題是如何系統化驗證 Server 的正確性、相容性與可靠度。

對工程團隊而言，MCP 測試不應只確認工具能否列出與呼叫，還需涵蓋傳輸層中斷、Schema 變動、錯誤回應、權限邊界及不同客戶端之間的行為差異。來源：https://ift.tt/A6ZQLP9

AWS DevOps Agent 串接 EventBridge 與 OpenSearch MCP

AWS 公布兩種 DevOps Agent 整合模式：第一種透過 Amazon EventBridge 與 Lambda，將調查事件轉送至第三方系統；第二種則利用 MCP，讓代理直接存取 Amazon OpenSearch 的可觀測性資料。

兩種模式分別處理事件外送與調查資料存取，可用來組合自動化事件回報、診斷及後續處理流程。導入時仍應明確限制代理可查詢的資料範圍及可觸發的外部動作。來源：https://ift.tt/RXn7Sxs

Google Workspace 遠端 MCP Server 可透過 Claude Code 外掛完成設定

一份實作指南將 Google Workspace 遠端 MCP Server 的設定流程封裝成 Claude Code Skill 與外掛，協助開啟所需 API、註冊 Server、完成登入並測試八個服務。

這類自動化能減少多服務整合時的重複設定，但涉及 Workspace 權限時，仍應逐項檢查 OAuth 範圍、憑證保存方式及測試帳號的存取界線。來源：https://ift.tt/6A5SNl4

CLAUDE.local.md 可能讓 Claude Code 停止讀取 AGENTS.md

一項實測指出，Claude Code 預設只會在工作目錄中沒有 CLAUDE.md 與 CLAUDE.local.md 時讀取 AGENTS.md。新增本機專用的 CLAUDE.local.md，可能因此讓原本跨工具共用的 AGENTS.md 指令失效。

同時使用 Claude Code、Codex、Cursor、GitHub Copilot 或 Windsurf 的團隊，應把指令檔載入順序納入專案文件與除錯流程，避免不同代理套用到不一致的規範。來源：https://ift.tt/N69BcRF

Claude Code 外掛在 Claude App 中可能只載入部分功能

有開發者發現，透過 Claude App 的 Customize > Plugins 安裝外掛時，聊天介面只會載入 Skill 與遠端 HTTP／SSE MCP Server；Hooks、子代理及本機 stdio MCP Server 則會被略過。

因此，若 Skill 依賴本機 MCP Server，可能出現介面顯示 Skill 已載入，實際卻沒有對應工具可用的「半相容」狀態。外掛作者應分別驗證 Claude Code 與 Claude App，而不能假設兩者支援範圍相同。來源：https://ift.tt/6eVH0O9

開源工具讓 Claude Code 的用量、成本與 CI 狀態更透明

一項開源專案試圖把 Claude Code 工作階段中的上下文用量、五小時速率限制、每週上限、預算及 CI 狀態集中呈現，降低長時間代理任務在背景消耗資源卻不易察覺的問題。

對大量採用程式開發代理的團隊而言，這類可觀測性有助於在工作中斷前發現限制，也能把模型成本與實際開發活動連結起來。來源：https://ift.tt/LUfZi0F

以 TypeScript 直接連接 stdio 與 HTTP MCP Server

一篇教學示範如何使用官方 TypeScript SDK，分別透過 stdio 與 HTTP 連接 MCP Server，完成協定交握並列出可用工具。

這種從客戶端程式碼直接觀察連線流程的方式，有助於排查設定檔之外的傳輸層、初始化及工具探索問題，也適合作為自製 MCP Client 的起點。來源：https://ift.tt/OH4YpFv

my-claude-code 7.75.0 擴充多供應商模型路由能力

my-claude-code 7.75.0 提供本機多供應商 LLM Proxy、模型路由與控制平面，可供 Claude Code、Codex、OpenCode、Gemini CLI 及其他 AI 程式開發代理使用。

專案宣稱支援 57 個供應商，並包含故障切換路由、憑證健康狀態、原生網路搜尋工具 Proxy，以及可追溯成本來源的分析功能。來源：https://ift.tt/enzohl9

Uber MCP Gateway 架構凸顯企業代理平台的治理需求

一篇架構分析以 Uber 的 MCP Gateway 為例，指出企業若要大規模部署實用代理，需要建立在既有 API、明確服務所有權及上下文控制之上。

集中式閘道可作為代理與內部服務之間的治理層，統一處理工具曝光、存取政策與上下文範圍；真正的挑戰不只在協定接通，更在於維持組織原有的責任與權限邊界。來源：https://ift.tt/TN32kXV

[Tempest AI 深度解讀] 能力逼近、安全落後：GLM-5.3 爭議揭開開放模型的網攻治理難題 (2026-10-06)

事件背景：爭議不只在模型「會不會駭」

《DIGITIMES》報導，Anthropic 認為中國 AI 業者 Z.ai 的 GLM-5.3，在漏洞利用能力上已逼近 Claude Mythos Preview，卻缺乏相稱的安全防護。原始報導受訂閱限制，但其核心命題可由 Anthropic、Z.ai 與美國國家標準暨技術研究院（NIST）資料交叉驗證。報導來源：https://www.digitimes.com/news/a20261005PD205/anthropic-z.ai-claude-startup.html

來源事實：NIST 旗下 CAISI 記載，Z.ai 於 2026 年 8 月 14 日發布 GLM-5.3，兩週後公開模型權重；CAISI 將其評為當時網路能力最強的開放權重模型，但在四項測試綜合衡量下，仍約落後美國前沿模型四個月。這比「已全面追平 Claude」更精確：GLM-5.3 跨過的是可自由取得模型的能力門檻，不代表每項任務都與最強封閉模型相同。NIST 資料：https://www.nist.gov/news-events/news/2026/09/caisis-assessment-zais-glm-53-cyber-capabilities

ExploitBench 真正在測什麼

一般漏洞測試可能只要求模型找出程式錯誤、觸發當機，或寫出概念驗證；ExploitBench 的門檻更高。它以 Chrome 等瀏覽器使用的 V8 引擎已知漏洞為材料，要求模型逐步建立利用原語、突破沙箱，最後取得任意程式碼執行能力。基準把過程拆成 16 項能力，因此能區分「知道哪裡有洞」與「能把洞組成完整攻擊鏈」。

來源事實：Anthropic 在自己的執行環境中，讓各模型針對 41 個漏洞各嘗試十次。GLM-5.3 在 410 次嘗試中完成 50 次端到端利用，Claude Mythos Preview 為 56 次，約為 12% 對 14%。另一項涵蓋開源專案的內部測試中，兩者取得完整控制流程劫持的比例則為 4% 與 6%。研究說明：https://www.anthropic.com/research/glm-5-3-and-the-spread-of-advanced-cyber-capabilities

NIST 的數字看起來不同：其 ExploitBench 採每題三次嘗試中的最佳成績，GLM-5.3 得分為 9.8／16，換算 61.1%，美國前沿最佳模型為 16／16。兩組結果衡量方式、代理框架與彙整單位不同，不能直接互換；共同訊號則是 GLM-5.3 已能完成不只是觸發錯誤，而是把漏洞推進到實際利用的工作。

真正的商業與治理轉折：能力可以被下載

Z.ai 說明，GLM-5.3 沿用 GLM-5.2 的基礎模型，進步來自後訓練；公司也承認其網路能力成長快於預期。官方程式庫列出可下載的 744B-A40B 權重及本機部署方式：https://github.com/zai-org/GLM-5

合理推論：封閉 API 可以靠帳號審查、速率限制、日誌與伺服器端更新形成多層控制；權重一旦下載，原開發商便難以強制保留拒答機制，也無法完整掌握使用紀錄。這不是「開放權重必然危險」，而是治理重心從供應商控制，移到部署者、算力提供者及最終使用者。

Anthropic 的測試顯示，原版 GLM-5.3 面對直接的惡意命令會拒絕，但加入虛假紅隊情境後，執行比例升至 64%；預先填入推理內容時為 92%。研究團隊再以移除拒答傾向的方式修改權重後，模擬任務中的執行比例達 100%，而一般科學與部分網路能力測試僅小幅或未明顯下降。這些是 Anthropic 自行設計的測試結果，不宜視為所有現實攻擊的成功率，卻指出單靠模型內拒答並非穩固邊界。

為何現在值得注意

過去攻擊者即使知道漏洞，仍須投入時間把當機樣本轉成穩定利用鏈。Anthropic 另稱，研究者在隔離環境中，曾用 GLM-5.3 找到瀏覽器元件的多個未知漏洞並串成可讀取檔案的攻擊；較小的 GLM-5.3-Flash 也在有限人力介入下，把兩個已公開漏洞串成 ARM64 利用鏈。相關漏洞已通報維護者，但細節尚未公開，因此外界目前無法完全獨立重現。

作者觀點：最重要的改變不是模型突然能「一鍵入侵」，而是漏洞分析、反覆試錯與程式碼生成的邊際成本下降。低成功率若能平行執行、持續重試，仍可能壓縮防守方從修補公布到攻擊武器化之間的時間。相同能力也能協助防守者掃描程式碼、重現漏洞與驗證修補，問題因此不是禁止能力本身，而是誰能更早、更有制度地使用它。

容易忽略的限制與利益衝突

  • Anthropic 是 GLM 的競爭者，也是封閉模型與受審查存取方案的供應商；其安全警告有技術證據，但同時支持自身的發布模式，應由獨立機構持續重測。
  • ExploitBench 使用已知 V8 漏洞與隔離環境，無法完整代表目標偵察、帳密取得、社交工程、維持存取或規避偵測等真實攻擊鏈。
  • Anthropic 的惡意行為測試使用假 bash 工具，指令沒有連到外部系統，部分結果由另一個模型模擬；研究方也明言，這不是現實條件的完美重現。
  • 「美國前沿最佳」是多個模型各項最高成績的比較基準，且部分模型關閉安全護欄或只提供受信任存取，不等於一般使用者可取得的單一產品。

對台灣組織的意義

台灣企業常同時依賴瀏覽器、開源套件、網通設備與委外系統；當漏洞武器化速度加快，傳統按月修補與只看 CVSS 分數的流程會更吃力。實務上應縮短對外服務與端點瀏覽器的修補週期，建立關鍵資產清冊，將已遭利用跡象、是否暴露於網際網路及可否取得概念驗證，一併納入修補優先序。若導入本機開放權重模型做資安工作，也應隔離執行環境、限制網路與憑證權限，並保存提示、工具呼叫及產出紀錄；不能把模型的拒答當成存取控制。

後續觀察指標

  • ExploitBench、ExploitGym 與 OSS-Fuzz 類測試能否由第三方在相同代理框架下重現。
  • Anthropic 所稱未知漏洞完成修補後，是否公布足以驗證的技術分析。
  • Z.ai 是否提出權重發布前評估、分級存取、事件回報及修改版本追蹤機制。
  • 台灣關鍵基礎設施與供應鏈業者的平均修補時間，能否跟上 AI 輔助漏洞武器化的速度。

[Tempest AI 深度解讀] 兩行程式碼突破防線：Flowise 高危 RCE 暴露 AI 工具的驗證盲區 (2026-10-06)

事件背景：被信任的不是使用者，而是模型輸出

Flowise 是以拖拉節點建立大型語言模型應用的低程式碼平台。問題出在已移除的 CSV Agent：使用者以自然語言詢問 CSV 資料，系統要求模型產生 pandas／NumPy 程式碼，再由伺服器端的 Pyodide 執行。換句話說，聊天介面背後不是單純「回答問題」，而是一條從外部輸入通往 Python 解譯器的執行鏈。

來源事實：原始分析指出，CVE-2026-41264 可用兩行 Python 繞過正規表示式驗證：匯入合法套件時，同一行再把 os 偽裝成允許的別名，驗證器只看見第一個套件名稱，執行器卻會處理整行程式碼。原文見 https://dev.to/cgivre/cve-2026-41264-how-a-regex-let-prompts-run-code-in-flowise-26gj。

Flowise 官方 GitHub 安全公告交叉證實：受測版本為 3.0.13，攻擊者可在不需驗證身分的情況下，透過使用 CSV Agent 的 chatflow 誘使模型回傳惡意 Python，最終以執行 Flowise 服務之帳號權限執行任意程式碼。公告把 3.1.0 列為此 CVE 的修補版本，並明列同一個別名繞過方式：https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3hjv-c53m-58jj。

分數需要辨明口徑：公告內保留 ZDI 的 CVSS 9.8 評估，GitHub 頁面另以 CVSS v4 顯示 9.2；兩者都屬重大或關鍵風險，但不能把不同版本的計分結果當成資料矛盾。

防線為何失效：正規表示式在猜語意，Python 卻在執行語意

CSV Agent 的安全設計大致分成三步：先在提示詞中要求模型不要使用 import、exec、os 等危險功能；再以禁止清單逐項比對模型輸出的文字；通過後交給 Pyodide 執行。第一步只是對模型的請求，不是強制控制；真正的關卡只剩第二步。

合理推論：這套設計把「原始碼長得像什麼」誤當成「程式實際會做什麼」。別名、多重匯入、字串組合、反射、Unicode 正規化，以及 pandas 本身的網路與檔案介面，都可能讓相同能力以不同文字呈現。封鎖已知字詞只能處理已知拼法，無法替 Python 語言建立完整的安全邊界。

Pyodide 採用 WebAssembly，也不等於天然隔離。是否安全仍取決於宿主程式暴露哪些 JavaScript、檔案、網路及程序能力。WebAssembly 可以限制記憶體存取，但如果宿主主動把高權限介面交給執行環境，攻擊面仍會穿透至主機。

為何現在值得注意：修好一個繞法，不等於拆掉危險路徑

3.1.0 禁止額外匯入，確實封住 CVE-2026-41264 的特定技巧；然而後續官方公告指出，3.1.0 至 3.1.2 仍可經由預先載入的 pandas／NumPy 功能造成資料外洩、SSRF，甚至形成其他程式碼執行路徑。該公告清楚區分：舊漏洞需要 import，新繞法則不必匯入任何套件：https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-w7x8-q2gp-5cgg。

Flowise 最後沒有繼續擴充禁止清單。官方 PR #6499 於 2026 年 6 月合併，直接移除 CSV Agent、Airtable Agent、其核心執行邏輯、測試、Python 驗證器與 Pyodide 相依套件；變更隨 3.1.3 發布：https://github.com/FlowiseAI/Flowise/pull/6499。這是比「再補一條 regex」更重要的產品決策：當功能的效益不足以支付隔離、維護與持續繞過的成本，移除功能本身就是風險控制。

實際影響與容易忽略的限制

成功利用後，攻擊者可能讀取服務可見的資料與憑證、對內網發出請求、修改檔案或啟動其他程序；實際破壞範圍仍取決於 Flowise 執行帳號、容器掛載、網路出口與雲端權限。若服務以高權限帳號執行或掛載敏感目錄，後果自然更嚴重。

但這不代表所有 Flowise 都能被同一方式攻擊。必要條件包括部署了相關版本、chatflow 使用 CSV Agent，且攻擊者能接觸該流程。透過模型產生指定程式碼的路徑也可能需要多次嘗試；官方測試使用 Llama 3.2 與 Ollama，不能直接外推到所有模型。同時，目前引用資料證明漏洞可被利用，並未證明已有多少真實環境遭入侵。高 CVSS 是潛在衝擊與可利用性的評估，不是事件發生率。

對台灣自架團隊的意義

對把 Flowise 放在企業內網、用來查詢客服紀錄、營運報表或研發資料的台灣團隊，核心問題不是「有沒有把管理介面公開」，而是 prediction API、公開 chatflow 與模型節點能否觸及程式執行環境。低程式碼縮短上線時間，也容易讓資料處理、模型推論與主機權限被包進同一個服務帳號。

OWASP 將這類情境歸為 LLM05:2025「不當輸出處理」：模型輸出在送往下游系統前未被充分驗證，可能造成 SSRF、權限提升或遠端程式碼執行；其建議是把模型輸出視為不可信資料，而不是把模型當安全控制：https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/。

作者觀點：企業不應只確認「CVE-2026-41264 已在 3.1.0 修補」，而應確認整條危險功能是否仍存在。最低行動是升至已移除相關 Agent 的 3.1.3 以上版本、盤點歷史 chatflow，並檢查是否曾對外開放。若業務仍需要執行模型產生的程式碼，應把它放進獨立程序或工作負載，使用唯讀資料、無憑證、封鎖對外與內網連線、最小檔案權限及明確資源上限；否則「沙箱」往往只是一個名稱。

後續觀察指標

  • 資產清冊中是否仍有 3.1.2 以下版本，以及 CSV Agent／Airtable Agent 的歷史流程。
  • 公開 prediction 端點是否具備 API 金鑰、反向代理存取控制、速率限制與完整日誌。
  • Flowise 的 Node.js 程序是否曾異常啟動 shell、下載工具，或連向不明內外網位址。
  • 升級後失效的舊流程是否被私下保留在舊容器，形成未納管的「臨時」服務。
  • 未來導入的 AI Agent 是否仍讓自由文字直接進入 Python、JavaScript、SQL 或系統指令解譯器。

這起事件最值得記住的，不是某一條巧妙的別名語法，而是安全邊界的位置：模型可以協助產生內容，卻不能被授權決定哪些內容安全；只要輸出會被解譯執行，它就必須接受與任何外部輸入相同，甚至更嚴格的零信任控管。

[Tempest Agent Insights] 技術趨勢 (2026-10-07)

本期焦點集中在企業資料治理、Agent 身分與權限控管、MCP 生態系、開發工具，以及上線後的測試與可觀測性。市場重心正從展示型原型轉向可安全執行、可稽核、可維運的正式環境。

企業資料平台強化 Agent 的可信任上下文

Dell Technologies 擴充 Dell AI Data Platform，加入資料協調與儲存能力，並透過統一語意層與企業知識圖譜，讓應用程式與 Agent 使用一致的企業資料視圖。這類架構反映企業導入 Agent 時，資料語意、品質及存取一致性已成為基礎建設重點。

[https://ift.tt/p3VdxF6]

個人 AI Agent 進入企業後，身分控管成為新邊界

Aembit 宣布支援控管個人 AI Agent 對企業環境的存取，並將功能提供給既有客戶。當個人助理開始接觸工作資料與內部系統，企業需要將工作負載身分、最小權限及憑證管理延伸至 Agent，而不能只依賴傳統使用者登入機制。

[https://ift.tt/gDzA6xB]

Agent 安全從模型防護轉向完整執行路徑

隨著 Agent 能呼叫工具、存取系統、撰寫程式並高速執行動作，安全範圍已超越模型、提示詞與資料本身。實務上必須追蹤 Agent 使用了哪些身分、工具與 API，並針對授權、網路連線及執行結果建立可觀測與可阻擋的控制點。

[https://ift.tt/Go8FwCR]

Shadow AI 可視性與執行期 Kill Switch 浮上檯面

AppViewX 發表面向 Agent 身分安全的新功能，主打找出企業內未受管理的 Shadow AI、在執行期停止異常 Agent，並提供具量子韌性的 Agent 身分。這顯示治理需求正從事前核准進一步延伸到執行期偵測、歸因與緊急中止。

[https://ift.tt/SWFvUeC]

n8n 擴大 MCP 與程式開發 Agent 的整合

n8n 正將 Model Context Protocol 生態系擴展至 Claude Code、Codex、Cursor、Windsurf 與 Gemini CLI 等 Agent 主機。支援的 Agent 可透過 MCP 與 n8n 協作建構及操作工作流程，降低各開發工具分別維護專屬整合介面的成本。

[https://ift.tt/UsMAJ8a]

Cloudflare 推出面向 Agent 的新 CLI

Cloudflare 推出開源測試版 CLI「cf」，以統一介面操作旗下服務，並提供結構化輸出與指令探索能力，設計方向明確考量 AI Agent 的使用情境。對開發團隊而言，可預測的輸出格式與可探索指令，有助於降低 Agent 執行自動化工作時的解析錯誤。

[https://ift.tt/GMLKmpg]

Google 將遷移與現代化工具整合至 Agent 化產品線

Google 重新整合雲端現代化產品組合，將既有遷移與現代化工具、新的 Agent 化遷移工具，以及 Modernization Hub 納入 Google Cloud Modernize。此布局把 Agent 導入基礎架構與應用程式轉型流程，目標是加速企業現代化作業。

[https://ift.tt/s29gwRX]

LangChain 與 LangGraph 的選擇關鍵在流程控制權

一篇開發實務文章指出，在 LangChain 1.4.3 中，create_agent 會回傳 LangGraph 的 CompiledStateGraph。文章提出的判斷方式是：若由模型決定下一步，可使用 create_agent；若流程節點與轉移應由程式控制，則直接採用 LangGraph 較合適。

[https://ift.tt/oD9VPSQ]

Agent 上線測試不能只沿用確定性的單元測試

傳統軟體測試通常能以固定輸入與斷言判定成功或失敗，但 Agent 的規劃、工具選擇及輸出具有非確定性。正式環境的驗證因此需要涵蓋任務完成度、工具呼叫軌跡、失敗模式與治理條件，並持續蒐集執行資料，而非僅在發布前跑一次測試。

[https://ift.tt/nsxSctP]

Agent 失敗常源自工具能力缺口，而非模型本身

Arize AI 的示範以玩具商店 Agent 無法處理特定價格條件為例，追查後發現問題在搜尋工具缺少價格篩選功能。案例呈現一套實用改善迴圈：先建立可觀測性、檢視執行軌跡、定位工具或流程缺口，再交由程式開發 Agent 修改並重新驗證。

[https://www.youtube.com/watch?v=F0TNSmbo5hE]

Apple 收緊完整磁碟存取，回應個人 Agent 的隱私風險

Apple 預告將要求使用者更明確地同意應用程式取得 macOS「完整磁碟存取」權限。由於此權限可能涵蓋檔案、訊息、電子郵件及瀏覽紀錄，能代替使用者操作電腦的 Agent 也使授權範圍、同意流程與權限撤銷的重要性進一步提高。

[https://ift.tt/LlOREuC]

Personal Agent Protocol 嘗試標準化 Agent 與企業互動

Sierra 與 Meta 正推動 Personal Agent Protocol，目標是建立消費者個人 Agent 與企業互動的開放標準；Genesys、Instinct、Rocket、Shopify、Stripe 與 Walmart 被列為合作夥伴。若標準逐步落地，客服與商務系統將需要重新設計 Agent 身分、意圖傳遞及交易授權介面。

[https://ift.tt/V2seBfc]

[Tempest AI News] 技術新聞精華 (2026-10-07)

本期焦點集中在 MCP 與 AI 代理的企業整合、安全風險及工程實務。從憑證釣魚、提示注入、SSRF 到工具設計與記憶架構，顯示代理系統取得更多執行權限後，權限控管、網路隔離與輸出驗證已成為部署時不可忽視的環節。

假冒 ChatGPT、Gemini 與 Claude 的廣告入口竊取帳密

資安研究人員揭露一套由真人操作的釣魚平台，會仿冒 ChatGPT、Gemini、Claude、Perplexity、Meta Muse 與 Manus 等 AI 服務的廣告產品入口。攻擊目標不只包含帳號密碼，也涵蓋多重要素驗證碼；企業在採購或投放 AI 相關廣告時，應確認網域、登入流程與身分驗證頁面的真實性。來源：[https://ift.tt/QBkfzhi]

GitHub Copilot CLI 可能遭網頁指令誘導外洩本機機密

研究指出，惡意網頁內容可能誘使 GitHub Copilot CLI 擷取本機敏感資料並傳送給攻擊者，而且攻擊結果會因工作階段採用的模型而異。這類案例再次突顯間接提示注入的風險：代理讀取外部內容時，不應自動取得機密檔案與任意對外連線權限。來源：[https://ift.tt/Ck61IOb]

Microsoft UFO Mobile MCP 爆出 Android Shell 指令注入漏洞

CVE-2026-105788 影響 Microsoft UFO 3.0.10 之前的版本，問題出現在 Mobile MCP 的 type_text 與 launch_app 工具，已驗證使用者可能藉此觸發 Android Shell 指令注入。採用該框架的團隊應檢查版本與工具暴露範圍，並避免把未經驗證的輸入直接帶入系統指令。來源：[https://ift.tt/HbTfNxn]

MCP Toolbox Java SDK 1.0 推進企業代理資料存取

Google 發表 MCP Toolbox Java SDK 1.0，延伸 MCP Toolbox 在企業資料存取情境中的應用。對 Java 團隊而言，這項 SDK 提供更直接的整合路徑，讓代理透過標準化工具介面連接資料來源；實際導入時仍須搭配最小權限、身分驗證與稽核紀錄。來源：[https://ift.tt/tAsSRjm]

MCP 漏洞研究點名 Linear、Notion 與 Dropbox Dash 整合

資安業者 ClawSecure 公布 MCP 協定與實作面的漏洞研究，內容涉及 Linear、Notion 及 Dropbox Dash 等企業工具。事件提醒開發者：協定標準化不等於整合本身安全，仍須逐一檢視 OAuth 權限、工具參數驗證、信任邊界與跨服務資料流。來源：[https://ift.tt/ciP6qZW]

Kubernetes 內的 MCP Server 應限制 Metadata 與內網連線

一篇實務討論將焦點放在 Kubernetes 叢集內 MCP Server 的對外流量，特別是可能透過 URL 或路徑參數觸發的 SSRF。部署端可重新盤點網路政策、DNS、雲端 Metadata Endpoint 與內部 IP 存取規則，避免代理工具成為橫向移動或竊取雲端憑證的跳板。來源：[https://ift.tt/9JxoMkq]

AI 代理的提示注入與 SSRF 防護指南

這份指南整理 AI 代理連接 Shell、正式環境資料庫及雲端 API 後面臨的提示注入與 SSRF 風險。當履歷、客服單或網頁擷取內容進入代理迴圈時，應一律視為不受信任資料，並透過輸入隔離、工具權限限制、網路控管及高風險操作核准機制降低影響。來源：[https://ift.tt/0N5UWD1]

Amplitude 分享整併 MCP Server 的工程經驗

Amplitude 回顧早期依照 API Endpoint 逐一建立 MCP 工具所造成的問題，包括上下文膨脹、功能重疊，以及模型需要大量引導才能選對工具。其經驗顯示，MCP 工具不宜只是 API 的機械式映射；依使用者任務重新劃分工具邊界，通常更有利於代理選擇與維護。來源：[https://ift.tt/BNFLxQV]

MCP 解決工具連接，但沒有解決代理記憶

文章指出，MCP 標準化的是代理如何呼叫工具與取得資料，並未定義工作階段結束後應保留哪些資訊。團隊若要建立可靠的長期代理，仍須另外設計短期狀態、長期記憶、資料生命週期、存取權限與遺忘機制，不能把連線能力誤當成完整的記憶架構。來源：[https://ift.tt/liODHGR]

Paperclip 管理 Claude Code、Codex 與 Gemini CLI 代理團隊

Paperclip 是一套開源代理團隊管理工具，示範如何透過 Adapter、組織、目標、組織圖與任務委派，協調 Claude Code、Codex 和 Gemini CLI。影片並以小型筆記應用程式展示協調代理與程式開發代理的分工方式，適合評估多代理工作流程的團隊參考。來源：[https://www.youtube.com/watch?v=RknGPBeA6AQ]

VS Code 示範 Spring Boot、Copilot、MCP 與 Playwright 工作流

這支教學影片以 Java Spring Boot 專案串起 GitHub Copilot、VS Code 除錯、MCP 工具化與 Playwright 測試。內容涵蓋從應用程式開發到把功能轉換成代理可呼叫工具的流程，可作為 Java 團隊導入 AI 輔助開發與端對端驗證的實作參考。來源：[https://www.youtube.com/watch?v=ghh5VGouRVI]

ARGUS 以 MCP 代理架構支援配電網決策

期刊論文提出 ARGUS，一套以 MCP 為基礎的代理式大型語言模型架構，用於現代配電網的決策支援。這項研究反映 MCP 的應用正從通用軟體工具擴展至能源領域，但此類高影響情境仍需重視資料品質、可解釋性、驗證程序與人工監督。來源：[https://ift.tt/98SuLsl]

手機圈選介面問題後，直接定位原始碼檔案與行號

FIXME 是一套由 macOS 應用程式與行動應用程式 Debug 輔助元件組成的工具。開發者在手機或模擬器上圈選異常介面後，系統會透過 MCP 將對應的原始碼檔案、行號、UI Tree 與問題元素交給 Claude Code，展示視覺回報如何轉換成可直接處理的除錯上下文。來源：[https://ift.tt/Mv8R6cB]

[Tempest AI 深度解讀] 從賣晶片到替客戶擔保：Broadcom 如何綁住 Anthropic 的 600 億美元擴張 (2026-10-07)

這筆交易真正值得注意的，不只是 600 億美元有多大，而是晶片供應、設備租賃與信用風險開始被包進同一套商業模式。Broadcom 不再只是把晶片交貨後收款，而可能同時協助融資、承擔設備殘值風險，甚至透過可轉換債權分享 Anthropic 的股權上行；相對地，Anthropic 則用未來的 Claude 收入，提前鎖定今日尚未部署的運算能力。

先釐清：600 億美元仍不是已完成交易

原始報導稱，美國銀行、花旗與摩根士丹利已開始為 420 億美元優先擔保債務尋找投資人，Blackstone 另主導 180 億美元次順位部分；Broadcom 則對優先層提供設備「殘值支持」。報導並將這套安排與 Broadcom 擬提供 Anthropic、最高 420 億美元的可轉換融資並列。原文見：https://www.techtimes.com/articles/328625/20261006/broadcom-anthropics-chip-supplier-lender-debt-guarantor-60-billion-syndication-begins.htm

但必須劃出證據邊界。Bloomberg 的獨立報導確認，600 億美元方案尚未公開宣布，420 億美元優先層的資料來自不具名知情人士；換言之，聯貸邀請不等於承諾已全數到位，條件與規模仍可能改變。https://bloomberg.com/news/articles/2026-10-02/broadcom-starts-amassing-60-billion-to-fund-chips-for-anthropic

公開文件證實了什麼

可由第一方資料確認的是大方向。Broadcom 今年 6 月與 Apollo、Blackstone 成立 AI XPV 融資平台，目標在 2028 年前支援逾 20GW、採用其客製化 XPU及網路方案的運算容量；首筆交易為 350 億美元，用於 Anthropic 超過 1GW 的部署。https://investors.broadcom.com/news-releases/news-release-details/broadcom-apollo-and-blackstone-establish-landmark-strategic

Anthropic 也已公開表示，與 Google、Broadcom 簽下數個 GW 的次世代 TPU 容量，預計自 2027 年上線；同時強調其運算橫跨 Google TPU、AWS Trainium 與 NVIDIA GPU，並非完全押注單一架構。https://www.anthropic.com/news/google-broadcom-partnership-compute

至於更具體的 420 億美元可轉換融資，目前主要依賴媒體看到的非公開招股文件。Reuters 報導顯示，Anthropic 未來十年的基礎設施承諾至少達 5,180 億美元，約八成不可取消或須不論使用量照付，其中 Broadcom 相關設備租賃義務約 1,612 億美元。這些數字尚不能由公開版招股書逐項核對，引用時應保留此限制。https://www.investing.com/news/stock-market-news/anthropics-518-billion-ai-buildout-hinges-largely-on-deals-that-cannot-be-canceled-filing-shows-4922031

這套機制如何運轉

合理的結構解讀是：特殊目的載體向銀行與機構投資人借款，再購買包含 TPU、機櫃與網路設備的運算系統，最後租給 Anthropic；租金用來支付本金與利息。優先債權人先受償，次順位資金吸收較早發生的損失，而 Broadcom 的殘值支持則補強設備轉售價格不足的風險。

這與一般雲端採購的差別，在於資產與信用被拆開並分配給不同投資人。它能讓 Anthropic 不必一次支付龐大硬體成本，也讓 Broadcom 更快把設計訂單轉成出貨；代價是供應商、債權人與客戶的利益變得難以切割。

原文把 600 億美元聯貸與另一筆最高 420 億美元可轉換融資相加，得出 Broadcom 涉及 1,020 億美元融資的說法。這是名目金額的加總，不能直接視為 Broadcom 已承擔同額現金損失：兩者用途可能重疊，殘值支持也未必涵蓋優先層全部本金。真正曝險仍要看最終契約、擔保上限與資產折舊假設。

為何現在值得注意

Broadcom 自己的 10-Q 已警告，租賃、回購或擔保安排會增加交易對手信用風險與底層資產跌價風險；其前五大終端客戶又占最近九個月營收約五成。這表示「協助客戶買晶片」不只是金融附加服務，而可能改變公司的風險輪廓。https://investors.broadcom.com/static-files/96641754-401f-4090-a4ab-210728c83a28

作者觀點是，市場正在把 AI 加速器從快速折舊的科技產品，重新包裝成可長期融資的基礎設施。問題不在「有沒有抵押品」，而在抵押品是否真能跨越技術世代保值。客製 XPU 或 TPU 的買家、軟體相容性與部署環境都較受限；若模型效率提升、需求不如預期，或新一代晶片迅速取代舊設備，二手價格可能與融資模型的假設落差甚大。

對台灣供應鏈的意義

對台灣讀者而言，正面訊號是大型 XPU 專案可提前拉動晶圓製造、先進封裝、載板、記憶體整合與伺服器組裝需求，而且長約有助供應商安排產能。然而，訂單可見度不等於最終需求已被驗證。當採購由租賃與結構融資推動，供應鏈面對的不只景氣循環，也包括終端客戶能否產生足夠現金流，以及融資市場是否願意持續承接債務。

因此，台灣業者與投資人不宜只追蹤晶片數量或 GW 規模，也要觀察付款條件、庫存歸屬與取消條款。若設備先出貨、但最終使用率不足，風險可能沿著租賃載體、Broadcom 與供應鏈重新分配。

接下來的觀察指標

  • 600 億美元最終能否全數完成募集，以及優先、次順位債務的利率與期限。
  • Broadcom 殘值支持的金額上限、觸發條件及是否需列入資產負債表或附註。
  • Anthropic 公開招股書是否證實 420 億美元可轉換融資，並揭露與聯貸方案的重疊關係。
  • 2027 年 TPU 容量是否準時上線，Claude 的收入與使用量能否同步吸收新增供給。
  • Broadcom 客戶集中度、應收款、租賃資產與或有負債是否持續上升。

這不是已被證實的「金融危機前兆」，也不只是普通的大型晶片訂單。較準確的描述是：AI 算力擴張正把半導體公司推向基礎設施金融。它可以放大成長，也會把技術淘汰、客戶信用與資本市場流動性綁在一起；最值得看的，正是這三種風險是否會在同一時間轉向。