MCP权限升级盲区：授权不等于身份验证

引言：一个被忽视的安全空白

随着AI Agent（智能体）逐渐从实验走向生产环境，如何管理它们的权限成为一个绕不开的话题。MCP（Model Context Protocol，模型上下文协议）在这方面做出了重要贡献——它标准化了Agent请求更多权限的方式。MCP是由Anthropic于2024年底推出的开放协议，旨在为大语言模型（LLM）与外部数据源、工具之间的交互建立统一标准。在MCP出现之前，每个AI Agent框架都需要为每种外部工具编写专属的集成代码，导致生态碎片化严重。MCP采用客户端-服务器架构，定义了Agent如何发现可用工具、如何传递上下文、如何请求执行权限等一系列标准化流程——可以将其类比为AI领域的USB-C接口。目前MCP已获得OpenAI、Google DeepMind等主要AI厂商的支持，正在成为行业事实标准。

MCP的出现解决了AI Agent生态中的「N×M集成问题」——如果有N个Agent框架和M个外部工具，传统方式需要编写N×M个适配器，而MCP将其简化为N+M个（每个框架实现一个Client，每个工具实现一个Server）。这种设计模式在软件工程中并不陌生：ODBC/JDBC之于数据库、LSP（Language Server Protocol）之于代码编辑器，都采用了类似的中间协议层思路。事实上，MCP的设计团队明确表示受到了微软LSP的启发。截至2025年初，MCP生态已涌现出数千个社区贡献的Server实现，覆盖数据库、云服务、开发工具、通信平台等主要类别，Anthropic、OpenAI、Google等主要AI厂商均已在其产品中集成MCP支持。

从技术架构来看，MCP采用JSON-RPC 2.0作为通信协议基础，定义了三个核心角色：Host（宿主应用，如Claude Desktop）、Client（协议客户端，负责与Server通信）和Server（提供工具和资源的服务端）。JSON-RPC 2.0是一种轻量级的远程过程调用协议，使用JSON格式编码请求和响应。相比REST API的资源导向风格，JSON-RPC更适合MCP这种以「方法调用」为核心的交互模式——Agent本质上是在调用远程工具的方法并获取返回结果。JSON-RPC 2.0的关键特性包括：支持批量请求（Batch Request）以减少网络往返、支持通知（Notification，无需响应的单向消息）、以及标准化的错误码体系。MCP在此基础上定义了特定的方法名（如tools/list、tools/call）和参数结构，形成了Agent工具调用的完整语义。

Server通过声明capabilities来告知Client自己支持的功能集，包括tools（可调用的工具）、resources（可访问的资源）和prompts（预定义的提示模板）。这种声明式的能力发现机制，使得Agent无需硬编码就能动态感知可用的外部能力。MCP支持两种传输模式：stdio（标准输入输出，用于本地进程间通信）和HTTP+SSE（用于远程服务通信），后者使得Agent可以连接互联网上任意符合MCP规范的服务端点。

然而，一个关键问题浮出水面：MCP虽然解决了「权限升级」（scope step-up），却没有回答「身份验证升级」（authentication step-up）的问题。

一句话概括核心洞察：MCP标准化了Agent如何请求更多权限，但它还没有词汇来询问持有令牌背后的那个人是否仍然在场。

这个看似微妙的区别，实际上触及了AI Agent安全架构中的一个根本性盲区。

权限升级与身份验证升级的本质区别

权限升级（Scope Step-up）的工作原理

在OAuth等授权框架中，「scope」定义了一个令牌能够访问的资源范围。OAuth 2.0是当前互联网最广泛使用的授权框架，它允许用户授权第三方应用访问自己的资源，而无需暴露密码。其核心概念「scope」定义了访问令牌的权限边界——例如GitHub的OAuth scope中，repo允许访问代码仓库，user:email仅允许读取邮箱地址。在OAuth流程中，客户端（此处即Agent）先请求特定scope，用户同意后获得对应权限的访问令牌（Access Token）。

