Cloudflare提出智能体任务级访问架构

Cloudflare 在 2026 年 8 月 5 日发表《The Agent Access Model》，提出 Agent Access Model（AAM）：让智能体以短时、任务限定且绑定发送方的凭证访问工具与数据，并在 harness 和网络路径上持续执行策略。当天的 news peg 很明确：这是一份把任务级授权、执行中介和审计证据连在一起的参考架构。

可以直接确认的是，原文将 AAM 划为 6 个组件：四个运行时控制为 Agent Identity Broker、Task-Scoped Access Engine、Mediation Layer 与 Trust Ratchet；两个支撑系统为 Agent Activity Log 与 Grant Review Loop。Cloudflare 的表述也明确：AAM 是 reference architecture，不是 wire-level specification。因此，它不是一份已经获行业采纳的协议标准，也不是一项宣布全面落地的产品。

目前不能从文章推出的内容同样重要。Cloudflare 没有在文中公布统一 SDK、参考代码、客户部署数量、价格、覆盖全部 MCP 服务器的兼容表，或一个能够解决多主体委托的最终授权协议。现有 AI Gateway 与 Zero Trust 产品页可帮助理解 Cloudflare 的既有产品背景，却不能替代对 AAM 是否已经产品化的证明。

对开发者和安全团队而言，这篇文章的直接价值是评估框架：不要再把“模型收到什么提示”当成唯一权限边界，而要问一次工具调用和一次出网请求是否有独立、可审计、可撤销的身份与执行约束。是否能按该框架部署，仍要逐个系统核对身份提供方、工具适配器、网络路径和日志管道。

8 月 5 日新增的，是一套控制边界

Cloudflare 的起点是区分“长寿命的智能体服务”和“短寿命的任务运行”。同一套 harness 今天执行夜间对账、明天处理告警，或接收另一个事件，按原文的定义都应形成新的 task execution graph。也就是说，任务不是一个泛化的“机器人账号”，而是有发起主体、目的、资源边界和生命周期的一段执行图。

这种区分是对长期服务账号的反驳，而非换一个 token 名称。服务账号常配有长效密钥、宽范围 scopes 和低频轮换；短时智能体如果继承这套做法，凭证可能比工作本身活得更久，并出现在内存、日志或环境变量中。Cloudflare 因此要求凭证的生命周期与任务对齐：Identity Broker 签发的凭证最迟在任务结束时过期。这里的 short-lived 不能被写成“较短的长期 token”，更不能被改写为无限续期的会话令牌。

原文还给出两个进一步的限定。其一，task-scoped 表示凭证表达的是“哪个智能体代表哪个主体执行哪项任务”，而不是“这个智能体以后能做什么”。其二，sender-constrained 表示令牌绑定到 harness 持有的 proof key；即使令牌泄露，攻击者只有令牌本身也不能完成重放。文章还特别说模型不接收该凭证。发送方约束并不等于凭证永远不可被滥用，它只是在令牌被单独复制时增加一道使用门槛。

层次	AAM 的原文定位	可以写成的事实	不能据此写成
当天新闻	8 月 5 日发表的参考架构	Cloudflare 提出任务级访问模型和组件分工	Cloudflare 发布了通用智能体访问产品
凭证	短时、任务限定、绑定发送方	凭证应最迟在任务结束时到期	智能体获得可长期复用的 token
控制位置	harness 与网络路径持续中介	工具调用和出网请求可成为策略执行点	提示词本身能够授予或撤销权限
标准关系	借用现有身份原语	RFC 8693、RFC 9449 可提供部分能力	AAM 已成为新的 IETF 或行业标准
组织协作	原文保留开放问题	多主体授权仍需后续设计	多智能体、异步委托已被完整解决

文章的 10 分钟数字也需要按语境阅读。它出现在“夜间对账智能体”的示例中：调度器先为该任务建立十分钟的 capability ceiling，再让 Identity Broker 交换出任务范围内的凭证。这个数字用于展示能力上限如何服务于一个具体工作流，不是 AAM 的默认有效期，亦不是 Cloudflare 对所有工作负载给出的 SLA、套餐限制或安全阈值。

