AI Agent 身份与安全 — 系列规划

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

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

本文是写作规划，不是可发布正文。定位：IAM 系列（人）+ 零信任系列（边界）的自然延伸，回答 「非人类主体如何获得、行使、审计权限」。

一、为什么写这个系列

1.1 现有内容的覆盖情况

已有系列	覆盖	缺口
iam/ (20)	人、SSO、OAuth、服务身份 SPIFFE	Agent 作为独立主体未系统展开
zero-trust/ (18)	持续验证、设备姿态、策略引擎	`#18-zero-trust-emerging` 仅前瞻 1 篇
llm-infra/ (25)	Agent 框架、MCP、网关	偏工程栈，非身份安全模型
architecture/61-zero-trust	概览	不展开 Agent

结论：当 LLM Agent 代表用户调用 API、读写邮件、执行 SQL 时，传统 OAuth「用户登录 → 拿 token → 调 API」模型不够用。需要新系列拆解：Agent 身份、委托链、工具级授权、审计与撤销。

1.2 系列边界

是： - Agent 作为 OAuth/OIDC 客户端或 Resource Owner 的扩展 - MCP（Model Context Protocol）的安全模型与 threat model - 工具调用（function calling）的授权粒度 - 与 SPIFFE、零信任策略引擎的集成 - 真实协议与草案（RFC 8693 Token Exchange、CAEP/SSE draft）

不是： - Prompt 工程或 Agent 编排教程 - 替代 llm-infra/ 的框架选型 - 对未发布标准的臆测性「标准答案」

与 zero-trust/18 的关系：该文是前瞻入口；本系列是系统展开。

二、核心问题与目标读者

2.1 五个关键问题

Agent 的「身份」绑定在谁身上？ 用户委托 vs 服务账户 vs 独立 Agent ID — Token Exchange 如何表达 act claim？ → 第 2、3 章。
工具调用的授权边界在哪？ 「能调 search API」不够——SQL 的 WHERE 子句、文件路径是否该进策略？ → 第 4、5 章。
MCP 的信任模型是什么？ Host、Client、Server 三方的认证、授权、数据隔离。 → 第 6、7 章。
Agent 会话如何持续验证与撤销？ 用户 revoke 后正在运行的 Agent 怎么办？CAEP/SSE 能否用？ → 第 8 章。
Agent 行为如何审计？ 工具调用日志、PII、归因链（哪个用户委托的哪个 Agent 读了哪条记录）。 → 第 9、10 章。

2.2 目标读者

平台安全工程师、IAM 架构师、AI 应用后端负责人
先修：iam/02-sso-oidc、iam/10-workload-identity、zero-trust/06-continuous-verification
不假设：已读过 MCP 源码

三、篇目结构（10 篇）

第一部分：身份模型（第 1–3 篇）

01 — 系列索引

5 个问题、阅读路径、与 IAM/ZT/LLM-infra 边界
争议清单：哪些已有共识、哪些仍在草案

02 — Agent 身份谱系：从 API Key 到委托 Token

四代模型：API Key → OAuth 用户 token → Service Account → Delegated Agent Token
RFC 8693 OAuth 2.0 Token Exchange：subject_token、actor_token、act claim
JWT 结构示例（来自 RFC，非编造）
与 iam/06-jwt-jwks 交叉引用
坑：把用户 refresh token 直接塞给 Agent — 撤销与 scope 失控

03 — 细粒度 Scope 与 UMA 2.0 启示

从 coarse scope（read:mail）到 resource-specific consent
UMA 2.0 的 Permission Ticket 模型是否适用于 Agent
Google OAuth incremental auth 对照
不展开完整 UMA 教程 — 只取 Agent 相关机制

第二部分：工具与 MCP（第 4–7 篇）

04 — Function Calling 的授权模型

Tool schema 暴露面 = 攻击面
允许列表 vs 策略引擎（OPA/Cedar）在 tool 层的应用
SQL Agent：statement class 限制、read-only 角色、row-level 策略
与 iam/13-policy-engines、postgresql-kernel RLS 边界（PG RLS 另文引用）

05 — 人机协同授权：Human-in-the-Loop

高风险操作 step-up：转账、删除、外发
同步确认 vs 异步审批队列
超时与 Agent 状态机

06 — MCP 架构与安全基线

Host / Client / Server 三角
Transport：stdio vs SSE 的安全差异
认证：OAuth 2.1 for MCP（跟踪 IETF/OAuth 草案版本，写清版本边界）
来源：MCP 官方 spec（A 级）

07 — MCP Server 隔离与供应链

多 Server 并存时的 secret 隔离
恶意 tool description 注入（indirect prompt injection 的安全侧）
与 zero-trust/13-supply-chain-zt 联动

第三部分：持续信任与审计（第 8–10 篇）

08 — Agent 会话的持续验证与撤销

OpenID CAEP / Shared Signals Events（draft 状态标注）
短有效期 token + 轮询 vs 推送 revocation
与 iam/07-session-revocation、zero-trust/06-continuous-verification 对照
坑：Agent 缓存 tool 结果含 PII — revoke 后缓存仍泄露

09 — Agent 审计日志与归因

最小日志集：delegator_id、agent_id、tool_name、resource、decision、policy_version
OpenTelemetry span 建模 Agent 工具调用
与 iam/19-pam-iga-audit 联动
PII 在 Agent 链路中的清洗点