值得关注的是，MCP在2025年3月的规范更新中引入了基于OAuth 2.1的授权框架。OAuth 2.1是OAuth 2.0的整合演进版本，它强制要求使用PKCE（Proof Key for Code Exchange）来防止授权码拦截攻击，并正式弃用了隐式授权流（Implicit Grant）和密码凭证授权流（Resource Owner Password Credentials）等已知存在安全缺陷的模式。PKCE（发音为"pixy"）最初是为移动应用和单页应用设计的安全增强机制。在标准OAuth授权码流程中，授权码在从授权服务器重定向回客户端的过程中可能被恶意应用拦截（尤其是在移动设备上通过自定义URL Scheme劫持）。PKCE通过在授权请求前生成一个随机的code_verifier，并将其SHA-256哈希值（code_challenge）附在授权请求中，在令牌交换阶段再发送原始code_verifier供服务器验证，从而确保只有发起授权请求的客户端才能完成令牌交换。OAuth 2.1将PKCE从可选升级为强制要求，体现了安全默认（Secure by Default）的设计理念。

在MCP的实现中，MCP Server同时扮演OAuth授权服务器和资源服务器的角色，Client通过标准的授权码流程获取访问令牌。然而，这一设计主要解决的仍是「谁有权访问什么」的问题，而非「谁在此刻真正在场」的问题。

当Agent需要执行更敏感的操作时——比如从「读取邮件」升级到「发送邮件」——它需要请求更大的权限范围，这就是权限升级。MCP在这方面做得很好：它提供了一套标准化的机制，让Agent能够以结构化的方式向系统声明「我现在需要更高的权限」。这解决了Agent工具调用中的一个重要工程问题——权限的动态扩展。

值得注意的是，IETF已经在RFC 9470中定义了OAuth 2.0 Step-Up Authentication Challenge Protocol，为资源服务器要求客户端提供更高级别认证提供了技术规范。RFC 9470定义了一种机制，允许资源服务器通过标准的HTTP 401响应和WWW-Authenticate头部向客户端传达「当前令牌的认证级别不足」这一信号。响应中可以包含acr_values参数（指定所需的认证上下文类别，如要求生物识别认证）和max_age参数（指定可接受的最大认证间隔时间，如300秒表示认证必须在5分钟以内）。客户端收到此挑战后，需要引导用户完成符合要求的增强认证，获取包含满足条件的acr和auth_time声明的新令牌，然后重试原始请求。这一协议为分级认证提供了互操作性基础，但其设计假设是客户端背后有一个可以直接交互的人类用户——这在Agent场景中恰恰是不确定的。因此，这一机制如何在MCP的Agent交互模型中落地，仍然是一个开放问题。

身份验证升级（Authentication Step-up）解决什么问题

身份验证升级则是另一回事。它回答的问题不是「这个令牌能做什么」，而是「此刻，令牌背后是否真的有一个活生生的人在授权这次操作」。

在传统的人机交互中，当你要执行高风险操作（如大额转账、删除账户）时，系统会要求你重新验证身份——输入密码、进行二次验证（2FA）、生物识别等。多因素认证（MFA）技术在这方面经历了显著演进：传统的短信验证码（SMS OTP）因SIM卡劫持风险已逐渐被淘汰，取而代之的是基于TOTP（基于时间的一次性密码，如Google Authenticator）、FIDO2/WebAuthn标准的硬件安全密钥（如YubiKey）、以及设备端生物识别（如Face ID、指纹）等更安全的方案。

FIDO2是由FIDO Alliance和W3C联合制定的无密码认证标准，包含两个核心组件：WebAuthn（Web Authentication API，浏览器端标准）和CTAP（Client to Authenticator Protocol，设备端通信协议）。其安全性基于公钥密码学：注册时在认证器（如硬件安全密钥或设备TPM芯片）中生成密钥对，私钥永远不离开认证器，公钥注册到服务器；认证时服务器发送随机挑战（challenge），认证器用私钥签名后返回，服务器用公钥验证。这种设计从根本上消除了密码泄露和钓鱼攻击的风险。在Agent身份验证升级场景中，FIDO2可以作为最高级别的人类在场证明手段，因为它同时验证了设备持有（something you have）和用户身份（通过生物识别或PIN，something you are/know）。

这种「重新确认」保证了操作确实是由本人当下发起的，而不是被盗用的会话或自动化脚本在执行。

Agent时代为何必须重视这一区别

Agent打破了「人在场」的默认假设

在传统应用中，令牌通常绑定着一个正在使用应用的真人。但在Agent架构下，情况发生了根本变化：

