Agentic AI 安全模式：AI 网关 OAuth2 令牌交换 与 MCP 防护

• 背景
• Agentic AI 参考架构
• 安全模式一：应用到 Agent（AI 网关模式）
• 安全模式二：Agent 到 MCP 工具（令牌交换）
  • 为什么不能直接传播 token？
  • 令牌交换流程
  • 端到端安全模式
• 安全模式三：Agentic 防护栏（Guardrails）
  • 风险分类
  • 风险映射到架构
• 总结

背景

Agentic AI 系统的核心特征是自主性和推理能力——它们能将复杂任务分解为可执行的子任务，编排执行流程，并在执行过程中监控、反思和自适应修正。

这意味着几乎每个企业业务流程都可以被”agent化”：从客服台到 HVAC 优化，甚至用 agent 搭建软件、数据和 ML 工程管道。但一个关键问题随之而来——安全。

传统应用的安全模型在 agentic 场景下完全不够用。AI agent 不是人，不遵循 HR 流程，也没有”问责”的概念——一个 agent 出错可能导致整个执行链崩盘。

Agentic AI 参考架构

要理解安全模式，先看架构。一个完整的 agentic AI 平台包含以下关键组件：

• 推理层：分解复杂任务，自适应调整执行策略
• Agent 市场/注册中心：存管可用 agent、工具和模型的目录
• 编排模块：协调多 agent 系统的执行和监控
• 集成模块：通过 MCP 协议连接企业系统（ERP、CRM、知识库）
• 共享内存管理：跨 agent 的数据和上下文共享
• 治理层：可解释性、隐私、安全、防护栏

当用户提交任务时，平台需要找到合适的 agent（或 agent 组）来执行。Chain of Thought（CoT）是目前最广泛的任务分解框架，而 ReAct（推理+行动）允许 agent 评估自己的输出、从中学习、修正推理路径。

Agent2Agent（A2A）协议定义了 Agent Card（JSON 格式的”数字名片”），包含身份标识、服务端点、协议能力、认证方式和技能列表。这为 agent 注册和发现提供了标准化方案。

MCP（Model Context Protocol）则被用作系统集成层的基础，类似 AI 模型的”USB-C”接口。它定义了三个核心构件：

• Resources：服务器提供给 AI 的结构化数据（代码片段、文档、查询结果）
• Prompts：预设的指令或模板
• Tools：AI 可以调用的实际操作

安全模式一：应用到 Agent（AI 网关模式）

用户/应用与 agent 之间的交互通过 AI 网关 来保护。架构如下：

核心流程：

1. 用户在业务应用中发起交互
2. 应用通过 授权码 + PKCE 向 Entra ID（或其他 IAM）认证用户
3. Entra ID 签发用户 access token
4. 应用将 token 放入请求头调用 AI 网关
5. AI 网关执行 On-Behalf-Of（OBO）交换，获取下游 agent token
6. 网关校验 token，执行策略（JWT 验证、角色/作用域检查）
7. 网关将已验证的上下文转发给 agent
8. Agent 在自身层面进行二次授权
9. Agent 执行业务逻辑并返回结果
10. AI 网关和 agent 都将调用日志写入 OpenTelemetry 平台

关键点：token 不可传播。agent 收到的 token 只针对该 agent 本身，不能被用来调用其他 agent 或 MCP 服务器。

安全模式二：Agent 到 MCP 工具（令牌交换）

当 agent 需要调用工具来完成任务时，它通过 MCP 协议与工具服务器交互。这里的关键安全机制是 OAuth 2.0 令牌交换（Token Exchange, TE）。

为什么不能直接传播 token？

两个原因：

1. 溯源性：如果 token 被传播，下游工具无法分辨请求是来自 MCP 服务器还是原始应用
2. 作用域：收到的 token 权限范围可能与 MCP 服务器需要的不匹配

令牌交换流程

1. Agent 收到用户/应用传来的 access token（此 token 的 aud 声明标识 agent 本身，sub 声明标识原始用户）
2. Agent 需要调用工具，向认证服务器的 token 端点发起令牌交换请求，携带：自己的凭证、收到的 access token、新 token 的目标作用域和受众
3. 认证服务器校验请求，签发一个缩小作用域的新 access token，明确指向目标 MCP 服务器（sub 声明仍保持原始用户身份——保留用户上下文）
4. Agent 用新 token 调用 MCP 服务器

对于长时间运行的批处理任务（没有用户上下文），使用 客户端凭证授权（Client Credential Grant, CCG）——这是为机器对机器（M2M）通信设计的 OAuth 2.0 流程，完全不需要用户交互。

端到端安全模式

完整的端到端流程涵盖：用户 → 应用/UI → AI Agent → MCP 服务器/工具 → 数据平台。

每一步跨越安全域时都要做一次令牌交换。这不是可选的——是为了防止 token 越权传播、保证审计链路完整。

安全模式三：Agentic 防护栏（Guardrails）

光有认证授权还不够。作者整合了 OWASP 和 IBM 两份白皮书中的风险清单：

风险分类

对齐与行为风险

• R1：对齐失败与欺骗行为（动态欺骗）
• R2：意图破坏与目标操控（目标不一致）
• R3：工具误用（工具/API 滥用）
• R4：记忆中毒（Agent 持久化）
• R5：级联幻觉攻击（级联系统攻击）

安全漏洞

• R6：权限泄露
• R7：身份伪造与模仿
• R8：意外 RCE 与代码攻击

运营韧性

• R9：资源过载
• R10：抵赖与不可追溯

多 Agent 合谋

• R11：多 Agent 系统中的恶意 Agent
• R12：Agent 通信投毒
• R13：人类对多 Agent 系统的攻击

人类监督

• R14：人类操控
• R15：人机环路过载
• R16：角色驱动偏见（IBM 特有）

风险映射到架构

重要的是，防护栏不能只丢给一个中央治理层。不同的风险需要在其对应的架构层进行管控：

• 推理层：处理对齐失败、意图破坏
• 工具集成层：处理工具误用、RCE
• 内存层：防止记忆中毒
• 编排层：管理多 Agent 合谋、资源过载
• 用户接口层：处理人类操控、环路过载

总结

Agentic AI 的安全仍处于早期阶段，但重要性与日俱增。随着 agent 开始执行带记忆的长任务、在多 agent 场景中协作、处理越来越复杂的数据工作流——现在就开始将安全设计融入架构中，比以后补救要明智得多。

核心原则：零信任 + 最小权限 + 每次跨域做令牌交换。

版权所有，本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处：https://www.wangjun.dev//2026/06/agentic-ai-security-blueprints/