把一个能调付款、改库、发邮件的自主 Agent 丢进生产环境，第一道塌方的不是模型智商，而是授权模型。2026 年业界逐渐达成一个共识：OAuth 的 Authorization Code Flow（RFC 6749）从根上是为「人」设计的——人在点同意按钮时就知道自己要什么；而 Agent 是在推理时才决定调哪个动作，这往往发生在授权数小时甚至数天之后。这条「同意时机 vs 决策时机」的结构裂缝，让绝大多数 Agent 实际跑在过度授权之上：宽 scope、共享凭证池、零 per-agent 边界。修复方向不是再叠一层 prompt 护栏，而是把工具调用从「拥有令牌就能调」重构成「逐调用鉴权 + scope-action 映射 + 能力弱化 + 机器主体身份」的能力模型。本文拆解这条重构链路上的八个断层与三道闸门。
最小权限（Principle of Least Privilege）是安全圈最古老的规则，但 Agent 天生违反它。一个面向 MCP 生态的 Agent 默认拿到三样危险东西：宽 OAuth scope（为了省事直接给 repo:*、billing:write）、共享凭证池（多个 Agent 复用同一组 API key）、零 per-agent 权限边界（Agent 的身份就是用户的身份）。
结构性的病根在于时机错配。传统 OAuth 流程里，资源拥有者是人类，授权发生在「我知道我要干嘛」的瞬间，scope 粒度可以粗。Agent 模式下，授权发生在部署或连接时，而真正用哪个工具、传什么参数，是 LLM 在第 N 步推理时才决定的——模型可能把「读邮件」的权限临时用来「转发附件给外部联系人」。这不是 bug，是架构层面的语义错位：scope 是静态声明，action 是动态涌现，二者之间缺一层翻译。
| 失效模式 | 表现 | 后果 |
|---|---|---|
| 宽 scope | files:rw 一把梭 |
删库与读文件同权 |
| 共享凭证 | 多 Agent 复用 token | 无法定位误操作来源 |
| 继承式身份 | Agent=用户身份 | 用户全权=Agent 全权 |
| 一次性同意 | 部署时全勾选 | 推理时无二次校验 |
| 模型/机制 | 颗粒度 | 委托安全 | 同意时机 | 审计能力 | 生产成熟度 |
|---|---|---|---|---|---|
| OAuth 2.0 scope（人本） | 粗（资源级） | 弱（令牌即全权） | 一次性 | 中 | 极高 |
| MCP OAuth 2.1 + DCR | 中（工具级） | 中 | 连接时 | 中高 | 高（2026 主流） |
| Scope-Action Map | 细（动作级） | 中 | 逐调用 | 高 | 中高 |
| Capability Token（能力令牌） | 极细（单操作） | 强（可弱化 attenuation） | 逐调用 | 高 | 中 |
| Token Exchange 降权（RFC 8693） | 细（派生令牌） | 强（downscope） | 逐调用 | 高 | 中高 |
| SPIFFE/SVID 工作负载身份 | 系统级主体 | 强（mTLS+短证书） | issuance 时 | 极高 | 高（云原生） |
| CIMD（MCP 客户端身份） | 客户端级 | 中高 | 注册时 | 中高 | 上升中 |
这是 2026 年被反复提到的核心模式：不要让 Agent 直接消费 OAuth scope，而是在中间架一张「scope → 允许动作」的映射表。它的价值在于把「令牌持有的能力」和「本次调用是否被允许」解耦。即便令牌带着 repo:write 这种宽 scope，映射表仍可在单次调用上拒绝 repo:delete 这类高危动作，或要求额外同意。
# scope-action map：把宽 scope 收窄到具体动作
SCOPE_ACTION_MAP = {
("files.read", "download"): {"allow": True},
("files.read", "list"): {"allow": True},
("files.write", "upload"): {"allow": True, "require_consent": False},
("files.write", "delete"): {"allow": False, "reason": "需逐次同意"},
("billing.read", "invoice"): {"allow": True},
("billing.write","charge"): {"allow": True, "require_consent": True, "max_amount": 100},
}
def authorize(tool, action, ctx):
rule = SCOPE_ACTION_MAP.get((ctx.scope, action), {"allow": False}) # deny-by-default
if not rule["allow"]:
raise PermissionDenied(rule.get("reason", "默认拒绝"))
if rule.get("require_consent"):
ctx.must_pause_for_human_approval(timeout_s=300)
return rule
这张表的工程意义在于可审计、可测试：安全团队可以 review 整张表，而不是去读散落在 prompt 里的护栏指令。它把「最小权限」从一句口号变成了一个可以被 CI 校验的数据结构。缺点是维护成本随工具数线性增长——这正是后面 CIMD 与能力令牌要补的位。
OAuth 令牌是「持有即全权」的 bearer token——谁拿到令牌，谁就拥有令牌的全部权限，没有降级机制。能力安全模型（object-capability）走另一条路：权限绑定在一个不可伪造的令牌句柄上，且可以弱化（attenuate）后转交。Agent 拿到一个「能删除指定 file_id」的能力令牌，转给子 Agent 时可以进一步收窄成「只能删除这一个文件」，而不是把完整 files:write 权限递过去。
# 能力令牌：单操作、可弱化、短时效
capability = issue_capability(
principal="agent:researcher-01",
action="files.delete",
resource="file:doc_8842", # 绑定到具体资源
constraints={"expires_in": 300}, # 5 分钟过期
)
# 委托给子 Agent 前做 attenuation（弱化），无法扩权
child_cap = attenuate(capability, resource="file:doc_8842", max_calls=1)
能力模型的杀手锏是委托可控：多 Agent 协作时，权限沿调用链自然衰减而非膨胀。这一点 OAuth 单独做不到——OAuth 的 scope 是声明式的，无法在委托链上做结构性收窄，只能靠 token exchange 模拟。代价是能力令牌需要一套独立的颁发、撤销、过期基础设施，落地成本高于直接复用 OAuth。
如果你不想抛弃 OAuth 栈，又想要能力模型式的「按需收窄」，答案在 RFC 8693——令牌交换。Agent 用一个宽授权令牌，向授权服务器换取一个降权派生令牌（downscoped token），再拿派生令牌去调工具。派生令牌只包含本次调用真正需要的 scope，且可短时效。
# 每次工具调用前，用宽令牌换取极窄的派生令牌
derived = token_exchange(
subject_token=broad_user_token, # 用户委托给 Agent 的宽令牌
scopes=["files.read"], # 只为这一步申请
audience="mcp://filesystem.local",
lifetime_seconds=120,
)
resp = call_tool("download", args={...}, bearer=derived)
这条路径的好处是完全活在 OAuth 2.1 生态内，云厂商（AWS、Azure、GCP）的 STS/Workload Identity Federation 都原生支持 token exchange 语义，审计侧也能在日志里看到「哪个宽令牌换出了哪个窄令牌」。它是当前企业生产里最务实的折中：不推翻 OAuth，但堵住了「宽令牌直达工具」的口子。短板在于每次调用多一次 token exchange 往返，需要靠本地短缓存（按 audience+scope 维度）摊薄延迟，否则工具调用 RTT 会显著拉长。
前几层解决的是「令牌里装什么权限」，但还有一个被忽视的问题：Agent 本身没有身份。它要么借用户的壳，要么用一把静态 API key。2026 年从云原生圈借来的答案是 SPIFFE——为每个工作负载签发一个 SVID（SPIFFE Verifiable Identity Document），通常是一张带短 TTL 的 mTLS 证书。Agent 进程拿到 SVID 后，它就是一个可被验证的机器主体，而不是「某个用户授权的某个匿名调用」。
这层的价值在两点。第一，审计可追责：每一次工具调用都能定位到一个具体的 Agent 实例（spiffe://corp/agent/researcher-01），不再是共享凭证池里一团浆糊。第二，mTLS 双向认证：工具服务器也验证调用方身份，恶意或被污染的工具服务器无法轻易冒充合法 Agent 反向攻击。SPIFFE 与前几层是正交叠加的——SVID 解决「我是谁」，scope-action/capability 解决「我能做什么」。多 Agent 系统里，这一层几乎是从「能跑」到「敢上生产」的分水岭。
MCP 协议在 2026 年补上的关键一环是客户端身份。Scalekit 等厂商力推的 CIMD（MCP Client Identity）解决的是：当一个 Agent 作为 MCP 客户端去连一堆工具服务器时，服务器怎么知道这个客户端是谁、能调哪些工具？答案是把 MCP 客户端也纳入 OAuth 2.1 + 动态客户端注册（DCR，RFC 7591）的体系——客户端注册时声明自己的工具白名单与 scope 上限，服务器据此签发受限令牌。
# MCP 客户端注册声明（CIMD 风格）
client:
id: agent://researcher-01
registered_scopes: [files.read, search.query] # 上限，不能再多
tool_allowlist: [search, read_doc] # 只暴露这些工具给模型
max_delegation_depth: 2 # 委托链深度上限
audit_sink: https://audit.corp/mcp
CIMD 的实战意义在于工具可见性管控：与其把 14K 个 MCP 工具全注册给模型再指望护栏兜底，不如在客户端注册阶段就把模型能看到的工具收窄到一个白名单。这是「最小权限」在工具枚举层的落地——模型连「有这个工具」都不知道，自然谈不上误调。它把攻防界担心的工具污染面也顺带收窄了：不可见的工具，污染了也无法被 Agent 触发。
宽 scope 之所以危险，是因为同意发生在「一切尚未发生」的部署时刻。修复办法是把部分同意推迟到推理时刻——即「按需/增量同意」（just-in-time consent）。Agent 推理到「我需要 delete 这个文件」时，运行时发现 scope-action map 标了 require_consent，就触发一次结构化的人机交互检查点（HITL），而不是默默执行。
flowchart TD
A[Agent 推理: 选定工具+动作] --> B{鉴权网关 deny-by-default}
B -->|未命中 allow| X[拒绝 + 审计]
B -->|命中 allow| C{scope-action map}
C -->|低风险| E[Token Exchange 降权派生]
C -->|高风险 charge/delete| D[JIT 同意检查点 HITL]
D -->|人拒绝| X
D -->|人批准| E
E --> F[工具执行 + 能力令牌]
F --> G[审计日志: principal+scope+action+结果]
G --> H[返回结果给 Agent]
JIT 同意流最大的工程敌人是同意疲劳——如果每步都弹窗，UX 崩溃，用户会养成无脑点同意的肌肉记忆，反而比一次性授权更危险。所以实践中要做风险分级：低风险动作静默放行，只对「金额超阈值」「不可逆删除」「外发数据」「跨租户访问」这四类触发检查点。这与零信任里的「just-in-time, just-enough access」是同一套逻辑，只是触发源从人变成了模型。
零信任 Agent 权限模型要堵的三种失效模式可以一句话概括：宽令牌直达工具、权限沿委托链膨胀、误操作无法定位。对应的三道闸门是：鉴权网关默认拒绝（deny-by-default）、委托链深度上限 + 弱化、全链路审计。其中 deny-by-default 是底线——scope-action map 里未显式 allow 的，一律拒绝。这与大多数 Agent 框架默认的「注册了就能调」截然相反。
# 鉴权网关中间件（FastAPI 风格）
@app.middleware("http")
async def authz_gate(request, call_next):
principal = request.state.principal # 来自 SPIFFE/SVID
tool, action = parse_invocation(request)
rule = SCOPE_ACTION_MAP.get((principal.scope, action)) # 未命中即 None
if rule is None or not rule["allow"]:
audit.log(principal, tool, action, verdict="DENY")
return JSONResponse({"error": "denied by default"}, 403)
if delegation_depth(principal) > MAX_DEPTH:
return JSONResponse({"error": "delegation too deep"}, 403)
return await call_next(request)
审计回路是第三道闸门里最容易被低估的一环。它不只是写日志，而是要能回答「这个文件是谁删的、用了哪个派生令牌、委托链经过哪些 Agent」。没有这条回路，前两道闸门出了事也无法追责，最小权限就退化成一句写在 PPT 里的口号。
工具授权这条线本身不能直接做成 C 端训练营（太偏安全工程），但它是所有「Agent 上生产」企业课的核心模块。变现逻辑在于：B 端付费意愿最高的恰恰是「敢不敢让 Agent 碰生产系统」这个问题。一个针对工程团队的 2 天工作坊，模块切成「OAuth scope 现状审计 → scope-action map 落地 → token exchange 接入 → CIMD 客户端注册 → JIT 同意与审计」，客单价能撑到中高端。差异化卖点是不讲 prompt 护栏（那已被讲烂），而是讲身份与授权基础设施——这是 2026 年市场上仍稀缺的角度。落地阻力主要在企业 OAuth 系统改造的协同成本，需要甲方 IAM 团队配合。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。