Cloudflare 开源 Cloudflare OS：智能体访问模型 AAM 把「信任」从系统缩小到一次动作

三个月前，Cloudflare 的销售团队自己动手用 AI 搭了一个超级应用：把报价生成、合同起草、CRM 录入、审批跟进全部串进同一条工作流，业务员只需要对着对话框说一句"给这家客户做一份新报价"，应用就会自动完成后续所有环节，从查价格表到起草条款再到写入系统，全程不需要人工干预。

等到 IT 部门发现这件事的时候，这个应用已经被全公司几千名员工日常使用，甚至没有人能说清楚它到底碰过哪些内部系统，也没有人知道它的权限边界画在哪里。它就像一株在无人知晓的角落长起来的植物，等被人看见时，根系已经伸进了好几块土壤。

这听起来像是一个美好的效率故事，直到有人问了一个让所有人都沉默的问题：这个 AI 应用能读写合同系统，它凭什么？它的权限是谁给的？它执行的每一步操作，有没有人验证过该不该做？当时没有人能回答，因为传统权限体系里根本找不到这些问题的坐标。

8 月 5 日，Cloudflare 把内部这套经过实战检验的东西正式开源为 Cloudflare OS，同一天发布论文《The Agent Access Model》，提出了一套面向 AI 智能体的访问控制模型 AAM。这不是一次普通的开源，它把 Agent 安全的讨论从提示词对抗直接拉进了系统层治理的战场，值得每一个做 Agent 的人认真读一遍。

要理解 AAM 为什么出现，先看传统权限模型为什么失灵。过去二十年，企业权限体系的核心假设是：执行者是确定的人。人登录系统，系统分配角色，角色绑定权限，每一次敏感操作都留下操作者姓名，出了问题可以定位到具体的人。

这个模型在人类员工时代运转良好，因为人可以培训、可以追责、可以记住规则，人的行为天然受到社会规范的约束。但 Agent 时代把第一个假设直接击碎：执行者变成了模型，它没有身份焦虑，不会因为昨天刚被警告过就收敛行为，也不会主动判断这件事超出我的职责范围。

模型只会沿着任务指令执行，直到完成或者被硬性阻断。它不会觉得哪个操作不合适，不会因为权限太大而感到不安，更不会在深夜反思自己今天的行为。指望模型自律，等于把安全建立在概率之上，而安全工程最忌讳的就是概率。

论文把 Agent 与传统执行者的差异归纳为四个特性，第一个是短暂性。Agent 的会话、任务、运行环境都是临时存在的，任务结束一切消散，这意味着昨天为某个任务签发的凭证，今天可能没有任何主体认领，它变成一把悬空的钥匙，谁捡到谁用。

第二个特性是机器速度。人类点击一次授权按钮需要几秒钟，而 Agent 一秒钟可以发起几十次请求。如果沿用每次操作都要人工审批的老路，审批队列会瞬间被淹没，业务直接停摆；如果跳过审批，又回到了没有任何防护的裸奔状态，两条路都走不通。

第三个特性是提示词非边界。很多人以为在系统提示词里写"不要访问财务系统"就安全了，但提示词只是模型的行为建议，不是安全边界。越狱、提示注入、工具返回内容里隐藏的指令，都可能让模型做出提示词明确禁止的动作，而且这些攻击手段还在不断进化。

第四个特性是跨跳组合权限，这是最隐蔽也最危险的一个。一个任务往往要依次调用数据库、代码仓库、邮件服务三个工具，每个工具都按最小必要分配了独立权限，但三个权限组合起来，可能形成一条越过所有边界的通路。

举个具体的例子：从只读数据库里读到内部文档，再借邮件服务的权限把文档发给外部地址，每一步单独看都合规，整体却完全失控。这就是组合攻击，它不攻破任何单一防线，而是把多个合法权限拼接成一条非法通路，传统审计事后都很难发现。

AAM 的核心规则只有一句话：不信任运行，每个动作都在执行的那一刻实时校验，而不是在任务开始时一次性授权。信任不再是静态的、授予之后就长期有效的东西，而是每一次动作都要重新证明的东西，任何一次证明失败都会立即中断执行。

校验的依据是三个维度：智能体身份、授权任务、已触达资源。身份回答谁在执行，任务回答它被授权做什么，已触达资源回答它这一路已经碰过什么，三个维度共同决定当前这个动作是放行还是拒绝，缺一个维度都不做决定。

