代理式人工智能浪潮正在迅速加速。一开始只是配备简单工具的聊天机器人，现在已发展成为深度集成到企业工作流程中的自主数字工作者。
随着这些部署的成熟，一个关键的安全漏洞正变得越来越明显。
当前许多代理架构仍依赖于所谓的 “上帝之钥 “模型–在这种模型中，广泛、长期存在的凭证将用户身份、授权和工具访问权限合并为一个共享秘密。
这种方法无法安全扩展。
对于旨在大规模运行代理的企业来说，需要向委托身份和人工智能感知执行机制过渡。
下面我们将深入探讨真正的问题以及生产级解决方案的内容。
1.真正的风险：过度授权的代理证书
在许多早期的代理部署中，如 LangChain 风格的工具、自定义 MCP 服务器和内部工具网关，通常使用静态服务凭据来管理身份验证：
- 长效 API 密钥
- 共享服务账户
- 广泛的 OAuth 客户端证书
- 或粗糙的工作量特性
需要说明的是，MCP 本身不需要静态密钥。该协议支持适当的 OAuth 和委托身份模型。然而，在现实世界的实施中，许多代理仍然使用范围过大、非用户绑定的凭据与单个 MCP 服务器进行对话。
这就是风险的根源。
共享身份问题（跨用户归因）
考虑这样一种情况
- 50 名员工使用一个营销代理
- 代理使用一个服务证书调用 GitHub
在这种设置下，GitHub 日志会简单地显示Agent_Service_Account 删除了 repo X。
缺少什么？
- 哪个人发起的行动
- 用户是否获得授权
- 该行动是否在预料之中
从审计和取证的角度来看，归属感已经丧失。这不是 MCP 的缺陷，而是许多代理部署中存在的身份传播漏洞。
权限过宽问题（跨工具范围）
考虑到 MCP 服务器会暴露多种工具：
- 读取文件
- 文件列表
- 删除文件
如果代理使用单一、范围广泛的凭证进行验证，任何成功的提示注入或代理不当行为都有可能调用风险更高的工具。虽然 MCP 确实允许服务器强制执行每个工具的授权，但目前许多 MCP 服务主要集中在工具功能上，而不是设计为全面的企业策略执行点。
这就造成了巨大的建筑差距。
2.架构现实：MCP 服务器不是 ZTNA 网关
在大多数企业中，内部应用程序本身不需要实施全面的身份验证、授权和风险策略逻辑。相反，这一职责通常集中在企业应用程序前端的零信任网络访问（ZTNA）层。
应当以同样的方式看待多边协商程序服务。
实际上，许多 MCP 服务器
- 注重工具的执行
- 信源
- 实施粗略或服务级身份验证
- 缺乏深入的用户/组策略模型
- 不进行代币兑换
- 在设计上不适合处理即时驱动的风险决策
期望每台 MCP 服务器都充当完整的零信任执行引擎既不现实，也无法扩展。
3.为什么 ZTNA 是自然控制点
ZTNA 已经在企业安全领域发挥了重要作用：
- 面向内部应用程序
- 集中认证
- 执行访问政策
- 提供单一控制平面
- 减轻应用团队的负担
将这一模式应用于 MCP 服务，可为企业提供统一的方法来保护传统应用程序和人工智能驱动的工具访问。
保护传统应用程序和人工智能驱动工具访问的一致方法。
然而，人工智能对 ZTNA 解决方案提出了新的要求。
4.传统的 ZTNA 对人工智能行为视而不见
传统的 ZTNA 解决方案基于以下因素做出决策：
- 用户身份
- 设备姿态
- 网络背景
- 应用身份
人工智能代理流量增加了新的风险维度，例如
- 正在调用哪个 MCP 工具
- 传递了哪些参数
- 请求是否由提示生成
- 行动是否具有高风险
- 用户是否被授权使用该特定工具
传统的 ZTNA 解决方案无法看到或执行该层的控制。为了安全地前置 MCP 服务，ZTNA 必须具备 MCP 协议感知和人工智能感知能力。
我们需要的不是 ZTNA 的替代品，而是它的进化版。
支持 MCP 的 ZTNA：所需的演变
传统的 ZTNA 仍然是企业应用（包括 MCP 服务）的正确架构前门。事实证明，在应用程序外部集中访问控制具有可扩展性、可审计性和运行效率高的特点。
然而，代理驱动的工作流引入了两个新的要求，而传统的 ZTNA 在设计时并没有考虑到这些要求：
用于工具执行的用户级受权身份
MCP 工具活动的协议级可见性
满足这些要求并不能取代 ZTNA，反而会使其得到发展。
感知 MCP 的 ZTNA 层在两个关键方面扩展了传统的零信任模型：身份授权和协议感知授权。
授权身份：为什么需要代币交换
当人工智能代理调用 MCP 工具时，下游服务必须能够回答一个基本问题：
该操作是代表哪个人执行的？
直接向每个 MCP 服务传递广泛、长期的用户令牌既不安全，也无法扩展。它会造成过度的信任传播，并在令牌被滥用时增加爆炸半径。
相反，现代零信任架构使用委托身份。
在这种模式中
- 用户通过企业 IDP 进行身份验证
- 代理传播用户身份
- ZTNA 执行层验证用户
- 执行层执行令牌交换
- 为特定的 MCP 服务铸造一个短期的、范围狭窄的证书
这种方法可确保下游服务只获得请求操作所需的最低授权。
委托代币交换还允许企业：
- 执行一致的终生控制
- 使受众正常化
- 减少令牌爆炸半径
- 并保持完整的用户归属
但仅有身份是不够的。
为什么 MCP 协议意识很重要
即使拥有完美的身份识别，传统的 ZTNA 仍然缺乏对代理实际工作的可视性。
从网络角度看，MCP 流量通常显示为标准 HTTPS。如果没有协议意识，执行层就无法看到：
- 正在调用哪个 MCP 工具
- 传递了哪些参数
- 行动是否具有高风险
- 用户是否被授权使用该特定工具
这是关键的盲点。
可感知 MCP 的 ZTNA 层包括深度协议解析，可提取
- 工具名称
- 工具参数
- 会议背景
- 用户索赔
这些信号可实现细粒度的人工智能感知授权策略，远远超出简单的应用程序访问决策。
只有在身份授权和 MCP 级检查都到位后，代理工作流才能实现真正的最小权限执行。
关键实施细节：代理必须传播用户身份
要使委托身份实现端到端功能，代理运行时必须主动传播用户身份信息。在当前的许多部署中，用户在前端已通过身份验证（例如，使用 ZTNA 和 OIDC），但下游工具调用仍使用静态服务凭证。当出现这种情况时，用户属性就会丢失，最低权限控制就会失效。
要启用人工智能感知零信任，代理或代理框架必须确保出站 MCP 或工具请求携带可验证的、用户绑定的凭证，以实现 AI>Secure。在大多数代理框架中，这种功能都不是自动实现的，通常需要明确的配置，在某些情况下还需要对代码进行少量修改。
推荐的生产模式：双身份头罩
在生产型 AI>Secure 部署中，请求通常包括两个独立的可验证身份：
代理身份：
授权：承载者
用户身份：
X-AI-User-Assertion：
上游授权：
授权：承载者
在进行任何策略评估之前，AI>Secure 都会对这两种令牌进行独立验证。
代理有哪些变化（最低限度）
大多数代理框架只需稍作改动即可支持这种模式：
- 将 MCP 端点指向 AI>Secure
- 继续发送现有的代理 JWT
- 添加携带用户 JWT 的出站标头
OpenClaw 等现代框架通常支持自定义出站标头，因此这种过渡非常简单。无需更改 MCP 协议。
AI>Secure 如何执行最小特权
当请求到达 AI>Secure 时，会发生以下步骤：
- 验证代理身份
- 验证用户身份
- 解析 MCP 流量
- 评估细粒度政策
- 人工智能>安全进行代币交换
- 向上游发送短时委托令牌
在转发请求之前，AI>Secure 会删除原始凭据并注入：
授权：承载者
这样就能确保 MCP 服务器只接收正确作用域的标识。
AI>Secure 必须配置的功能
每个 MCP 服务器的上游验证
对于每个 MCP 服务器，AI>Secure 都配置了适当的上游身份验证方法，包括
- OAuth 承载器
- API 密钥
- mTLS
- 其他支持的方法
细粒度授权政策
人工智能>安全策略能够执行：
- 工具允许/拒绝规则
- 论据检查
- 用户/组控制
- 基于风险的条件
身份代理配置
AI>Secure Identity Broker 处理以下任务：
- 验证收到的用户令牌
- 核实发行人和受众
- 执行 OAuth 令牌交换
- 铸造短期委托代币
- 向目标 MCP 服务扩展令牌
- 执行终生限制
- 可选择转换的索赔
有了这些机制，MCP 服务器只需接收权限最小的凭证，而无需自己执行复杂的身份逻辑。
底线
问题不在于 MCP 协议的缺陷。核心问题在于，许多早期（甚至现在）的代理部署依赖于权限过大且缺乏适当归属的凭证。这些凭证授予了过多的权限，而且无法明确识别是哪个用户或代理执行了特定操作。因此，MCP 服务被要求执行安全控制和访问策略，而它们在设计时根本没有考虑到这一点，这给它们的实施带来了不必要的负担。
通过在 MCP 服务前放置人工智能感知 ZTNA 层，企业可以
- 集中访问控制
- 保留用户归属
- 执行每工具最低权限
- 避免 MCP 服务实施负担过重
针对人工智能时代调整零信任架构的组织将最有能力安全地扩展数字员工规模。在自主代理时代，零信任必须从谁可以连接扩展到人工智能实际上可以做什么。