自主AI智能体与MCP服务器信任难题：Cisco开源Agent身份框架解析

为什么智能体正在改写身份与访问管理的规则

当AI智能体开始以机器速度自主执行任务时，企业沿用了数十年的IAM体系正面临根本性挑战。Cisco旗下孵化引擎OutShift的产品管理总监Jhulu Panath与Duo Security高级产品经理Cindy Chiu在一场技术分享中，系统阐述了这一问题的根源与应对思路。

OutShift的使命是探索与Cisco核心业务（网络、安全、可观测性、协作）相邻的新兴市场，当前聚焦于"智能体互联网"革命。其开源项目Agency已捐赠给Linux Foundation，目标是为智能体之间的互操作建立开放标准——正如当年互联网的TCP/IP协议一样。

Cindy Chiu指出，智能体的独特之处在于它同时具备人类和机器的属性：用概率性的自然语言沟通（像人），却以机器速度和规模运行（像软件）。这种组合带来了三个核心难题：发现与识别（在数百万智能体中确认对方是否可信）、安全连接（跨框架、跨平台传递复杂状态）、观测与评估（确保概率性系统按预期工作，不陷入冲突或死循环）。

Gartner的预测给出了紧迫感：到2026年，近半数企业应用将嵌入专用AI智能体，而目前这一比例不足5%。

传统IAM模型为何在智能体面前失灵

Cindy Chiu逐一拆解了三种主流访问控制模型在智能体场景下的局限：

• RBAC（基于角色的访问控制） 在人类和长期运行的服务中表现优异，但智能体没有"职位头衔"，其动作高度依赖上下文，粗粒度的角色无法描述"此刻要调用哪个工具完成哪个任务"。
• ABAC（基于属性的访问控制） 引入了位置、部门、数据敏感度等动态属性，灵活性更强，但策略条件随属性增加呈指数级膨胀，在机器速度下难以管理、理解和调试。
• ReBAC（基于关系的访问控制） 擅长建模"谁与谁相连"的协作关系，却无法表达智能体正在执行的具体任务，缺乏动态工具交互所需的细粒度控制。

这些模型共同的盲区在于：它们回答的是"这个人能不能访问"，而智能体需要回答的是"这个工作单元需要什么权限"。

MCP协议的单向信任缺口与三类攻击面

Cindy Chiu将讨论引向Model Context Protocol（MCP）。MCP为AI应用连接外部数据源、API和工具提供了标准化框架，但当前主流实现沿用了传统客户端-服务器模式——AI客户端向MCP服务器认证，信任基本单向流动。

这意味着AI智能体往往无法通过密码学手段验证MCP服务器是否合法、其宣称提供的资源是否真实。由此衍生出三类攻击面：服务器伪造（攻击者搭建仿冒服务器）、中间人攻击（缺乏双向认证导致通信被拦截或篡改）、权限提升（被攻陷的服务器开放不应访问的资源）。

值得强调的是，问题不限于MCP——任何AI智能体自主访问外部资源的系统都存在同样的信任单向性问题。跨组织边界运行时，单向信任必须升级为双向认证。

MCP（Model Context Protocol） 是由Anthropic于2024年底提出的开放协议，旨在为大型语言模型与外部数据源、工具和API之间提供标准化的连接方式。它采用客户端-服务器架构：AI应用（客户端）通过MCP协议向MCP服务器发起请求，以获取数据或执行操作。MCP的出现解决了此前每个AI应用都需要为不同工具单独定制集成代码的碎片化问题，被业界类比为“AI领域的USB-C接口”。然而，正如文中所指出的，当前MCP的主流实现中，认证与信任建立主要发生在客户端向服务器这一方向上，服务器本身缺乏向客户端证明其合法性的密码学机制，这种不对称的信任模型在跨组织、开放环境下的智能体交互中构成了显著的安全隐患。

Agency Agent Identity框架：证明它、治理它、扩展它

Jhulu Panath接棒介绍了Agency的应对方案。框架的设计原则可以浓缩为三步公式：Prove it, Govern it, Scale it。

密码学身份：让智能体无法被冒名