这是 AAM 与传统模型最本质的区别：信任边界从应用缩小到了单次动作。传统模型里，权限绑定在应用和系统之间，应用拿到权限后做什么都行；AAM 里，权限绑定在动作上，应用本身不再拥有任何长期有效的权限，每次调用都是独立的裁决。

为了让每个动作实时校验能够落地，AAM 引入了任务执行图的概念。Agent 的一次任务被拆解成一张图，图的每个节点是一次工具调用或资源访问，每条边是动作之间的依赖关系，授权不是对着整张图做一次判断，而是每个节点到达时单独判断，互不影响。

任务执行图带来的一个直接好处是故障隔离：图中任何一个节点的授权失败，只会中断这条分支，不会连累整张图的其他部分。更关键的是，这张图本身就是审计的骨架，事后复盘时顺着图走一遍，Agent 的每一步行动都清清楚楚。

支撑动作级授权的第一件工具是任务范围凭证。任务启动时签发一张短命凭证，凭证里写死这个任务允许调用哪些工具、访问哪些路径、读取哪些资源，任务结束凭证立即作废，不进入任何长期存储，也不可续期，更不可能被别的任务复用。

凭证的设计遵循最小必要原则，只给当前阶段够用的权限，不给整个任务全周期的权限。这样即使凭证在任务中途泄漏，攻击者拿到的也只是当前阶段这一小片权限，而不是整个任务的全部权限，损失被限制在最小范围。

第二件工具是信任棘轮。直觉上任务越深入，Agent 应该获得越多信任，AAM 反其道而行，权限随任务进展单向收紧。每完成一个阶段，凭证里的可用范围就缩小一圈，直到任务结束时权限归零，中途被劫持也拿不到越来越大的权限。

信任棘轮这个名字取得很形象：棘轮只能向前转，不能倒退。权限也一样，只能随任务推进而收缩，不能因为任务需要临时扩张。任何需要扩张权限的请求，都必须重新走一遍完整的授权流程，而不是在现有凭证上加一行。

光有模型和论文还不够，Cloudflare OS 把 AAM 落成了可部署的工程实现。权限的执行者是 Gatekeeper，每一个内部服务一个实例，Agent 想调用任何服务，请求必须穿过对应服务的 Gatekeeper，否则直接拒绝，没有第二条路可走。

Gatekeeper 的工作只有三件事：校验任务凭证是否有效、检查本次请求路径是否命中凭证白名单、把每次放行和拒绝都写入审计日志。它不做任何智能判断，只做确定性的规则匹配，因为安全机制越简单越可靠，越复杂越容易出漏洞。

资源观察日志是 AAM 里被低估的一环。每一次放行都留痕，事后可以完整复盘一个 Agent 从任务开始到结束碰过哪些系统、读过哪些数据、做过哪些变更，没有日志的授权体系等于裸奔，因为出了事你连追责的入口都没有。

这里要特别说清楚 Gatekeeper 和 MCP 的关系。MCP 协议解决的是 Agent 能调用什么工具，Gatekeeper 解决的是这次允不允许调用，协议和能力描述归 MCP，策略和授权归 Gatekeeper，两者严格分离，互不越界，各管一摊。

这种分离是刻意的架构选择：MCP 是生态标准，应该保持通用；授权是企业策略，应该保持私有。把两者耦合在一起，要么生态被企业策略绑架，要么企业策略被生态标准稀释，两头都不讨好。

下面这段代码是 Gatekeeper 的最小实现，跑在 Cloudflare Workers 上，可以直接部署到自己的账户里实验。它做的事情严格限定为三件：解析任务凭证、校验请求路径、写审计日志，没有任何多余的分支。

// Gatekeeper: 每个服务一个实例，拦截 Agent 的每一次工具调用 export default { async fetch(request: Request, env: Env): Promise<Response> { const taskToken = request.headers.get('x-task-token'); if (!taskToken) return new Response('missing task token', { status: 401 }); // 1. 解析任务范围凭证：里面写死允许的动作 const scope = await env.KV.get(`task:${taskToken}`, 'json'); if (!scope) return new Response('task expired', { status: 403 }); // 2. 动作级校验：请求路径必须命中白名单 const path = new URL(request.url).pathname; if (!scope.allowedPaths.some(p => path.startsWith(p))) { await env.AUDIT.put(crypto.randomUUID(), JSON.stringify({ task: taskToken, path, decision: 'deny', ts: Date.now() })); return new Response('path not in task scope', { status: 403 }); } // 3. 放行并写审计日志 await env.AUDIT.put(crypto.randomUUID(), JSON.stringify({ task: taskToken, path, decision: 'allow', ts: Date.now() })); return env.UPSTREAM.fetch(request); } }

