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認證構建在傳輸層之下……