{
  "title": "使用OIDC和OIDC-A保护MCP：超越",
  "excerpt": "将OpenID Connect (OIDC)和新的OIDC-A代理扩展与身份感知API网关集成,以安全地认证用户、LLM代理和MCP工具——远超基本的API代理。",
  "content_html": "<p>AI代理正在快速从研究演示转向真实的企业应用,将大型语言模型(LLM)与公司数据和服务连接起来。一种常见的方法是使用工具或插件让LLM获取上下文或执行操作——但有些人将这些视为只是\"华而不实的API调用\"。实际上,将AI与业务系统安全集成要复杂得多。这就是<strong>模型上下文协议(MCP)</strong>的用武之地,也是为什么具有<strong>OpenID Connect (OIDC)</strong>身份的强大代理架构对企业级部署至关重要。</p>\n\n<p>上图展示了安全MCP实现的高级架构。其核心是将API网关/代理作为AI代理和MCP工具之间的中央安全控制点。代理与支持OIDC的身份提供商协同工作,创建一个强制执行身份验证、授权和访问控制的安全边界。这确保了来自AI代理的所有MCP请求在到达实际的MCP工具之前都经过适当的身份验证和授权,而这些工具又访问各种后端系统。</p>\n\n<p>MCP是一个开放标准(最初由Anthropic推出),为AI助手与外部数据源和工具交互提供了一致的方式。MCP不是为每个系统定制集成,而是充当通用连接器,允许AI模型通过标准化的JSON-RPC接口检索上下文或执行任务。重要的是,MCP<strong>在设计时就考虑了安全性</strong>——默认情况下不会向AI暴露任何内容,它只能访问您明确允许的内容。然而在实践中,确保在众多工具和用户之间实施\"允许列表\"原则需要仔细的基础设施。生产级<strong>API网关(代理)</strong>可以充当AI代理(MCP客户端)和工具或数据源(MCP服务器)之间的守门人,强制执行身份验证、授权和路由规则。</p>\n\n<h2>超越\"华而不实的API调用\"：安全MCP集成的必要性</h2>\n\n<p>乍一看,通过MCP使用AI工具似乎就像调用Web API一样简单。在基本演示中,LLM代理可以访问REST端点,获取一些JSON,就这样。但在真实的企业场景中,幕后发生了更多事情:</p>\n\n<ul>\n<li><strong>用户身份和访问控制:</strong> 在交互式AI应用程序中(如可以查询内部系统的聊天助手),每个请求都来自具有特定权限的用户。系统必须确保AI只访问<em>当前用户</em>被允许访问的数据或执行的操作。与用户直接向服务进行身份验证的典型API调用不同,这里AI代理代表用户进行调用。如果没有适当的身份传播机制,您可能会将简单的工具调用变成严重的数据泄露或权限违规。</li>\n<li><strong>多步骤上下文交换:</strong> MCP支持有状态会话和流式交互。AI代理可能进行多轮对话,按顺序调用多个工具并综合它们的输出。这远远超出了一次性API调用。这个链条越长,发生<strong>上下文中毒</strong>等问题的可能性就越大——一个步骤中的错误或恶意数据会影响后续步骤。我们需要保障措施,以便一个工具的恶意响应不能欺骗模型在下一步做危险的事情。</li>\n<li><strong>复杂的委托链:</strong> 与上述相关,考虑工具调用其他工具的情况。例如,AI可能使用\"文件搜索\"工具,该工具本身查询数据库或调用另一个API。这个委托链应该在<strong>不</strong>过度授权任何步骤的情况下传递原始用户的权限和上下文。每一跳都需要一致地强制执行\"谁被允许做什么\",否则中间服务可能会执行用户不打算的操作。管理这些委托授权并非易事。</li>\n<li><strong>动态工具配置:</strong> 在敏捷环境中,新工具(MCP服务器)将频繁添加——想想启动新的微服务并立即将其提供给AI代理,或者允许安装第三方插件。这种动态性对灵活性很好,但对安全性来说是个头疼的问题。如何确保每个新工具都符合您的安全标准?如何防止引入未经审查甚至恶意的工具?自由放任的方法很快会导致混乱或违规。从第一天起就需要明确定义工具的<strong>入职、注册和策略执行</strong>。</li>\n</ul>\n\n<p>简而言之,企业必须以对待任何生产服务集成的严格程度来对待AI工具集成——如果不是更严格的话。适当的<strong>网关层</strong>通过充当中央控制点来帮助解决这些问题。代理不是将信任硬编码到每个AI代理或工具中,而是强制执行组织范围的安全策略。这种方法使我们<em>超越了\"只是调用API\"的思维模式</em>,转向一个结构化模型,其中每个MCP调用都经过身份验证、授权、监控和审计。</p>\n\n<h2>MCP工作流中的关键安全挑战</h2>\n\n<p>让我们检查在大规模部署MCP时出现的几个具体安全挑战,以及它们为什么重要:</p>\n\n<ul>\n<li><strong>上下文中毒:</strong> 因为MCP能够将外部数据馈送到模型的上下文中,所以存在数据可能被故意制作以误导或利用模型的风险。这可能是一种提示注入形式——例如,通过工具检索的文档可能包含劫持模型行为的指令。恶意行为者也可能尝试注册返回有毒内容或虚假信息的工具。架构需要验证和清理来自工具的上下文的方法。缓解措施可以包括对响应进行内容过滤、根据预期验证数据,或限制模型对某些查询信任哪些工具。</li>\n<li><strong>委托链和身份传播:</strong> 如前所述,AI代理通常代表用户行事。当它调用MCP服务器时,应该传递用户<em>是谁</em>(或至少他们被允许做什么)。如果工具然后调用后端API,该后端也可能需要凭据。这个委托链很棘手——您希望避免\"共享密码\"反模式或在开放环境中硬编码密钥。相反,解决方案涉及令牌和OAuth流程:例如,用户同意并颁发OAuth2/OIDC令牌,AI在MCP请求中携带该令牌,MCP服务器可以<strong>将其传递</strong>给后端API(或交换它)。管理这些令牌并确保它们被正确使用(而不是被其他人使用)是核心安全任务。代理应该通过在每个步骤附加和验证身份上下文来促进这一点。它还支持<strong>RBAC策略</strong>——例如,仅当用户的角色是管理员时才允许某些工具方法。</li>\n<li><strong>动态工具配置:</strong> 在MCP生态系统中,工具可以来去。例如,企业可能会快速为特定数据集建立新的MCP服务器或通过MCP集成第三方服务。如果没有控制,AI代理可能会在新工具出现后立即开始调用它。这是有风险的——您可能不希望默认情况下新添加的工具对所有人都可用,或者它可能需要审查。还有配置方面:新工具端点应该可以被AI发现,网关需要知道如何路由到它们以及需要什么身份验证。安全设置可能涉及代理咨询的<strong>工具注册表</strong>或发现服务,以及工具的管理批准。然后,代理可以自动为每个新工具强制执行适当的身份验证和路由,而不是依赖每个代理开发人员更新逻辑。这为工具生命周期提供了治理层。</li>\n</ul>\n\n<p>通过认识到这些挑战,安全工程师和架构师可以在问题发生<em>之前</em>设计防御措施。接下来,我们将看看身份感知代理如何以干净、集中的方式提供这些防御措施。</p>\n\n<h2>MCP的身份感知代理模式</h2>\n\n<p>云架构中经过验证的设计是在服务前面放置<strong>反向代理</strong>(通常称为API网关)。基于MCP的AI系统也不例外。通过在AI代理(客户端)和MCP服务器(工具/后端)之间引入智能代理,我们创建了一个受控漏斗,所有AI工具流量都通过它。该代理可以在第7层(应用层)运行,这意味着它理解HTTP甚至JSON有效负载,允许细粒度控制。下面,我们概述了这样的代理在保护MCP方面发挥的关键作用:</p>\n\n<h3>会话感知路由和负载均衡</h3>\n\n<p>与简单的无状态API调用不同,MCP会话可以是长期的并涉及流式传输(用于输出的服务器发送事件等)。代理应确保属于给定会话或对话的所有请求和响应得到一致处理。这通常意味着实现<strong>会话亲和性</strong>——如果运行多个MCP服务器实例,代理将每次将给定会话的流量路由到同一实例。这可以防止出现诸如工具A的状态(内存缓存、上下文窗口等)丢失的问题,因为请求2转到了与请求1不同的实例。现代代理可以使用HTTP标头或路由进行会话感知负载均衡(例如,将URL中的会话ID或客户端ID映射到特定后端)。此外,代理可以优雅地处理SSE连接,以便流式响应不会被网络中介意外中断。如果会话需要恢复或移交,网关可以协调(如即将推出的Envoy MCP功能所提议的)。简而言之,代理确保MCP有状态交互的可靠性和一致性,这对用户体验和维护正确上下文至关重要。</p>\n\n<h3>用于身份验证的JWT和OIDC集成</h3>\n\n<p>访问MCP网关的每个请求都应携带有效的身份令牌——通常是通过OIDC由身份提供商颁发的JSON Web令牌(JWT)。通过要求JWT,代理将身份验证从工具本身卸载,并确保只有经过身份验证和授权的调用才能通过。在实践中,这意味着AI代理(或用户与代理的会话)必须获取OIDC令牌(例如,ID令牌或访问令牌)并将其附加到每个MCP请求(通常在HTTP标头中,如<code>Authorization: Bearer &lt;token&gt;</code>)。代理验证此令牌,检查签名和声明(颁发者、受众、过期等),并拒绝任何未正确身份验证的请求。这样,您的MCP服务器永远不会看到匿名调用——它们信任网关已经审查了身份。</p>\n\n<h3>引入用于代理和工具身份的OIDC-A</h3>\n\n<p>虽然上面的讨论侧重于对<strong>人类用户</strong>进行身份验证,但生产级MCP部署还必须识别另外两个参与者:</p>\n\n<ol>\n<li>正在编排工作流的<em>LLM代理</em>。</li>\n<li>在后端被调用的<em>MCP工具/资源</em>。</li>\n</ol>\n\n<p>我们的配套文章\"<strong>OpenID Connect for Agents (OIDC-A) 1.0提案</strong>\"扩展了OIDC Core 1.0,为<strong>代理身份、证明和委托链</strong>提供了丰富的声明集。实际上,这意味着:</p>\n\n<ul>\n<li>当AI代理启动会话时,它获得一个包含OIDC-A声明(<code>agent_type</code>、<code>agent_model</code>、<code>agent_instance_id</code>、<code>delegator_sub</code>、<code>delegation_chain</code>等)的<strong>ID令牌</strong>。此令牌在每个MCP请求中与用户的访问令牌一起传输。</li>\n<li>MCP工具同样可以公开自己的OIDC身份(或被颁发签名的<em>资源令牌</em>),该身份宣传元数据,如工具功能、版本和信任级别(<code>agent_capabilities</code>、<code>agent_trust_level</code>、<code>agent_attestation</code>)。</li>\n<li>网关现在在每次调用时验证最多<strong>三个</strong>身份——<strong>用户→代理→工具</strong>——形成可以根据RBAC和合规策略评估的显式<em>委托链</em>。</li>\n</ul>\n\n<p>采用OIDC-A带来几个好处:</p>\n\n<ul>\n<li>对触及请求路径的所有内容进行端到端、可加密验证的身份。</li>\n<li>基于代理或工具功能的细粒度授权(例如,仅允许宣传<code>email:draft</code>功能的代理调用邮件工具)。</li>\n<li>内置证明(<code>agent_attestation</code>)使网关能够在将流量路由到代理和工具之前验证它们的完整性和来源。</li>\n</ul>\n\n<p>在本文的其余部分,当我们提到网关验证\"令牌\"时,假设这现在包括<strong>用户的令牌、代理的OIDC-A令牌,以及(可选)工具/资源令牌</strong>——所有这些都在单个策略决策步骤中进行评估。</p>\n\n<h3>工具元数据过滤和策略执行</h3>\n\n<p>代理的一个强大优势是它可以不仅基于URL,还基于请求中的<em>元数据</em>做出路由决策。使用MCP,请求和响应采用JSON-RPC格式,其中包括工具方法名称、参数甚至工具注释等字段。身份感知代理可以配置为检查这些细节并应用<strong>策略规则</strong>。例如,您可以配置如下规则:</p>\n\n<ul>\n<li><em>\"如果工具调用是<code>delete_file</code>且用户不在IT管理员组中,则拒绝请求。\"</em></li>\n<li><em>\"仅在工作日上午9点至下午5点之间允许<code>execute_sql</code>工具,并记录所有查询。\"</em></li>\n<li><em>\"如果工具标记为包含敏感数据,请确保响应被清理或加密。\"</em></li>\n</ul>\n\n<p>这类似于Web应用防火墙(WAF)或API网关执行内容过滤,但针对AI工具使用进行了定制。在Envoy MCP提案中,这对应于解析MCP消息并对其使用RBAC过滤器。代理本质上理解每个工具调用的<em>意图</em>,并可以适当地控制它。如果需要,它还可以编辑或转换数据——例如,从用户不应看到的响应中剥离某些字段,或屏蔽个人身份信息。通过在网关中集中这一点,您可以避免在每个工具服务中实现检查(这可能不一致或被遗忘)。<strong>审计</strong>是另一个好处:代理可以记录每个工具调用以及用户身份和参数,输入SIEM系统进行监控。这样,如果AI有一天做了不应该做的事情,您就有了明确的轨迹,知道涉及哪个工具调用以及是谁提示的。总之,基于元数据的过滤将代理变成了智能策略执行点,在MCP的基本功能之上添加了安全层。</p>\n\n<h3>版本感知和上下文感知路由</h3>\n\n<p>企业不断发展其服务——新版本、A/B测试、暂存与生产部署等。代理可以大大简化AI代理如何处理这些变化。代理可以实现<strong>版本感知路由</strong>,而不是AI需要知道要调用哪个版本的工具。例如,\"文档搜索\"工具的MCP端点对代理来说可以保持不变,但代理可能将90%的请求路由到服务的v1,将10%路由到新的v2(用于金丝雀发布)。或者将内部用户路由到\"测试版\"实例,而外部用户转到稳定版。这是通过匹配请求属性或使用包含用户受众和工具标识符的路由规则来完成的。</p>\n\n<p>同样,路由可以考虑<strong>上下文</strong>——例如,如果知道用户的位置,则将请求定向到最近的区域服务器以降低延迟,或者根据请求的大小选择不同的后端(可能是用于非常大文件的特殊高内存实例)。所有这些都可以在代理级别配置。AI代理只需调用逻辑工具名称,网关负责找到正确的后端。这不仅简化了操作(您可以升级后端工具而不破坏AI的接口),还增加了安全性。您可以隔离某些版本进行测试,或确保实验性工具仅在某些条件下可访问。通过控制流量流,代理有助于在宏观规模上维护<strong>最小权限原则</strong>——AI只通过适合当前上下文的路由到达它应该到达的后端。</p>\n\n<h2>使用代理实现MCP安全性:实用方法</h2>\n\n<p>既然我们已经介绍了关键的安全模式,让我们看看使用身份感知代理实现MCP安全性的实用方法。本节概述了设置安全MCP环境的步骤,重点关注组件之间的集成点:</p>\n\n<ol>\n<li><strong>设置身份提供商:</strong> 配置您的IdP(例如Azure AD、Okta、Auth0)以支持MCP安全所需的OIDC流程。这通常涉及创建OIDC应用程序、配置适当的范围和声明、设置重定向URI以及生成客户端凭据。</li>\n<li><strong>配置API网关:</strong> 设置OIDC集成,包括配置令牌验证参数(颁发者、受众等)、定义MCP请求的路由规则、配置工具访问的安全策略以及设置审计日志。</li>\n<li><strong>实现工具注册表:</strong> 创建数据库或服务来存储工具元数据、定义新工具的注册流程、实现工具访问的批准工作流,并将注册表与API网关集成。</li>\n<li><strong>定义安全策略:</strong> 定义工具访问的RBAC策略、配置响应的内容过滤规则、设置审计日志要求以及实现版本控制策略。</li>\n<li><strong>集成AI代理:</strong> 配置代理以获取和使用OIDC令牌、实现MCP客户端功能、处理身份验证和授权错误,以及管理令牌刷新和会话连续性。</li>\n<li><strong>监控和审计:</strong> 持续跟踪和审查系统活动,确保所有MCP交互都被记录和监控以用于安全和合规目的。</li>\n</ol>\n\n<h2>结论:超越华而不实的API调用</h2>\n\n<p>通过使用身份感知代理实现安全的MCP架构,您可以从\"华而不实的API调用\"远远超越到AI代理与业务系统之间强大的企业级集成。这种方法解决了MCP部署的关键安全挑战,包括:</p>\n\n<ul>\n<li>用户身份和访问控制</li>\n<li>多步骤上下文交换</li>\n<li>复杂的委托链</li>\n<li>动态工具配置</li>\n<li>远程MCP更改和版本跟踪</li>\n</ul>\n\n<p>基于代理的架构提供了一个集中控制点,用于强制执行安全策略、管理工具访问和监控AI代理活动。它还通过抽象后端服务的复杂性并为AI代理提供一致的接口来简化操作。</p>\n\n<p>随着MCP继续发展并获得采用,本文描述的安全模式对于企业部署将变得越来越重要。通过现在实施这些模式,您可以确保您的AI代理基础设施是安全的、可扩展的,并为未来做好准备。</p>",
  "source_hash": "sha256:2e298f37ca328b0eb320a81887dd3640aeb212ad3bf1d820c547bb98ab9e3b19",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-05T01:27:39.823859+00:00"
}