Agent 继承用户权限，这套做法不够了

一个只运行十分钟的对账 Agent，兜里却揣着一把长期有效的 API Key。

任务结束了，Key 还活着。它可能留在环境变量里，也可能被写进日志，运气再差点，还会跟着一段报错被模型原样吐出来。

好家伙，人都下班了，工牌还挂在公司大门上。

8 月 5 日，Cloudflare 发布了一份叫 Agent Access Model 的访问控制模型，简称 AAM。同一天，他们还开源了 Cloudflare OS，一套给企业跑 Agent、生成应用、连接内部系统的工作平台。

如果只看发布列表，这很容易被归进又一个 Agent 平台加又一篇安全白皮书。可把两件事放在一起看，味道就不一样了。Cloudflare 真正想补的，不是聊天框，也不是再接几个 MCP，而是企业把 Agent 放进生产以后最容易被忽略的那层地基。

权限到底该怎么给。

我一直觉得，很多团队现在给 Agent 做权限控制，多少有点把实习生工牌塞给叉车，然后在车头贴一张纸，写着「请谨慎驾驶」。

用户能读哪些文档，Agent 就继承哪些文档权限。用户能访问生产数据库，Agent 也拿到同样的连接。再在 system prompt 里补几句「不要访问无关数据」「不要向外部发送敏感内容」。看起来身份有了，规则也写了，像是挺完整。

可问题在于，人类权限模型默认的使用者，是一个坐在设备前、按人的速度点击的人。Agent 不是。

人一天可能打开几十份文档，Agent 一分钟可以扫几千条记录。人的账号出现异常，风控还有时间弹窗、冻结、打电话。Agent 拿到数据库连接和公网出口，可能在异常检测完成一次采样前，就把表读完并 POST 到外部地址了。

Cloudflare 在原文里说得很直接，给人设计的控制拿去管 Agent，不会大声失败。它会安静地给太多权限、留下太少证据、信任太长时间。

这个判断我认。

眼下很多 Agent 安全讨论都盯着模型，提示注入怎么防，推理时怎么判断意图，危险动作要不要多问一句。模型当然要管，但 AAM 做了一个挺有意思的转向。它不把全部希望压在「让这次判断更聪明」上，而是先缩小能力范围，让需要判断的东西少一点。

一句 prompt 写着「不要访问生产环境」，它只是意图，不是边界。模型读到一份被人埋了恶意指令的工单，照样可能被带跑。真正的边界要落在 Agent 调用工具的运行框架里，也要落在所有出网流量必经的网络层里。

能靠几句话绕过去的，真不能算边界。

这也是为什么我看到 AAM 里那句「Do not trust the run」时，觉得有点子牛逼。零信任以前解决的是别因为请求来自内网就默认相信它，AAM 往前又推了一步，别因为任务在派发时通过授权，就相信它后面每一步都合理。

任务启动时的批准，不会自动传给下一个动作。每一次工具调用都要重新检查三件事，当前 Agent 是谁，它被授权做什么任务，这张任务执行图此前已经碰过哪些资源。

注意第三件事。

传统 RBAC，也就是基于角色的访问控制，擅长回答「这个账号能不能读这张表」。Agent 真正麻烦的问题却是「它刚刚读完这张表以后，还能不能访问那个外部地址」。单独看，读表可能合法，访问外部支持系统也可能合法。把两步接起来，数据外泄路径就出现了。

权限风险不是每一步单独相加，而是在路径里组合出来的。

AAM 给出的核心机制叫 Trust Ratchet，可以理解成信任棘轮。棘轮这种机械结构只允许向一个方向转，权限也是。任务一旦触碰被策略保护的数据，它剩下的能力只能缩小，不能在同一任务里重新长回来。

Cloudflare 的 Trust Ratchet 流程，受保护响应要等权限收紧后才会交给模型。

Cloudflare 用夜间对账 Agent 演示了这套东西。任务启动时，它可以从指定支付处理商获取报告，读取两张生产账本，在出现约定异常时联系供应商支持，再把摘要发到固定财务频道。这些都在十分钟的能力上限内。