六个组件如何把权限留在执行路径上

原文将前四项称为 active controls。Agent Identity Broker 负责签发可验证的任务凭证；Task-Scoped Access Engine 在调度时将经批准的任务模板、发起主体权限、智能体服务权限以及资源所有者或租户策略相交，得出该任务的 capability ceiling。这个上限可以被智能体少用，也可以被后续状态收紧移除；若要扩大权限，原文要求新建一项经过授权的任务。

Mediation Layer 覆盖两类边界。第一类是工具路径：适配器在执行前构造并冻结完整请求表示，包括操作、资源、影响范围的参数、租户与收件人，然后由 Access Engine 对同一表示作出授权判断。第二类是网络出口：即便工具调用被管理，如果智能体或其子进程还能任意直连互联网，工具层的限制也会被绕开。网络层可依据目标地址和传输属性控制可达性；只有协议暴露足够信息，或流量在可信中介点终止时，它才能进一步判断 HTTP 方法、租户、收件人或应用操作。

Trust Ratchet 是这份架构里最具状态性的部分。它不是一次任务开始时的静态授权表，而是当受保护事件发生时，按策略从 task execution graph 中移除能力。原文强调，被 Trust Ratchet 移除的权限只能在一项新授权任务中返回，不能靠当前任务的 token 更新或一次 scope challenge 恢复。这一点防止“先拿宽权限，再在任务内申请恢复”的做法把撤权变成形式。

两个支撑系统则处理证据和下一轮配置。Agent Activity Log 是由 Identity Broker、Access Engine、harness、Trust Ratchet 状态存储与网络执行点共同写入的追加式、可查询记录；它试图回答“这个任务做了什么”和“代表某个主体做过什么”，而不依赖模型对自己行为的事后叙述。Grant Review Loop 使用这些证据审查任务模板与实际运行之间的差距，并把建议交给策略负责人。获批变更只影响未来任务模板，当前任务保留原来的 ceiling 与状态。

这也是为什么原文把“提示词”与“执行授权”分开。提示词可以表达意图，却不能发放凭证或扩大能力；真正的保障依赖工具与流量不能绕过中介、共享控制面在故障时采用 fail closed，以及各执行点对同一任务身份和状态版本达成一致。这些是参考架构提出的工程前提，不是文章已经用公开部署数据证明的结果。

两份 RFC 提供原语，但没有替 AAM 落地

Cloudflare 将 OAuth 2.0 Token Exchange（RFC 8693）和 DPoP（RFC 9449）列为可用原语。前者定义通过基于 HTTP 和 JSON 的 OAuth 2.0 Security Token Service 请求、取得安全令牌的协议，并可表达 impersonation 与 delegation。后者定义应用层的持有证明机制，将 OAuth 2.0 access token 和 refresh token 约束到发送方，以帮助发现令牌重放攻击。

二者与 AAM 的关系应按“可用部件”理解。RFC 8693 能帮助 Broker 把较宽泛的服务身份交换为任务身份相关的令牌；RFC 9449 的 proof-of-possession 可以支撑 sender-constrained 的要求。但 RFC 并不规定任务模板该怎样命名资源、Trust Ratchet 何时触发、harness 与网络中介如何共享状态、日志事件怎样关联到发起主体。Cloudflare 原文也明确说 AAM 不依赖某一个协议取胜。

材料	明确覆盖的范围	对 AAM 仍未给出的部分
RFC 8693	Security Token Service 的 OAuth 令牌交换、委托与模拟语义	任务能力上限、策略模板和撤权状态
RFC 9449	以持有证明实现 sender-constrained OAuth 令牌并辅助发现重放	哪个工具、资源、收件人可被任务访问
AAM 文章	身份、访问引擎、执行中介、状态收紧、日志与复核的组合关系	单一线级协议、统一实现和跨厂商互操作承诺
AI Gateway 产品页	AI 应用的模型连接、路由、缓存、可观测性和统一计费等产品描述	其已实现 AAM 所有控制面或负责任务凭证签发
Zero Trust 产品页	Cloudflare 对员工、AI agents 与基础设施的零信任访问定位	具体 AAM task graph 在任意企业中的部署状态

