Agent安全棧：傳輸、身份、策略、運行時

假設你正在構建一個Agent。它讀取Linear的問題、從Gmail獲取上下文、打開GitHub的PR並在Slack中發佈更新。或者，它是一個由編排器協調的Agent系統，將任務分配給各個專業Agent。現在，你需要弄清楚如何保護所有內容，結果你打開了多個瀏覽器標籤頁，每個都指向不同的方向。

一個標籤頁在向你推銷MCP網關，另一個是非人類身份清單工具，另一個是運行時護欄，用於監控提示注入，另一個是連接器平台，另一個是策略引擎，還有一個是想要完全取代API密鑰的新規範。它們看起來都是“如何保護我的Agent”的答案，但實際上它們解決的是不同的問題。

我在Keycard從事Agent身份與訪問的工作，Agent安全解決方案正在迅速激增，以至於很難知道你需要什麼、為什麼需要以及用於什麼用途。這篇文章是Agent安全棧的地圖：每層做什麼，有什麼工具，邊界在哪裏，以及哪一層目前最不完善。

對Agent身份的需求

2026年1月，CrowdStrike同意以約7.4億美元收購身份安全初創公司SGNL。一個月後，Palo Alto Networks於2026年2月11日完成了對CyberArk的250億美元收購。兩家公司在宣佈交易時都評論了Agent身份的未來。CrowdStrike首席執行官George Kurtz表示：“AI Agent以超人的速度和訪問權限運行，使得每個Agent都成為必須保護的超管身份。”Palo Alto收購CyberArk後，首席執行官Nikesh Arora表示：“AI Agent的新浪潮將要求我們保護每個身份——人類、機器和Agent。”

他們説得對，但這只是問題的開始，而不是結束。“Agent身份”不是一個問題，而是幾個問題，答案存在於Agent安全棧的不同層面。

為什麼單一Agent安全層不夠？

一個典型的人類API調用有一個控制面。你點擊一個按鈕，會話cookie傳到服務器，一個權限檢查決定會發生什麼。

Agent調用鏈有更多的面。LLM決定調用工具，調用穿越傳輸層，憑據隨之傳遞，接收服務授權調用。而且，這個“服務”越來越多地是另一個Agent，它會調用另一個，再調用第三個，每一步都需要自己的範圍權限，並可以追溯到發起整個鏈的人類。

每個面以不同方式失敗。傳輸層認證告訴你客户端允許連接，但它不告訴你用户授權了什麼。策略引擎評估規則，但它不知道憑據是如何發出的。運行時護欄監控行為，但它不知道Agent被允許訪問什麼。你不能將它們合併為一個檢查而不丟失重要內容。

因此，讓我們仔細看看Agent安全棧的各個層面。

第1層：傳輸

傳輸是前門。在這裏，Agent或客户端證明它被允許與服務器通信。

模型上下文協議（MCP）目前做了很多工作。MCP授權規範基於OAuth 2.1，並將MCP服務器視為資源服務器，與授權服務器分離。發現通過受保護資源元數據（RFC 9728）進行。2025年的規範修訂引入了兩個值得了解的內容。2025年6月的修訂使資源指示符（RFC 8707）成為強制性的，因此為一個MCP服務器頒發的令牌不能針對另一個MCP服務器重放。2025年11月的修訂增加了增量範圍同意，允許客户端僅請求每個操作所需的最小訪問權限，並引入了客户端ID元數據文檔以取代大規模動態客户端註冊。Agent2Agent（A2A）協議通過其自己的配置文件解決了類似的問題，用於Agent間通信。

專門圍繞MCP網關和代理構建的Agent安全產品將發現集中化、添加審計日誌，並在傳輸邊界執行策略。這類平台與一種傳輸方式耦合。圍繞MCP構建的網關在Agent通過A2A通信或直接調用REST API時無法實施控制。

在傳輸層運行的安全解決方案告訴你，此客户端是否允許連接，以及客户端的令牌是否對此資源有效。

傳輸層解決方案不會告訴你用户是否授權了此特定操作，誰在實際發起調用，或者Agent現在是否應該執行此操作。

第2層：身份與委託

這一層是建設最不足的，現在也是行動最多的地方。身份層的問題是：這個Agent是誰？Agent代表誰行事？Agent在執行什麼任務？

長期有效的API密鑰無法回答這些問題。環境變量中的靜態令牌只是表明“擁有此字符串的任何人都被授權”。它無法告訴你請求背後的用户、被授權的任務，或者授權是否仍然有效。

這一層有幾種解決方案，將它們混為一談是該領域令人困惑的原因之一。

工作負載身份：SPIFFE和SPIRE為工作負載提供加密身份，使服務無需共享密鑰即可證明自己的身份。雲提供商為託管工作負載提供自己的版本（AWS IAM Roles Anywhere、GCP工作負載身份、Vercel的OIDC令牌）。這是其他一切的前提條件；沒有它，你就回到了承載令牌。但工作負載身份本身不解決委託問題。它告訴你工作負載是真實的，但不告訴你工作負載代表哪個用户。結合運行時證明，這使得某些平台能夠完全消除靜態憑據。Agent的身份來自其運行時環境，而不是磁盤上的秘密。