10 — 落地架构与案例框架

参考架构：IdP + Policy Engine + Agent Gateway + MCP Host
开源组件：Keycloak、OPA、Envoy ext_authz — 能力边界
商业：Azure AI Foundry、Bedrock Agents — B 级来源，不背书
迁移路径：从「用户 token 直连 API」到「Agent Gateway 代签」
案例：仅使用公开文档可核实的部署（不写虚构 FinCo）

四、依赖关系

01 (索引)
├── 02 (Agent 身份) ←── iam/02, iam/06
├── 03 (Scope/UMA) ←── 02
│   ├── 04 (Function Calling) ←── iam/13
│   ├── 05 (Human-in-the-Loop) ←── iam/09
│   └── 06 (MCP 架构) ←── 02
│       └── 07 (MCP 供应链) ←── zt/13
│           ├── 08 (持续验证) ←── iam/07, zt/06
│           └── 09 (审计) ←── iam/19
│               └── 10 (落地架构) ←── 全部

五、阅读路径

读者	路径
IAM 工程师转 Agent 安全	01→02→03→08→09
MCP 应用开发者	01→06→07→04
架构师	01→02→05→10
完整	01→…→10

六、来源台账

A 级

RFC 8693（Token Exchange）
RFC 6749、OAuth 2.1 草案（标注 draft 号与日期）
MCP Specification（modelcontextprotocol.io，标注版本）
OpenID CAEP / SSE 草案
Keycloak、OPA 官方文档（具体版本）

B 级

Anthropic/OpenAI/Google 官方 Agent 安全文档
NIST AI RMF（辅助 threat framing）

C 级（仅线索）

社交媒体「Agent 安全最佳实践」无版本帖

版本纪律

每个草案结论标注 「截至 YYYY-MM 的 draft 状态」
标准更新时文内写「以 spec vX 为准，旧版差异见脚注」

七、实验台账

实验	说明
Token Exchange	Keycloak 或 Auth0 配置 actor/subject token（若支持），记录 claim
OPA tool 策略	Rego 拒绝特定 tool + 路径组合
MCP stdio	本地 Host + 两个 Server，验证 secret 不交叉
OTel span	一次 Agent 工具链的 trace 结构

无法实测的协议行为（如 CAEP 推送）— 不写进结论，只写「规范意图 + 待验证」。

八、系列联动

系列	联动
`iam/`	02、06、07、10、13、19
`zero-trust/`	06、07、13、18
`llm-infra/`	Agent 框架、MCP 工程篇
`observability/`	09 审计与 OTel

九、边界承诺

承诺

草案标准明确标注状态
Threat model 分「已发生案例」与「理论风险」
每个协议机制配序列图
与 IAM 系列风格一致：中文标点、相对 .html 链接

不承诺

Prompt injection 全文（仅 tool/metadata 注入的安全侧）
具体 LLM 模型对齐
替企业做法务合规认定

十、写作顺序

01 索引 — 定边界与引用锚点
02 Token Exchange — 全系列理论基础
06 MCP 架构 — 工程读者最多入口，可与 02 并行
04 Function Calling 授权
08 持续验证 → 09 审计
03、05、07、10 补齐

十一、待确认问题

系列目录：post/agent-identity/ vs post/iam/agent-identity/（子系列）？
MCP spec 更新快 — 是否每篇标注 spec commit hash？
是否单独立法「Multi-Agent 互信」（A2A 协议）专篇？
中文监管语境（生成式 AI 暂行办法）是否专章 — 还是仅 B 级引用？

规划版本：v1，2026-06-18 下一步：确认目录与待确认问题 → 编写 index.md → 开始 02、06

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-06-18 · architecture / security

【Agent 身份与安全】AI Agent 的身份、委托与审计

IAM 系列（人）与零信任系列（边界）的自然延伸：当 LLM Agent 代表用户调用 API、执行 SQL、读写邮件时，传统 OAuth 模型如何扩展？拆解 Token Exchange、MCP 安全模型、工具级授权、持续验证与审计归因。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

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

一、为什么写这个系列

1.1 现有内容的覆盖情况

1.2 系列边界

二、核心问题与目标读者

2.1 五个关键问题

2.2 目标读者

三、篇目结构（10 篇）

第一部分：身份模型（第 1–3 篇）

01 — 系列索引

02 — Agent 身份谱系：从 API Key 到委托 Token

03 — 细粒度 Scope 与 UMA 2.0 启示

第二部分：工具与 MCP（第 4–7 篇）

04 — Function Calling 的授权模型

05 — 人机协同授权：Human-in-the-Loop

06 — MCP 架构与安全基线

07 — MCP Server 隔离与供应链

第三部分：持续信任与审计（第 8–10 篇）

08 — Agent 会话的持续验证与撤销

09 — Agent 审计日志与归因

10 — 落地架构与案例框架

四、依赖关系

五、阅读路径

六、来源台账

A 级

B 级

C 级（仅线索）

版本纪律

七、实验台账

八、系列联动

九、边界承诺

承诺

不承诺

十、写作顺序

十一、待确认问题

同主题继续阅读

【Agent 身份与安全】AI Agent 的身份、委托与审计