每个智能体获得可密码学验证的身份——没有共享用户账号，没有匿名服务。身份与智能体注册绑定，锚定在防篡改的信任节点中，并在整个生命周期内受管理。这从源头阻断了智能体相互伪造、越权而不被发现的可能性，也避免了凭据泛滥。

密码学身份通常依赖公钥基础设施（PKI）或去中心化标识符（DID）体系来实现。每个智能体持有唯一的私钥，并通过公钥或可验证凭证（Verifiable Credential）向交互方证明自己的身份。与传统的用户名/密码或API密钥不同，密码学身份不依赖于共享秘密，因此不存在凭据泄露后被冒用的风险，也无需在多方之间分发和轮换密钥。在智能体场景中，这一机制还支持对智能体的“出生证明”进行锚定——即将其注册信息与公钥绑定并记录在防篡改的账本或信任节点上，使得任何一方都能独立验证该智能体确实由声明的实体创建并持续受其管理。这为跨组织边界的智能体互操作提供了可审计的信任基础。

TBAC：为"工作"而非"人"授权

这是整个框架最具创新性的部分。TBAC（Task-Based Access Control，基于任务的访问控制）并非替代RBAC/ABAC/ReBAC，而是在其之上增加的能力层。它将权限逐步收窄：从宽泛的意图（task），到需要触达的系统与API，再到精确可审计的事务（transaction）。三者共同构成一个临时的、即时授予的权限信封——仅在任务活跃时生效，仅包含最小必要工具，任务完成后自动撤销。

这与委托或模拟（impersonation）有本质区别：TBAC授权的是工作单元本身，而非假装智能体是某个用户。

互操作与人类兜底

身份服务支持与Duo、Okta等现有IDP集成，企业无需重建认证栈。同时支持去中心化身份，让身份随智能体跨系统、跨组织流动。高风险场景下可触发human-in-the-loop审批。

演示验证：从403到带审批的交易

演讲者用一个多智能体汇率转换应用做了端到端演示：OASF财务助手智能体通过A2A协议与汇率兑换智能体通信，后者通过MCP协议访问汇率MCP服务器的两个工具——查询汇率与执行兑换。

初始状态下未配置任何策略，助手请求汇率直接收到403 Forbidden。为OASF智能体创建仅允许访问GetCurrencyExchangeRate工具的TBAC策略后，查询恢复正常。

当用户要求兑换1000美元时，由于未授权调用A2A智能体，再次返回403。补充两条策略后——一条允许A2A智能体访问TradeCurrencyExchange工具，一条允许OASF智能体调用A2A智能体——兑换成功完成。

最后是human-in-the-loop环节：将兑换规则标记为"需要审批"后，智能体尝试调用交易工具时，注册的移动设备收到推送通知，须在60秒内允许或拒绝，超时自动拒绝。拒绝则返回403，允许则交易完成。这条链路把"最小权限"和"人在回路"落到了可操作的工程实现上。

这意味着什么

Agency的路径提供了一个值得关注的范式：智能体安全的核心不是给智能体发一个账号，而是围绕"工作单元"重建整个授权逻辑。TBAC目前聚焦工具层级（tool-level），任务层级和事务层级的策略仍在探索中。项目已开源并纳入Linux Foundation的中立治理，这对希望参与标准制定的团队而言是一个可进入的入口。

对于正在将智能体引入生产环境的企业，这条思路的启示在于：身份必须是密码学锚定的、权限必须是即时的和任务绑定的、信任必须是双向的。三者缺一，自主性就会变成风险敞口。

背景补充

TBAC（Task-Based Access Control） 并非全新概念，在传统工作流管理和数据库系统中早有学术探讨，其核心思想是将访问权限与业务流程中的任务实例绑定，而非与静态的主体身份绑定。在智能体语境下，TBAC被赋予了新的内涵：一个“任务”由智能体的意图触发，经过策略引擎解析后生成一个临时的权限信封（permission envelope），其中精确列出该任务生命周期内允许调用的工具、API和事务范围。这种即时授予（just-in-time granting）机制与零信任架构中的“最小权限”原则高度契合，但更进一步——它不仅限制“能访问什么”，还限定了“在什么任务上下文中访问”以及“访问持续多久”。任务完成后权限自动失效，从根本上压缩了凭据泄露或权限滥用的窗口期。