前九篇拆解 Token Exchange、scope、tool 策略、HITL、MCP、供应链、撤销、审计。本文给出 可部署的参考架构、开源组件能力边界、迁移阶段——案例仅用 公开文档可核实 的部署模式描述,不写虚构金融机构故事。
一、参考架构总览
flowchart TD
User[用户] --> Host[MCP Host / Agent UI]
Host --> GW[Agent Gateway]
GW --> PEP[Policy Engine OPA/Cedar]
GW --> IdP[IdP Keycloak / Entra / Auth0]
GW --> MCP[MCP Servers]
GW --> APIs[Enterprise APIs]
IdP --> GW
PEP --> GW
GW --> Audit[Audit / OTel Collector]
CAEP[CAEP Receiver] --> GW
| 组件 | 职责 |
|---|---|
| IdP | OAuth/OIDC、Token Exchange、consent、CAEP 发送(若支持) |
| Agent Gateway | refresh 托管、Exchange、heartbeat、HITL 队列 |
| Policy Engine | tool/path/SQL 策略 |
| MCP Host | 模型 + MCP Client + 本地策略钩子 |
| Audit | 归一化日志、SIEM |
与 API Gateway 认证、零信任 IAP 同族——Agent Gateway 是 身份感知 BFF。
二、Agent Gateway 内部模块
┌─────────────────────────────────────────┐
│ Agent Gateway │
├─────────────────────────────────────────┤
│ Delegation Store (consent + constraints) │
│ Token Service (refresh + RFC8693) │
│ Tool Policy Sidecar (OPA) │
│ Approval Queue (HITL) │
│ CAEP Webhook Receiver │
│ Rate Limiter │
└─────────────────────────────────────────┘
关键路径:Agent 请求 → Gateway 验证 agent session → OPA tool 判定 → 需要 HITL 则 pending → Exchange delegated token → 转发 MCP/API。
三、开源组件能力边界(截至 2026-06)
| 组件 | Agent 相关能力 | 边界 |
|---|---|---|
| Keycloak | Token Exchange、OAuth 2.1、fine-grained permissions | CAEP 发送需查版本发布说明;非 MCP 专用 |
| OPA | tool 策略、decision logs | 不代管 OAuth |
| Envoy ext_authz | 请求级 authorize | 不懂 LLM tool;适合 API 层 |
| SPIRE | Agent 工作负载 identity | 不代用户委托 |
| OpenTelemetry Collector | 审计管道 | 策略在 SDK/Agent 侧 |
商业平台(Azure AI Foundry、Amazon Bedrock Agents 等,B 级):提供托管 Agent 运行时与部分 IAM 集成——本文不背书;选型时核对是否支持委托审计字段与 per-tool policy。
四、Envoy + ext_authz 层
企业 API 已有 Envoy 时,Agent 流量仍走 ext_authz:
# 概念配置片段 — 非完整生产文件
http_filters:
- name: envoy.filters.http.ext_authz
typed_config:
grpc_service:
envoy_grpc:
cluster_name: opa_envoy_pluginext_authz input 需含
delegator_id、agent_id(自 JWT
act)——Gateway 或 RS 解析 JWT 后注入 header
X-Delegator-Id、X-Agent-Id。勿信任
Client 自报 header 无 JWT 验证。
五、迁移路径
5.1 阶段 0:现状(Gen2 反模式)
Agent 持 user refresh token 直连 API。
5.2 阶段 1:Gateway 旁路
flowchart LR
A[Agent] --> GW[Gateway 转发]
GW --> API
refresh 迁入 Gateway;Agent 用 opaque session id。
5.3 阶段 2:Token Exchange
Gateway RFC 8693 Exchange;RS 开始解析
act。
5.4 阶段 3:Tool 策略 + HITL
OPA sidecar;高风险 tool 审批。
5.5 阶段 4:MCP 标准化 + 供应链
stdio/HTTP Server pin;per-server token。
与 零信任迁移策略 相同:每阶段可独立回滚、可度量。
六、公开可核实部署模式(B 级框架)
以下仅描述 文档中常见的模式名称,非虚构客户:
| 模式 | 公开来源类型 | Agent 身份要点 |
|---|---|---|
| 企业 Copilot + Entra ID | Microsoft Learn | OBO / conditional access |
| Google Workspace + DLP | Google Cloud docs | incremental scope |
| 自研 Internal Agent + Keycloak | Keycloak docs | Token Exchange |
落地时以各厂商 当前 文档为准——字段名可能随草案更新变化。
七、SLO 建议
| 指标 | 目标 |
|---|---|
| delegated token 签发 p99 | < 200ms |
| 撤销生效(无 CAEP) | ≤ access token TTL |
| 策略 evaluate p99 | < 50ms(本地 OPA) |
| 审计丢失率 | 0(同步写 Kafka 再 ack tool) |
八、全系列回顾
| 篇 | 核心产出 |
|---|---|
| 02 | RFC 8693 act 委托链 |
| 03 | scope + UMA ticket 思想 |
| 04 | tool 参数策略 |
| 05 | HITL 状态机 |
| 06 | MCP transport + OAuth |
| 07 | secret 隔离 + SBOM |
| 08 | 短 TTL + CAEP |
| 09 | 审计字段 + OTel |
| 10 | 本文架构 |
九、边界
- 不提供虚构 FinCo 案例数字
- 商业产品能力以官方为准
十、HA Gateway
active-active + OPA sidecar;IdP 依 vendor SLA。
十一、local dev
mock IdP——禁止 prod refresh token 进 laptop。
十二、success metric
act 审计覆盖率 100%;Agent 进程 user refresh
数 = 0。
上一篇:审计与归因
下一篇:系列索引
参考资料
- Keycloak Documentation, Token Exchange, 2026-06
- Open Policy Agent, Envoy Integration
- API Gateway 认证
- 零信任迁移
- Model Context Protocol Specification 2025-03-26
读完这篇,下一步读什么
优先读同系列或同问题的下一篇,把单篇消费变成主题集群。
【Agent 身份与安全】Function Calling 的授权模型
Tool schema 暴露面、允许列表 vs OPA/Cedar 策略引擎、SQL Agent 的 statement class 与 RLS 边界,以及 Host 层 tool 调用拦截架构。
【Agent 身份与安全】Agent 身份谱系:从 API Key 到委托 Token
四代 Agent 身份模型:API Key、OAuth 用户 token、Service Account、RFC 8693 Token Exchange 委托链。拆解 subject_token、actor_token、act claim,以及与 JWT/JWKS 系列的交叉引用。
【Agent 身份与安全】细粒度 Scope 与 UMA 2.0 启示
从 coarse scope 到 resource-specific consent:UMA 2.0 Permission Ticket 模型、Google incremental auth 对照,以及 Agent 场景下的动态授权边界。
【Agent 身份与安全】人机协同授权:Human-in-the-Loop
高风险 Agent 操作的 step-up 认证、同步确认 vs 异步审批队列、超时与 Agent 状态机,以及与自适应认证和 PAM JIT 的衔接。