这段代码只有三十行左右，但已经把 AAM 的三个核心机制都装进去了：凭证不存在就直接拒绝，路径不在白名单就拒绝并记录，放行也要写日志。把它挂到任意上游服务前面，一个受保护的工具就诞生了。

注意一个容易被忽略的设计：deny 和 allow 都写日志。很多团队只记录拒绝，不记录放行，结果复盘时只能看到 Agent 被拦了几次，看不到 Agent 到底干了什么，AAM 要求双向留痕，放行日志才是事后审计的主料。

凭证里存什么也很有讲究。示例里只存了 allowedPaths 一个字段，实际生产里还要存任务 ID、签发时间、过期时间、允许调用的上游主机名，凭证本身要短命，示例里 KV 的键就是任务令牌本身，任务结束删键，凭证立即失效。

再看 Cloudflare OS 这个平台本身。它不是又一个聊天机器人界面，而是一个可部署的 AI 工作区：每个员工拥有一个基于公司上下文和技能库的智能体工作区，可以创建自己的微型应用，应用自带隔离数据库、实时能力和访问控制，全程零信任默认。

平台的底座是 Cloudflare 已有的基础设施：Workers 提供隔离运行时，Access 提供零信任身份验证，AI Gateway 统一管理模型调用和成本，MCP Portals 把内部工具以 MCP 协议暴露给 Agent，这些组件在 Cloudflare OS 之前各自独立存在，OS 把它们编排成了一个整体。

Gatekeeper 就插在 Agent 和每个内部服务之间。Cloudflare 官方文档里的表述很直接：Gatekeepers 把每个 Agent 的访问范围收缩到用户本来就能看到的东西，并附带完整的审计、成本控制和模型选择能力，权限只减不增。

最值得品的是 Cloudflare OS 的五项设计原则，其中有一条是宪法级别的：权限不因 AI 扩大。员工能看什么，他的 Agent 最多也能看什么，AI 永远不会获得比人类操作者更大的权限，这条原则把整件事的天花板定死了，后面所有机制都是它的展开。

另一条原则是人负责输出。Agent 可以起草、可以执行、可以归档，但最终对外发布和关键决策的确认权留在人手里，这不是保守，而是把责任边界画清楚：机器负责效率，人负责责任，出了问题知道找谁。

还有一个原则值得单独说：面向工程师和非工程师同样提供支持。销售、市场、财务的人不需要写代码，用自然语言就能构建自己的 micro-app，工程师则可以直接写 Workers、自定义 Gatekeeper 策略，两拨人共用同一套安全底座。

这些原则不是纸上谈兵。Cloudflare 内部这个平台已经被数千名员工日常使用，覆盖工程、销售、IT、财务各个职能，是从真实业务里长出来的系统，而不是为了开源临时拼凑的演示品，每一个机制都经过了真实业务的检验。

开源方式也很有 Cloudflare 风格：整个平台部署到你自己的 Cloudflare 账户里，Access 策略、AI Gateway 配置、Gatekeeper 规则全部由你掌控。你的术语、你的系统、你的策略，平台不碰你的数据边界，数据始终留在你自己的账户内。

用一张表把传统权限模型和 AAM 放在一起对比，差异会非常直观，也方便你在设计自己的 Agent 系统时逐项对照检查。

这张表里最扎眼的一行是最后一行。提示注入在传统模型里几乎无解，因为模型一旦被注入指令，就会用已有的合法权限执行恶意动作；在 AAM 里，注入只能改变模型的意图，改变不了凭证里的白名单，动作级校验让越权请求在边界上就被挡下。

这也解释了为什么论文强调缩小能力集而不是优化单次决策。单次决策做得再聪明，也只是在概率上减少错误；把能力集物理缩小，错误根本没有发生的空间，确定性优于概率，这是安全工程的老原则，AAM 只是把它重新用在了 Agent 身上。

论文还专门讨论了单主体控制与多人访问控制的差异。单个 Agent 的授权相对简单，复杂的是多个用户共享一个 Agent、一个 Agent 服务多个用户时，权限必须跟着调用者走，而不是跟着 Agent 走，这个场景里 Agent 只是执行壳，权限主体始终是背后的人。

如果你正在搭建自己的 Agent 平台，AAM 给出的不是理论，而是一份可以照抄的检查清单。第一条：你的 Agent 拿到的每一个凭证，是否绑定了具体任务？如果 API key 是长期有效的、全平台通用的，你已经在裸奔，只是还没出事，出事的概率每天都在增长。

