AI 代理框架只是中介軟體，而中介軟體信任漏洞比你的職涯還老 的封面圖片

Cor E

這是沒人想聽的事：我們早就知道如何破解那些元件會盲目信任彼此輸出結果的系統。我們已經知道二十五年了。只是我們給它取了新名字，然後把教訓忘得一乾二淨。

背景

「AI 代理框架」就是 orchestration 膠水。把 LLM 包裝起來，接上一堆連接器、外掛和工具呼叫的支架，讓它真正能做事（查詢資料庫、呼叫 API、寫檔案），這樣你就做出了一個代理框架。Dark Reading 那篇文章指出一件說出來就很明顯的結構性問題：這些元件形成了一條信任邊界鏈，而其中很多元件並不會驗證旁邊元件傳過來的東西。

如果這句話讓你有似曾相識的感覺，那是應該的。反序列化漏洞、透過內部服務呼叫造成的 SSRF、「受信任」上游解析器造成的 XML 實體注入——整個應用程式安全史，就是一部「元件 A 假設元件 B 已經做好驗證」的歷史。每當新的架構模式熱到足以吸引生產流量，而還沒有人對它做過威脅模型時，我們就會一次又一次地重新發現這個模式。

新的部分不是信任邊界問題。新的部分是，位於這條鏈中間的那個東西，是一個機率性文字生成器，它可能被自己的輸入說服去做奇怪的事，而且它現在已經直接連接到工具執行。

炒作檢驗

被過度宣稱的部分：把這件事包裝成某種需要 AI 專屬防禦的全新 AI 專屬漏洞類別。這不是。它只是一個穿著 LLM 戲服的整合安全問題。一旦你有外掛和連接器在元件之間傳遞資料而不做驗證，你就會遇到跟把任何一組微服務用隱含信任的方式黏在一起時一樣的問題。攻擊面是舊聞；新的只是有效載荷傳遞機制（提示驅動的工具呼叫）。

被低估的部分：這些代理框架被推出的速度有多快，而且沒有人做過基本的元件邊界威脅模型，因為大家都在搶著推出代理，而不是代理周圍的管線。沒有人想當那個花了三個 sprint 做工具呼叫之間的結構驗證，結果競爭對手卻推出閃亮展示的團隊。這種壓力是真實的，而且不會消失。

把這件事稱為全新 AI 威脅類別，對誰有利？坦白說，對所有在賣東西的人都有利。廠商得到新的緊迫性敘事，以及推銷新工具的理由，而不是「請像我們 2015 年就告訴你的一樣驗證你的介面」。安全團隊得到更容易合理化的預算項目，而不是「改善我們的 SDLC 衛生」。沒有人會從那個無聊但真實的答案中獲益，也就是：對待多元件分散式系統時該有的嚴謹度，一樣要用在這裡，並把 LLM 的輸出視為不受信任的輸入，無論它跨越哪一個邊界，因為它本來就是不受信任的。

影響

如果你正在建置或部署代理框架，實際的 takeaway 並不光鮮亮麗。orchestrator、連接器與外掛之間的每一次跳轉都是一道介面，而介面需要合約：結構驗證、輸出清理，以及每個工具呼叫實際允許做什麼的最小權限範圍。不要讓外掛的輸出直接傳進另一個工具的執行環境，只因為 LLM 這麼說了。這不是 AI 安全問題，這是輸入驗證問題，碰巧 LLM 是未受信任輸入的來源，而不是表單欄位。

對安全團隊來說，這是在提醒大家：「模型已經對齊」和「管線是安全的」是兩件完全不同的事，而很多組織目前只在檢查前者。對模型輸出進行紅隊測試的重要性，遠低於對模型產生東西之後、交給下一道元件之前所發生的事進行紅隊測試。

對整個產業來說：代理框架架構的擴散速度，遠快於任何關於元件之間應該如何互相驗證或驗證彼此的共享標準。這才是真正的差距。不是缺乏對信任邊界存在的認知，而是缺乏共識，不知道在這個特定堆疊中，驗證信任邊界到底應該長什麼樣子。

開放性問題

如果我們已經有二十年關於軟體元件之間隱含信任的慘痛教訓，為什麼每一個新的架構模式，都要再過五年才有人把這些教訓套用上去？

— Cor，Skyblue Soft

來源