• Agent可能在人类离开后持续运行数小时甚至数天
• Agent可能自主决策并触发一连串操作
• 令牌可能被长期缓存、传递，甚至在多个Agent之间流转

在传统Web应用中，访问令牌（Access Token）通常设置较短的有效期（如15分钟到1小时），配合刷新令牌（Refresh Token）实现无感续期。但在Agent场景下，令牌的生命周期管理面临全新挑战。Agent可能需要在后台持续运行数天完成复杂任务（如监控数据变化、定期生成报告），这要求令牌具有更长的有效期或频繁的自动刷新能力。然而，长寿命令牌意味着更大的被窃取和滥用风险——攻击窗口随令牌有效期线性增长。

在多Agent协作架构中，令牌委托（Token Delegation）是一个更深层的安全难题。OAuth 2.0 Token Exchange（RFC 8693）定义了令牌交换机制，允许一个服务用已持有的令牌换取适用于下游服务的新令牌。但在Agent-to-Agent场景中，委托链可能跨越多个信任边界：Agent A调用Agent B，Agent B再调用Agent C，每一层都可能对令牌进行转换和传递。这种链式委托不仅增加了令牌泄露的攻击面，还使得追踪「原始授权者的意图」变得极其困难。

在分布式系统中，信任传递（Trust Propagation）一直是核心难题。Kerberos协议通过可信第三方（KDC）和票据授予票据（TGT）机制解决了这一问题，但其集中式设计在去中心化的Agent网络中面临扩展性挑战。SPIFFE（Secure Production Identity Framework for Everyone）项目提供了另一种思路——通过为每个工作负载分配加密身份（SPIFFE ID），并使用短期X.509证书（SVID）作为身份凭证，实现工作负载间的零信任互认。将SPIFFE的理念应用到Agent领域，每个Agent可以拥有自己的加密身份，Agent间的调用通过双向mTLS认证，委托链通过SVID中的嵌套信任信息实现可追溯。这种方案的优势在于它不依赖中心化的令牌颁发机构，更适合动态组建和解散的Agent协作网络。区块链领域的可验证凭证（Verifiable Credentials）和分布式身份（DID）技术同样为解决这一问题提供了潜在思路，但距离在Agent生态中的标准化落地仍有相当距离。

零信任架构（Zero Trust Architecture，ZTA）的核心理念——「永不信任，始终验证」——在这里显得尤为重要。ZTA由Forrester Research的John Kindervag于2010年提出，后经NIST SP 800-207标准化。在传统IT环境中，ZTA通过持续验证（Continuous Verification）、最小权限访问和微分段（Micro-segmentation）来消除隐式信任。将ZTA原则映射到Agent安全领域，意味着：Agent的每一次工具调用都不应因为「之前已验证过」就被自动信任；Agent的网络访问应限制在完成当前任务所必需的最小范围内；Agent间的通信应该经过加密和双向认证。

这意味着，一个拥有充分权限（scope）的令牌，并不能保证操作背后有人类的实时意图。权限只回答了「能不能做」，却没有回答「现在这个人是否想做」。

高风险操作需要「人在回路」验证

设想一个场景：你的AI助手被授予了访问银行API的权限。某天，一个被注入的恶意提示（prompt injection）让Agent尝试转出一笔大额资金。Prompt Injection（提示注入）是AI Agent面临的最严重安全威胁之一——攻击者通过在Agent可能读取的数据源（如邮件内容、网页文本、文档附件）中嵌入恶意指令，诱骗Agent将这些指令当作合法的用户请求执行。这种攻击之所以危险，是因为当前的大语言模型在架构层面难以可靠区分「用户指令」和「数据中嵌入的指令」。间接Prompt Injection更是可以跨应用链式传播，使得拥有广泛权限的Agent成为理想的攻击载体。

在学术界，Prompt Injection已形成较为完整的分类体系。直接注入（Direct Injection）是用户直接在对话中输入恶意指令来覆盖系统提示词；间接注入（Indirect Injection）则更加隐蔽，攻击载荷嵌入在Agent访问的第三方数据中——例如攻击者在网页中隐藏白色文字指令，或在电子邮件中嵌入Base64编码的恶意提示。目前的防御手段包括：指令层级隔离（Instruction Hierarchy，OpenAI等已在模型层面实现）、输入/输出过滤器、沙箱化工具执行、以及基于LLM的二次审查。然而，OWASP将Prompt Injection列为LLM应用的头号安全风险（LLM01），表明当前尚无银弹级的解决方案，这进一步凸显了在关键操作节点引入人类验证的必要性。

