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认证构建在传输层之下……