三个月前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): PromiseResponse { 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 系统时逐项对照检查。对比维度传统 IAM 模型智能体访问模型 AAM授权单位人-系统二元关系单次动作-任务绑定信任基础登录后长期信任不信任运行动作级实时校验凭证生命周期长期有效人工回收短命凭证任务结束即作废应对组合攻击依赖事后审计发现信任棘轮单向收紧天然阻断审计粒度系统级操作日志每一次工具调用留痕对提示注入的防御无直接防御动作级校验注入也无法越权这张表里最扎眼的一行是最后一行。提示注入在传统模型里几乎无解因为模型一旦被注入指令就会用已有的合法权限执行恶意动作在 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 用的凭证要和人用的凭证分库管理。人登录走 SSOAgent 调用走任务凭证两套体系混在一起是事故高发区分开之后无论是审计还是吊销都干净得多排查问题时也能快速定位是哪一类主体干的。最后说一个判断AAM 不是银弹它解决的是授权问题解决不了模型本身的幻觉和误判也解决不了企业内部的政治性授权但信任从系统缩小到动作这个方向是确定性的它把 Agent 安全从玄学变成了工程从口号变成了代码。下一次再看到我们的 Agent 接入了企业微信、飞书、数据库这类标题时值得多问一句它的每一次动作有凭证吗有日志吗白名单写清楚了吗这三个问题比模型选型更能决定你晚上能不能睡好觉也更能决定这家公司敢不敢把核心业务交给 Agent。