从权限角度看，Agent完全「有权」这么做——它持有的令牌scope包含了转账操作。但从安全角度看，这里缺失了关键一环：没有任何机制去确认「此刻是否有真人授权这笔转账」。这正是身份验证升级本应发挥作用的地方，而MCP目前尚无对应的「词汇」来表达这一需求。

MCP协议的设计缺口与演进方向

协议层面缺少身份验证语义

核心问题在于：MCP作为一个协议，缺乏表达「请重新验证人类身份」的标准语义。当Agent遇到需要人类实时确认的高风险节点时，它没有一种标准化的方式来「暂停并请求人类重新在场证明」。

在Agent架构中实现身份验证升级的难点在于：Agent本身无法执行生物识别或密码输入，必须将验证流程「回传」给人类用户的设备端。这需要一套标准化的中断-恢复机制——Agent暂停当前任务，触发人类设备上的验证请求（如手机推送通知要求Face ID确认），验证通过后Agent获得带有「新鲜度证明」的新令牌并恢复任务执行。这一流程在技术上并非不可实现，但需要协议层面的标准化支持。

这不是MCP的设计失误，而是一个尚待填补的演进空间。任何新兴协议都需要时间来覆盖所有边界情况，而Agent安全领域本身也在快速发展。

四种可行的解决思路

要弥补这一缺口，协议和实现层面可以考虑以下方向：

1. 引入身份验证挑战机制：在MCP中增加一类信号，允许资源服务器要求「新鲜的」身份验证证明，而非仅仅是有效的令牌。这可以借鉴RFC 9470中定义的Step-Up Authentication Challenge的设计思路，将其适配到MCP的请求-响应模型中。具体而言，MCP Server可以在工具调用响应中返回一个标准化的authentication_required错误码，携带所需的认证级别（如acr_values）和最大允许认证时间间隔（如max_age），Client据此触发相应的认证流程。

2. 令牌新鲜度（Freshness）标记：区分「刚刚由人类验证过」的令牌和「长期缓存」的令牌，让敏感操作只接受前者。具体而言，可以在令牌的Claims中嵌入auth_time（最近一次认证时间）字段，资源服务器根据操作敏感度设定可接受的最大认证时间间隔——例如，转账操作要求auth_time在5分钟以内。OpenID Connect规范中已经定义了auth_time和acr（Authentication Context Class Reference）等声明，为这一方向提供了现成的技术基础。

3. 人在回路（Human-in-the-loop）钩子：为高风险操作设计标准化的人类确认流程，Agent执行前必须获得实时授权。Human-in-the-loop在AI Agent领域的实现通常包括几种模式：同步确认模式——Agent在执行敏感操作前暂停并通过推送通知向用户请求明确批准；异步审批队列——Agent将高风险操作放入待审批队列，人类审批者定期审核；以及分层自治模式——根据操作风险等级动态决定自治程度。

   实现HITL的最大实际障碍是确认疲劳（Confirmation Fatigue）。研究表明，当用户每天收到超过一定数量的安全确认请求时，批准率会趋近100%——用户不再阅读内容就点击「同意」。这一现象在Android权限弹窗、Windows UAC提示等场景中已被广泛记录。自适应认证（Adaptive Authentication）是解决这一矛盾的关键技术方向——通过综合分析上下文信号（设备指纹、地理位置、行为模式、时间规律等）动态调整认证强度，只在真正异常的情况下才中断用户。将这一理念应用到Agent场景中，可以构建「Agent行为基线」——当Agent的操作模式偏离历史基线时才触发人类确认，从而在安全性和用户体验之间取得平衡。

4. 操作风险分级机制：根据操作的敏感度，动态决定是否需要触发身份验证升级。这需要建立一套标准化的风险评估框架，综合考虑操作类型（读取vs写入vs删除）、涉及资产价值、操作频率异常度、Agent会话持续时长等因素，自动计算风险分值并匹配对应的验证要求。这一思路与金融行业的交易风控系统类似——银行不会对每笔小额消费都要求短信验证，但对大额跨境转账会触发多层审核。类似地，Agent的风险分级机制应该能够区分「读取天气数据」（低风险，无需额外验证）和「删除生产数据库」（极高风险，要求最高级别的人类确认）。

