【Agent 身份与安全】落地架构与案例框架

土法炼钢兴趣小组的算法知识备份

Liao Tonglang · 2026-06-18 · via 土法炼钢兴趣小组的算法知识备份

前九篇拆解 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_plugin

ext_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。