AI助手接进内部系统时，一把钥匙只能开一扇门

一家中型制造企业的IT部门，给销售团队的AI助手接了三个内部工具：客户管理系统、售后工单系统、报价审批系统。为了省事，三个工具共用一个访问令牌。一次排查时发现，工单系统的插件会把收到的令牌原样转发给报价系统，于是任何能调用工单插件的人，事实上也能触达报价审批。

以上是假设场景，但它对应的风险在一份公开协议规范里被点名。本栏目此前讨论过“AI同事离职后怎样收回钥匙”（身份的退出）；本文讨论的是另一件事：钥匙发出去时，它能开哪扇门。

已经发生的事

【事实】模型上下文协议（MCP）2025-06-18版规范“Authorization”一节写明：授权对MCP实现是可选的；使用HTTP传输时应遵循该规范，使用本地STDIO传输时不应遵循，而应从环境中获取凭证。该机制基于OAuth 2.1草案、RFC 8414（授权服务器元数据）、RFC 7591（动态客户端注册）和RFC 9728（受保护资源元数据）中选定的部分。

【事实】同一规范要求：MCP客户端必须按RFC 8707在授权请求和令牌请求中带上resource参数，标明令牌要用于哪个MCP服务器；MCP服务器必须验证令牌确实是专门签发给自己的，不接受面向其他资源的令牌；MCP服务器调用上游API时，必须使用上游授权服务器另行签发的令牌，不得转发从客户端收到的令牌。规范把后一种情况称为“令牌透传”，指出它可能引发“混淆代理人”问题，即下游误以为令牌已经过验证。

【事实】规范还要求：授权服务器应签发短时效访问令牌；对公共客户端必须轮换刷新令牌；客户端必须实现PKCE；所有授权服务器端点必须使用HTTPS；授权服务器必须对预先登记的重定向地址做精确匹配。

变化的机制：权限的单位从“人”变成“人×系统”

过去员工用一个账号登录多个系统，权限由各系统分别管理。AI助手接入后，常见做法是给助手配一个技术账号或一个令牌，让它代所有人访问所有工具。这样，“谁能做什么”被压缩成“助手能做什么”。MCP规范的要求恰好反过来：每个令牌绑定一个目标服务器，服务器拒绝别人的令牌，中转时换新令牌。

【推演】如果企业按这种思路设计内部AI接入，组织层面的变化是：权限审批要细到“这个助手、代表这个用户、访问这个系统”。好处是一次泄露的影响范围被限定在一个系统内，审计时也能看清每一次访问对应哪张令牌。代价是IT需要维护更多授权配置，业务部门开通新工具时多一道审批。可能失败的环节：规范只约束采用HTTP传输并启用授权的实现；本地运行的插件、或者自研的非MCP接入，不在这套要求之内，企业仍可能留下“万能钥匙”。

对组织的影响

• 内部AI工具的接入清单需要记录：每个工具对应哪个授权服务器、令牌发给谁、多久过期。
• 安全评审要检查插件或中间服务是否转发令牌。
• 业务部门申请“让助手也能用某系统”时，审批对象应是这一个系统的访问，而不是扩大助手的总权限。

建议试验：给已接入的工具做一次“钥匙盘点”

【建议试验】列出公司目前接入AI助手的全部内部工具。投入：IT安全1人，3到5个工作日。判断指标：每个工具是否使用独立令牌；令牌是否限定目标；有没有任何中间服务转发收到的令牌；令牌有效期多长。失败条件：发现任何一个令牌能被两个以上系统接受，或找不到某个工具的令牌是谁签发的。盘点结果交给IT负责人决定整改顺序。

边界

本文依据MCP 2025-06-18版规范，后续版本可能调整细节；规范是协议要求，不代表各厂商产品都已完整实现。本文不讨论具体身份管理产品的选型。

参考资料

• Model Context Protocol Specification 2025-06-18: Authorization. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization （核验日期：2026-11-04）
• IETF RFC 8707: Resource Indicators for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc8707 （核验方式：通过MCP规范对其要求的引述核对，未逐条通读原文；核验日期：2026-11-04）