先忘掉API密钥和会话令牌吧。在智能体（Agent）的世界里，它们是上个世纪的旧货。当一段代码可以替你预订机票、编写并运行另一段代码、跨越多层工具链自动决策，你手里攥着的那枚长期令牌就不再是安全锚，而是被撕开的信封。Cloudflare前几天丢出了一篇论文——《The Agent Access Model》，直指这个裂口。它拒绝修修补补，而是从零开始定义了一套叫做AAM的智能体访问控制模型，核心只有一句话：不信任运行。每一个动作，都在任务执行图上被实时审判，而审判的依据不再是“这个应用是谁”，而是“此刻这个智能体为谁、在什么任务上下文里、碰过了哪些资源”。这思路很野，也很对症。
智能体凭什么撕裂了旧安全模型
一次性执行者，不是持证公民
传统访问控制——无论是RBAC还是更细粒度的ABAC——骨子里都假设请求背后站着一个稳定主体：一个用户、一个服务账号、一台设备。这些主体有生命周期，有清晰的身份字段，可以慢慢核对。但智能体不一样。它是短暂的。一个编排器拉起一个子Agent，执行一次订票操作，然后销毁；下一次为另一个任务再生时，底层容器、PID甚至网络地址全变了。给这种“一次性执行者”派发长期证书，就像把家门钥匙交给每天换一张脸跑腿的陌生人。Cloudflare在AAM里直接釜底抽薪：授权不跟任何持久化的应用身份捆绑，而是绑在一张限时、限域、限定上下游的任务凭证上。你要做事，可以，先出示这张凭证，再验你当下这一步是否还活在上次批准的范围里。
提示词是透明玻璃，不是墙
第二个让安全人员失眠的问题是：提示词不是边界。很多团队误以为给Agent规定了“只能订机票，不能改航班”的系统提示词，就等于上了锁。事实刚好相反——提示词是一块透明玻璃，任何一道下游工具调用可能不经意间把你的全量数据暴露出去。AAM的设计里根本没有试图加固这层玻璃。它直接从执行动作下手。模型压进任务执行图里，不看你“被教导了什么”，只看你“当下正在调用的API和参数是否超出了当前任务图节点的预授权范围”。这等于说：就算提示词被绕开，动作层面的置信区间依然是闭合的。
机器速度与跨跳组合的暗雷
还有一个少有人谈的角度。Cloudflare把机器速度和跨跳组合权限列为智能体的原生特性，而不是安全威胁的附属品。智能体可以在几毫秒内完成几十步工具链调用，这种速度下，传统的“事后审计”完全失效。更隐蔽的是权限累加：单看读取邮件和一个webhook调用各自无害，但两者组合起来，就可以把敏感信息外溢。AAM的解法不是禁止组合，而是拒绝静态权限并集。它用信任棘轮把已接触资源写入授权上下文，每一步的权限视界都受前一步污染面收窄，而不是放宽。动得越快，收紧得越狠。
AAM是怎么把“不信任”变成操作系统的
任务凭证，不是身份令牌
AAM把传统OAuth式的bearer token一脚踢开。它定义了一种Task Credential，这张凭证上不写“我代表用户X”，而是写“我属于任务T，当前可执行的动作集为A，节点路径为P，有效时间窗为W”。授权服务每次收到动作请求，不去数据库查你是谁，而是校验这张凭证是否尚未过期、是否与执行图节点一致，以及——最关键的一条——自从任务启动起，这个Agent已经触碰过的所有资源是否已经触发了某个收缩条件。这相当于把凭证从静态身份证明变成了带时间衰减和路径压缩的动态载荷。哪怕同一任务下的两个动作，凭证所代表的可信区间都可能在下一个tick瞬间变化。
缩小能力集，比单次决策优化更根本
大多数Agent安全讨论聚焦在“如何让模型不做危险决策”，拼命优化对齐。AAM论文的策略是扭头往另一个方向跑：直接把Agent的能力集砍掉。不是让Agent学会不动刀子，而是把整把刀收走，只留一把限重限长的削皮器。在架构上，这表现为任务定义时就要写出最小动作图，授权引擎再把这张图里每个节点的允许能力具象化。Agent不是被要求“自已判断是否安全”，而是根本看不到越界选项。这一刀切下去，省掉了大量猜测和对齐税。Cloudflare把这个思路叫做“缩小能力集而非仅优化单次决策”，读起来像安全工程里久违的减法美学。
信任棘轮：只紧不松的授权逻辑
棘轮是一种只能单向转动的齿轮，AAM里的信任棘轮也是如此。每次动作成功后，模型并不刷新一个恒定权限，而是把本次调用所触及的数据、通道、端点标记为“污染面”，并写入上下文的不可变记录。后续动作的授权查询必须带上这层污染面，授权引擎会判断：如果上一跳已接触到财务数据，下一跳就不允许再访问外部API，哪怕这个API本身权限列表里有它。这就形成了一种级联收窄的效应。智能体越深入执行，它所能触碰的世界反而越来越小。它不是防火墙，不是护栏，而是物理上限制了行为半径，这让“不信任运行”从口号变成了可执行的授权闭环。
当Agent不再只是你一个人的工具
单主体控制已经不够用了
AAM还碰了一个更麻烦的硬骨头：多人访问控制。之前的讨论大多假设一个智能体只服务一个用户，但现实场景里，一个任务很可能要融合多个人的数据——比如一个会议记录Agent要读取参会者的日程和邮箱，结果是决策权分散、利益冲突。传统的访问控制在这里彻底失语，因为ABAC只能判定“用户A是否可访问资源R”，但没法回答“当用户A和用户B的资源混合在一起，智能体该听谁的”。AAM区分了两种范式：单主体控制，和需要解决多方低信任协作的多人模式。后一种场景下，它建议把任务凭证拆成多个委托人签名片断，任何一侧都可以提前撤回自己的片断，导致整体凭证失效。等于把“我可以停止你的权力”内建进了协议本身。
冲突不靠仲裁，靠可撤销结构
最妙的一点是，AAM不试图设计一套智能仲裁逻辑去判断多个用户意愿的优先级。它回避了那个天坑。取而代之的是一个冰冷但干净的结构：每个人持有独立撤销权，且撤销不需要解释。这意味着如果一个智能体在帮两个人协调行程，其中一位随时可以触发撤销片段，终结整个任务线的权限，不留任何灰色地带。这是一种把社会信任问题降级为个体开关的工程化思路。它没有解决所有冲突，却给了每一方随时离场的按钮，而安全系统只需要保证按钮有效。这对于多人协同的智能体场景来说，也许比任何复杂的仲裁机制都更贴近真实需求。
AAM当然不是银弹。它要求你把每个任务的执行图提前定义清楚，这对某些开放式推理Agent来说本身就是一种桎梏。但它指出了方向：智能体安全不能再靠守卫大门，而得把每一道门换成只能单向通过、随时间自动变窄的通道。下次你的Agent自动调了一个api，想想它背后真正持有的权限是什么——是你给的令牌，还是任务此刻本该拥有的、而且已经被前一步污染面挤压过的最小动作权。两者之间的鸿沟，就是AAM想要填的。