这个边界也避免把“sender-constrained”误译成万能防护。它针对的是“攻击者只窃取到 token”这一情形；如果 harness、proof key、任务调度、资源服务器或网络执行路径中的其他环节遭到破坏，仍需依靠独立控制与审计。短时和发送方约束降低某些凭证滥用面，并不替代最小权限配置、密钥保护、资源侧授权和事件响应。

从任务模板到网络出口，哪里最难验证

文章的可操作建议是从一个触及系统记录的边界明确任务开始，例如夜间对账、日志分诊或拉取请求机器人。企业若尝试采用该思路，首先应把“任务允许做什么”写成可执行模板，而非仅放在提示词或开发文档里。模板需要能标注具体操作、资源、租户、收件人与有效期，并在任务派发时与发起人的真实权限求交集。

第二个验证点是“冻结请求表示”是否真的发生。若策略检查的是“读取某张表”，但实际执行时适配器能更换表名、租户、导出目的地或收件人，任务范围就会在检查后漂移。原文要求适配器构造并冻结完整请求，再授权并执行相同表示；这是对 tool calling 里参数注入、间接提示注入和代理层重写的一种工程回应。不过，文章没有提供独立测试来说明所有适配器都能满足这一性质。

第三个验证点是网络旁路。模型进程、子进程、代理运行时和外部工具可能拥有不同的出网能力。若只管 MCP 或 API 工具调用，却没有将所有相关连接纳入网络执行点，一个被绕开的 socket 足以使资源限制失效。反过来，网络侧通常只能看到目的地和传输层属性；要判断业务级的租户或收件人，又需要 HTTP 层可见信息或可信终止点。因此，harness 与网络中介不是相互替代，而是应对不同旁路路径的两层控制。

最后是状态收紧后的旧工作如何停止。文章要求 Access Engine、harness 和网络共享任务身份、capability ceiling 与 Trust Ratchet 状态；受保护输入到达前，需要执行点确认新的状态版本，harness 才把数据交给模型。这个序列把“发现敏感数据后立即减少访问”具体化，但它也暴露出最难的分布式问题：旧请求、缓存凭证、长连接、异步队列和子任务在状态切换时如何被围栏、撤销或重新授权。原文将多人访问控制称为开放系统问题，正说明这一架构不是一篇文章即可封口的实现细节。

下一批证据应当是什么

Cloudflare 若要把该参考架构推进为可复用的工程路径，最有信息量的后续材料会是可部署的实现与失败边界，而非更抽象的原则重述。首先应关注 Identity Broker 如何同企业 IdP、RFC 8693 交换、DPoP proof key 和资源服务器衔接，并明确任务取消、超时、重试与子任务委托时凭证的行为。

其次应关注 AAM 的日志事件契约。原文列出任务图、任务模板、发起主体、当前 actor、执行组件、操作、请求与解析后的范围、资源或目的地、策略结果、Trust Ratchet 版本、结果和关联标识等字段。若这些字段能够公开并与 SIEM、MCP 和 OpenTelemetry 的既有数据模型对齐，企业才更容易判断一次模型调用、一次工具调用和一次出网请求是否属于同一受控任务。

多人协作仍是决定这套模型能否跨越演示的关键。一个人授权一个任务的链条相对清晰；共享工作区、异步队列、代理再委托、多人共同编辑数据和跨租户资源会带来多个主体、不同权限与不同撤权时点。Cloudflare 已将它称为开放问题，因此接下来应看具体实现如何呈现委托链、权限交集、冲突处理、撤权传播和审计归因，而不是把单主体示例直接外推为全部智能体工作流的答案。