AI Agent开发者的安全设计清单

对于正在构建Agent系统的开发者而言，这一洞察提供了重要的安全设计提醒：

• 不要把「有权限」等同于「有意图」。令牌的scope只是访问控制的一部分，不应成为高风险操作的唯一门槛。在安全工程中，这体现了「纵深防御」（Defense in Depth）的原则——不依赖单一安全层，而是在多个层面设置防护。纵深防御的理念源自军事战略，在信息安全领域由美国国家安全局（NSA）推广，强调通过网络层、应用层、数据层、身份层等多层防护的叠加，确保任一层被突破时仍有其他层提供保护。

• 为敏感操作单独设计确认机制。即便MCP协议本身不提供，也应在应用层实现「人在回路」的保护。实践中，可以维护一个「敏感操作白名单」，将涉及资金转移、数据删除、权限变更、对外通信等操作纳入强制确认范围。建议同时实现操作的完整审计日志（Audit Trail），记录每一次敏感操作的发起时间、Agent身份、令牌信息、是否经过人类确认等元数据，为事后追溯和合规审查提供依据。

• 警惕长时间运行的Agent会话。会话越长，令牌背后「人还在场」的假设就越不可靠。建议实施会话超时策略，对于超过设定时长（如30分钟）未经人类交互的Agent会话，自动降低其可执行操作的风险等级，并在尝试高风险操作时强制触发重新认证。这一策略可以参考银行网银系统的会话管理实践——长时间无操作后自动锁定，恢复操作需重新认证。

• 实施最小权限原则（Principle of Least Privilege）。Agent在任何时刻都只应持有完成当前任务所需的最小权限scope，而非预先授予宽泛的权限范围。任务完成后应及时撤销不再需要的权限，缩小潜在攻击面。在实践中，这可以通过「即时权限」（Just-In-Time Access）模式实现——Agent在需要特定权限时动态申请，使用完毕后立即释放。AWS IAM的临时安全凭证（Temporary Security Credentials）和Google Cloud的短期服务账号令牌为这一模式提供了成熟的参考实现。

• 建立Agent行为监控与异常检测。除了事前的权限控制和身份验证，事中的行为监控同样不可或缺。通过记录Agent的工具调用模式、API访问频率、数据访问范围等行为特征，建立正常行为基线，当Agent的行为显著偏离基线时（如突然访问大量敏感数据、在非工作时间执行高风险操作）及时告警并介入。UEBA（User and Entity Behavior Analytics，用户和实体行为分析）技术最初由Gartner于2015年提出，旨在通过机器学习算法分析用户和实体的行为模式来检测内部威胁和账户接管。传统UEBA系统会建立每个用户的行为基线——包括登录时间模式、常用设备和位置、数据访问频率和范围等——并使用统计异常检测、聚类分析或深度学习模型识别偏离。将UEBA迁移到Agent监控领域需要重新定义特征集：Agent的「行为指纹」可能包括工具调用序列模式、API调用频率分布、数据访问范围的信息熵、任务完成时间的统计分布等。Splunk、Microsoft Sentinel等主流SIEM/SOAR平台已开始扩展其UEBA能力以覆盖非人类身份（Non-Human Identity），这一趋势将随着Agent部署规模的扩大而加速。

结语

MCP在标准化Agent权限管理方面迈出了重要一步，但权限升级不等于身份验证升级。前者管理「能做什么」，后者确认「谁在此刻授权」。

在AI Agent日益自主、令牌日益长寿的时代，这个区别不再是学术细节，而是关乎安全底线的实际问题。识别并填补这一空白，将是Agent安全基础设施走向成熟的必经之路。随着Agent生态的快速扩张——从个人助手到企业自动化，从单Agent到多Agent协作网络——建立一套涵盖身份验证升级语义的标准化安全框架，已经成为整个行业亟需共同推进的优先事项。

值得期待的是，随着IETF、OpenID Foundation等标准化组织对Agent安全议题的关注度持续提升，以及MCP规范本身的快速迭代，我们有理由相信这一安全空白将在不远的将来得到系统性的填补。但在标准化方案成熟之前，每一位Agent开发者都有责任在应用层实现必要的安全防护——不等待完美的协议，而是在当下就构建负责任的Agent系统。