报告取回来以后，系统发现它属于受保护数据。运行框架先把响应扣住，不让内容立刻进入模型，然后把任务从 Baseline 切到 Restricted。支付处理商和供应商支持两条路径被关闭，只保留两张账本的读取权限，以及一个固定格式、固定接收者的财务输出。

运行框架、访问引擎和网络执行点全部确认新状态以后，报告才交给模型。

厉害的地方不在于它识别出一段恶意 prompt，而在于它根本不需要赌模型能识别。

接下来，某条账本备注里真的藏了一句提示注入，要求把完整账户历史附到供应商支持工单。联系支持原本是合法动作，可棘轮已经把这项能力移除了。工具层拒绝调用，Agent 如果绕过工具直接连外网，网络层再拒绝一次。

两道门的失败方式还得尽量独立。运行框架有 bug，网络策略继续挡。网络配置出了错，运行框架也不该顺手放行。共享控制面只要超时、冲突或少了一个确认，默认就是不把敏感响应交给模型。

对账任务进入 Restricted 状态后，支持路径被关闭，只保留账本读取和固定财务输出。

坦率讲，这比在 prompt 里多写三遍「绝对不要泄露数据」靠谱多了。

棘轮还有个特别关键的时间顺序。权限必须先收紧，数据才能进入模型。要是模型已经看见完整报告，系统才慢悠悠关闭外网，那叫事后关门。Agent 以机器速度行动，几十毫秒就足够把敏感内容塞进下一次调用。

流式响应也不能偷懒。如果数据分类在返回前已经知道，先完成状态切换再开流。如果必须看内容才能分类，就先缓冲，等分类和权限收紧完成以后再放。旧连接要关，旧任务要取消，缓存的授权结果要清。

这块写起来很啰嗦，做起来也一定不轻。但安全工程最怕的恰恰是那种一句话讲完、实现时全靠默认值的方案。

AAM 还把凭据寿命拉回了任务本身。一个十分钟的任务，就拿一张不超过十分钟的凭据。凭据里不只是一个 service account 名字，还要表达 Agent X 正代表主体 H 执行任务 T。

现成标准能帮上一部分忙。OAuth 2.0 Token Exchange 可以把较宽的身份换成按 resource、audience 和 scope 收窄的 token，DPoP 可以把 token 绑定到运行框架持有的证明密钥。就算 token 泄露，攻击者没有那把证明密钥，也不能直接拿去重放。

模型不应该看到证明密钥，更不该自己保管它。完整请求也要在授权前冻结，操作、资源、会影响范围的参数、租户和接收者都包含在内。系统检查哪一份，适配器就原样执行哪一份，别检查时说读三行，真正跑的时候变成导出整表。

很多朋友可能会问，这跟 MCP 自带的授权有什么区别。

MCP 授权规范能建立客户端和远程工具服务之间的 OAuth 边界，却不会替你的业务定义「这次对账只能读 A、B、C 三张表」「读完受保护报告后不得再联系供应商」。逐工具、逐参数、逐任务状态的规则，仍然得由运行框架和工具服务器执行。

MCP 解决怎么连接，AAM 追问连上以后，每一步还剩多少权力。

说真的，这才是 Agent Harness，也就是让模型真正干活的那层运行脚手架最该承担的责任。一个运行框架如果只负责把 JSON 参数转发给工具，却不做权限检查、不冻结请求、不管网络出口，它更像一个方便的转接头，还没资格被叫作执行边界。

Cloudflare 把在线控制拆成身份代理、任务级访问引擎、中介层和信任棘轮，又配了活动日志与授权审查循环。名字不少，但思路是一根线。

别让 Agent 自己证明自己没干坏事。

活动日志要从外部执行点采集，记录谁发起了任务、当前执行者是谁、读了还是改了、碰了多少数据、哪条策略允许或拒绝、当时棘轮处于哪个版本。模型生成的行为总结可以当补充，不能当权威证据。攻击者既然能影响模型动作，当然也能影响模型怎么描述自己的动作。