一个常见的反例是很多 Agent 框架为了开发方便，把完整的 API key 直接交给模型，让模型在工具调用时自己携带。开发时确实快，但生产环境里这就是跨跳组合权限的温床：模型拿到的是整个系统的钥匙，而不是一个任务的钥匙，一次泄漏等于全盘失守。

最小改动方案是把工具调用层包一层 scope 校验，就像上面 Gatekeeper 示例做的那样。不改模型、不改工具，只在请求入口加一道校验和审计，这道薄薄的中间层，就是传统体系到 AAM 的第一步迁移，成本低到几乎可以忽略。

凭证设计有三个铁律：短命、任务绑定、单跳有效。短命保证泄漏窗口小，任务绑定保证权限不扩散，单跳有效保证即使一个工具被攻破，攻击者也不能拿这个凭证去调用下一个工具，三道保险缺一不可。

审计要先行。很多团队的顺序搞反了：先开权限，后补日志，正确的顺序是先有日志管道，再开放任何权限，因为权限一旦放开，你没有日志就永远无法知道 Agent 到底做了什么，出问题只能靠猜，而靠猜的复盘等于没有复盘。

好消息是 Cloudflare OS 开源意味着你不用从零造轮子。部署到自己的 Cloudflare 账户，接上 Access 策略和 AI Gateway，再把内部工具通过 MCP Portals 暴露出来，一个带动作级授权的工作区几个小时就能跑起来，比自己造一套省几个月。

如果你的工具栈不在 Cloudflare 上，AAM 的思想依然可以直接借用：把每个 Agent 任务当成一个临时的最小权限主体，把每次工具调用当成一次需要单独授权的动作，把每次放行写进日志，这套思想与具体平台无关，哪里都能落地。

把视角拉远，看这次开源释放的行业信号。过去两年 Agent 安全的主流讨论集中在提示词层面：怎么防止越狱、怎么清洗注入、怎么让模型拒绝危险请求，这些讨论默认了一个前提——模型是唯一的防线，模型守住了就安全了。

Cloudflare OS 和 AAM 的出现，把讨论的坐标从模型内部移到了系统外部。模型仍然可能被诱导、被欺骗、被注入，但只要动作级校验在，模型的一切异常意图都落不到真实系统上，防线从模型自律变成了系统强制，安全不再依赖模型的自觉。

这个转变的意义在于它改变了安全问题的归因方式。以前 Agent 闯祸，复盘结论往往是模型不够聪明；现在有了 AAM，闯祸意味着授权体系有洞，后者是可修的工程问题，前者是无解的哲学问题，工程问题至少还有解。

从商业上看，谁先受益也清晰：内部知识密集、工具链复杂、合规压力大的企业最先受益。金融、医疗、政务这类行业对每一次数据访问都要交代去向，动作级审计正好满足这种诉求，Agent 才敢真正进入核心业务流程，而不是永远停留在边角料任务。

反过来，把 Agent 当聊天框直接接入生产系统、又没做动作级授权的团队，风险敞口在快速变大。因为 Agent 的能力在涨，调用链在变长，而权限体系纹丝不动，这条裂缝会越来越宽，直到某一次事故把它撕开。

对独立开发者和中小团队，我的建议是从自己的 MCP 服务器开始改造：把每个 MCP 工具的调用入口加上凭证校验和审计日志，先让工具链里最敏感的那几个服务穿上甲，再逐步推广到全部，一次一个服务，不贪多。

还有一个容易被忽视的实操点：给 Agent 用的凭证要和人用的凭证分库管理。人登录走 SSO，Agent 调用走任务凭证，两套体系混在一起是事故高发区，分开之后无论是审计还是吊销都干净得多，排查问题时也能快速定位是哪一类主体干的。

最后说一个判断：AAM 不是银弹，它解决的是授权问题，解决不了模型本身的幻觉和误判，也解决不了企业内部的政治性授权，但信任从系统缩小到动作这个方向是确定性的，它把 Agent 安全从玄学变成了工程，从口号变成了代码。

下一次再看到我们的 Agent 接入了企业微信、飞书、数据库这类标题时，值得多问一句：它的每一次动作，有凭证吗？有日志吗？白名单写清楚了吗？这三个问题，比模型选型更能决定你晚上能不能睡好觉，也更能决定这家公司敢不敢把核心业务交给 Agent。