委託原語：RFC 8693 OAuth 2.0令牌交換是這裏的基礎標準。客户端向安全令牌服務（STS）出示自己的身份和主題令牌，作為回報，它收到一個針對特定下游資源範圍的新令牌。

一個新的IETF草案，《Agent的事務令牌》，用actor和principal字段擴展了Txn-Tokens，其中actor是執行操作的Agent，principal是Agent代表的人類或系統。

Dick Hardt的AAuth提案走得更遠。每個Agent都有自己的加密身份：一個綁定到簽名密鑰的Agent標識符（aauth:local@domain），在已知URL發佈，任何方都可以驗證，無需預註冊和共享密鑰。這些是協議，而非產品。系統構建在其之上。

憑據代理：這些產品處理SaaS API的OAuth交互，併為你的Agent提供令牌。當你的Agent需要與二十個SaaS服務通信，而你不想自己管理二十個OAuth流程時，它們很有用。有些產品在其上增加了範圍級治理、即時確認或細粒度授權。但結構上，沒有哪個產品將身份、委託權限、Agent證明和策略融合到憑據發放時刻的單一策略評估中。憑據首先被代理。當存在策略時，它是單獨評估的。

Agent統一身份與訪問：Keycard提供了這一點。用户身份從Okta、Entra、Google或任何OIDC提供商聯合。工作負載身份從AWS、GCP、Vercel、GitHub Actions及其等價物聯合。Agent身份通過工作負載證明建立，將Agent綁定到已驗證的運行時（SPIFFE、Kubernetes服務賬户、雲實例ID、mTLS）。安全令牌服務實現OAuth 2.1及擴展，在Agent請求訪問時評估策略。團隊可以通過SDK集成，通過直接STS調用或通過MCP網關。無論入口點如何，底層的授權上下文和策略引擎是相同的。

這可以看作是針對Agent用例重新設計的IAM，其中主體可以是人、工作負載或代表人類行事的Agent。同一系統處理所有三種情況。

身份與委託層告訴你誰在執行操作、代表誰、有何權限、執行什麼任務。

這一層不具體告訴Agent在獲得憑據後允許做什麼。那是下一層。

第3層：策略

策略是關於特定上下文中特定操作是否被允許在特定資源上執行的問題。身份和策略回答不同的問題。身份告訴你Agent是誰，策略告訴你他們是否被允許做某事。

獨立的策略引擎佔據這一層。AWS開源了Cedar，它是形式化可驗證且強類型的。Open Policy Agent是一個長期存在的基於Rego的引擎。OpenFGA專注於基於關係的訪問控制。AuthZEN是一個新興的OpenID標準，用於供應商中立的PDP/PEP查詢協議，促進互操作性。

這裏的經典部署模式是PDP/PEP：策略決策點（PDP）回答“是否允許”，策略執行點（PEP）位於請求路徑中，允許或拒絕操作。這種模式是為已經存在的憑據設計的，你需要決定是否接受它。

這個假設很重要。

給定身份、操作、資源和一些上下文，策略決定操作是否被允許。

策略不告訴你憑據是如何到達的，或者在訪問評估後該怎麼做。

第4層：運行時行為與治理

最後一層是最混亂的，因為它涉及人們混為一談的三個不同問題。

運行時護欄：提供即時護欄的解決方案監控Agent的行為，並標記提示注入、工具投毒、越獄和行為異常。它們作用於內容，而非身份。護欄可以告訴你Agent行為異常，但不能告訴你Agent是否應該首先擁有訪問權限。

非人類身份清單：這些解決方案盤點環境中所有的API密鑰、服務賬户和OAuth授權，並告訴你哪些權限過高、過時或共享。它們是態勢管理。它們告訴你已經存在的憑據，而不是在請求路徑中發放或評估憑據。

審計與委託鏈：這些是日誌，記錄發生什麼、誰授權以及憑據允許做什麼。這一層的大多數工具在事後重建這些信息；有些在事前捕獲。

運行時行為與治理告訴你Agent是否在做不該做的事、環境中存在什麼憑據，以及Agent事後做了什麼。護欄可以防止運行時某些攻擊類型。

但這一層不告訴你Agent是否應該首先擁有訪問權限。

協議層正在快速發展

在過去18個月中，協議層經歷了真正的變革。MCP授權規範在不到一年內發佈了三個版本。A2A有自己的認證配置文件。RFC 8693令牌交換自2020年就已存在，但突然為Agent場景做了新的工作。《Agent的事務令牌》在2026年2月發佈了第四個IETF草案。AAuth以全新的視角看待Agent身份。AuthZEN同樣通過使政策查詢供應商中立來推動政策領域。

如果你的Agent認證構建在傳輸層內，那麼傳輸層的變動就會變成你的變動。MCP網關是最清晰的例子：它們在MCP邊界集中化策略。如果所有Agent流量永遠都是MCP，那很好。如果需要任何非MCP協議，那就是問題。每次規範修訂，你的網關都必須更新。每個新的傳輸層協議（A2A、AAuth的簽名HTTP、下個月推出的未命名協議）都需要部署新的網關。

如果你的Agent認證構建在傳輸層之下……