身份代理、访问引擎、中介层和信任棘轮负责在线控制，日志与授权审查只改未来模板。

Cloudflare 同期发布的身份感知 AI Gateway把这个思路用在了模型流量上。每次请求绑定经过 Access 验证的用户身份，再按账号自己的历史建立动态基线。它看最近三十天的会话成本 p95，只有一次会话超过个人 p95 的两倍，同时又跨过组织级 p99 金额线，才进入异常提醒。

他们公开的内部样本里，大多数会话远低于 10 美元，p95 是 20 美元，p99 是 200 美元。一条固定阈值很容易误判，重度工程师多花 500 美元可能仍在正常范围，一个平时每次只花 5 美元的定时 Agent 突然花 50 美元，反而更可疑。

这套观察不会直接判断恶意，也不会自动封禁。它只是把偏离自己行为模式的账号推到管理员面前。身份和基线解决的是看见异常，AAM 的任务凭据、工具中介和网络出口负责真正拦动作，两个层次别混在一起。

权限自动优化也一样。某项授权在许多成功运行里从未使用，系统可以建议从未来的任务模板里删掉。某种拒绝反复伴随任务失败，也可以附上证据申请扩大。可反复请求不等于应该放行，攻击者也会反复撞门。修改必须有人审，且只能改未来任务，不能偷偷给正在跑的任务扩权。

这比每一步都弹人工确认更现实。

大家用过 Windows UAC，大概知道确认框太多会发生什么。人到头来不是更谨慎，而是形成条件反射，光速点允许。一个永远会被批准的弹窗，不是控制，是仪式。AAM 把人的注意力留给创建任务模板、修改权限，或者处理少数已经被策略明确标记的高风险动作。

已经被棘轮拿掉的权限，点确认也不能在原任务里恢复。真要继续，重新开一个授权清楚、隔离干净的新任务。

到这里，单用户场景勉强能画出一套工程图。多人共享 Agent 才是真正的硬骨头。

Cloudflare 在原文里举了一个明确标记为示例的场景。甲能看营收数据，乙不能。共享 Agent 在甲的权限下读过营收并生成一段总结，后来乙来问同一件事。缓存能不能复用？如果能，可能把甲的数据泄露给乙。如果所有回答都只能使用两个人共同拥有的权限，共享上下文又会被削得很弱。

这里最危险的一句话是「这不就是缓存吗」。不是，这是授权 bug。

每条检索结果、工具返回和缓存答案都得带着获取它时的权限与来源标签。数据进入模型上下文前检查一次，输出离开系统前再检查一次，还不能指望模型自己在生成过程中维护标签。相关研究 CI-Work 在模拟企业工作流里测到 15.8% 到 50.9% 的隐私违规率，最高泄漏 26.7%。

Cloudflare 也没有硬装已经解决。他们明确写道，目前不知道有哪套广泛部署的端到端系统把多人访问链条完整关上。AAM 当前能守住的边界，是派发前固定一份有效权限的一张任务执行图。共享 Agent 要么按用户隔离任务，要么只取所有人的共同权限，两种都要付成本。

我反而挺喜欢这种承认。Agent 行业现在最不缺的就是一张什么都能连的架构图，缺的是有人把「这里还没解」四个字写在图旁边。

如果你正在做 Agent，不需要明天就照着 AAM 重建公司权限系统。Cloudflare 自己给的起点很克制，挑一个边界清楚、会碰系统记录的任务，日志分诊、PR 机器人、夜间对账都行。

然后真做三件事。

把常驻 API Key 换成随任务过期的短时凭据。把工具调用放进能逐项授权的运行框架。把所有出网连接赶到可审计、可拒绝的网络出口。

活动日志开起来，先看真实任务到底用了哪些权限，再收模板。别一上来追求完美策略，先把永久工牌摘下来，把叉车开进有护栏的车道。

模型会越来越聪明，判断也会越来越像人。可再聪明的模型，都不该靠一句「请谨慎驾驶」获得整座仓库的钥匙。

任务只活十分钟，权限也该只活十分钟。

那把长期有效的 API Key，该收回来了。