正在加载，请稍候
2026 年 8 月 Cloudflare 发布 Agent Access Model 白皮书，拆解企业智能体安全部署的 4 条工程基线：不信任运行、身份绑定、行为异常检测、最小能力集。
2026 年 8 月 5 日，Cloudflare 在 Agents Week 期间发布了 Agent Access Model（AAM）白皮书，作者 Matt Silverlock 用 26 分钟阅读时长的篇幅论证了一个核心判断：我们为人类设计的访问控制模型，在智能体面前正在"安静地失效"——不是拒绝请求，而是悄悄放行了不该放行的东西。关于 AI Agent 平台搭建的整体工程路线，可先参考我们之前的 从单点 Agent 到硅基团队的工程路线图。本篇聚焦安全架构，逐条拆解 Cloudflare AAM 的 4 条工程基线。
过去十二年企业安全的主线是从"信任网络"走向"信任身份"。Google BeyondCorp 奠定了 Zero Trust 的范式：请求来自内网还是公网不重要，用户身份加设备健康度才是授权依据。这套逻辑在以人为操作主体的场景下运转良好——一个人每天登录一两次，操作速度有限，访问决策量可控。
智能体不是人。一个任务级执行实例在几分钟内可能发出上百次 API 调用，跨越数个系统，吞吐量远超人类操作员。AAM 白皮书指出，传统访问控制的三个默认假设——主体稳定、操作可审计、权限边界清晰——在智能化理场景下全部被打破：这类软件主体是短暂的（task-scoped），同一服务在不同时刻可能以不同身份执行不同任务，而"登录一次、信任整个 session"的模型对此毫无感知。
AAM 的解法不是把每次访问决策做得更"聪明"，而是反其道而行：先把执行单元的能力范围压到最小，再在这个窄窗口里做精确授权。以下四条基线，就是这套思路的工程化拆解。
传统模型在请求入口做一次验证（authenticate → authorize → let it run）。AAM 把这个逻辑推到任务执行图（task execution graph）的每一个节点：每当执行单元发起一个子动作，系统都要重新评估"当前这个动作是否仍应被允许"。
工程实现要点：
适合场景：需要跨多个内部系统（数据库→API→文件存储）串联操作的生产环境。
不适合场景：纯只读查询类任务，每一步都做完整验证的延迟开销可能不值得——此时更适合用基线四（最小能力集）兜底。
典型误用：团队把"实时授权"等同于"每次调大模型 API 前验一次 token"——这只是在验证调用者的身份，不是在验证它正在做的动作是否应该被允许。两者区别在于：前者回答"你是谁"，后者回答"你凭什么在这个时刻做这件事"。
这是最容易理解、也最容易被绕过的规则。AAM 要求每个 API 请求携带经 Cloudflare Access（或等价 IdP）验证的用户身份，智能体自身的 service account 不享有任何独立权限。换言之，它能做什么完全取决于"此刻操作它的那个人能做什么"。
这条基线直接封死了企业部署中最常见的一类漏洞：执行实例用高权限 service account 运行，终端用户通过它间接获得了自己本不该有的系统访问权。
工程实现要点：
sub 字段，按用户的 RBAC 角色做授权——走跟人类操作完全相同的策略路径。适合场景：替员工操作内部系统——比如 HR 智能体替你提交请假审批、DevOps 类任务替你触发部署流水线。
不适合场景：系统级自动化（如凌晨数据库备份）没有"当前人类用户"可绑定。此时需退化到基线四（最小能力集 + 严格限时 token）。
典型误用：给执行单元一个"超级管理员"用户身份来绑定，然后说"已经做了身份绑定"。这在审计意义上等于没做——操作日志上显示"admin 做了 X"，但分不清是哪个真实人类触发的。
AAM 白皮书提出基于账户近 30 天会话成本的 p95 百分位建立行为基线，任何会话成本超过基线 2 倍即标记为可疑。这是四条中最"数据驱动"的一条，也是工程门槛最高的。
Cloudflare 在同期发布的 Identity-Aware AI Gateway（已进入 open beta）中实现了这套检测逻辑：不止监控 token 消耗量，还追踪访问的内部系统范围、API 调用时序模式、输出数据量等维度，构成多维行为画像。
工程实现要点：
适合场景：已有多位员工在日常使用智能体的中大型团队——有足够流量建立统计基线。
不适合场景：日 session 量 < 10 的早期团队。此时统计基线不可靠，容易大量误报，建议先用硬限额（hard cap）替代。
典型误用：把异常检测等同于"看 token 花了多少钱"。Token 超量只是现象不是根因——一个被 prompt injection 诱导去扫全量数据库的任务，token 消耗可能完全正常（因为每行都是合法查询），但输出数据量会异常飙升。正如 Anthropic Claude 安全事件复盘 所示，智能体的攻击路径往往不是暴力破解，而是诱导式越权——攻击者不需要"攻破"系统，只需要让模型"愿意"做不该做的事。只看成本会漏掉这类攻击。
这是四条中最朴素、也最有效的一条。AAM 的核心哲学是：与其让每次访问决策更聪明，不如让执行单元的能力本身就小——小了，就不需要那么复杂的判断。
"最小能力集"不是传统 RBAC 的翻版。RBAC 回答"这个角色能做什么"，最小能力集回答"这个具体的任务实例能做什么"。一个服务可能被授权调用 5 个工具，但当它执行"帮用户查最近的订单状态"时，只需要一个查询接口——不需要修改、不需要删除、甚至不需要看到其他用户的订单。
工程实现要点：
适合场景：所有场景都适用。这是四条基线中唯一没有"不适合场景"的——最小能力集在任何阶段都应该做，且做得越细越好。
典型误用：把"最小能力集"做成了"开发环境只读、生产环境全开"这种粗粒度开关。真正的细粒度应该到"这个任务可以 query orders 表，但只能查最近 7 天、且只能查当前用户的订单"。
| 基线 | 当前可落地程度 | 阻塞点 |
|---|---|---|
| 不信任运行 | 中等——需要框架支持 DAG 级策略注入 | LangGraph / CrewAI 目前无原生策略钩子；需自建中间件层。关于不同框架在工程约束下的差异，可参考 AI Agent 开发三大流派 的详细对比。 |
| 身份绑定 | 高——OAuth2 + JWT 方案成熟 | 组织需先完成内部 IdP 统一（非技术问题） |
| 行为异常检测 | 低——多维基线建设成本高 | 需要至少 30 天历史数据 + 专用分析管道 |
| 最小能力集 | 高——工具白名单 + 动态 token 可立即实施 | 需要团队有按任务拆分权限的 discipline |
AAM 目前仍处于早期阶段。Cloudflare 自己在 8 月 5 日同一天发布的 Cloudflare OS 和 内部实践经验 表明，即使在其内部，完整落地也依赖多个组件协同——Access、AI Gateway、Workers、MCP Portal、WriteGuard——缺一环就留下盲区。
对国内企业而言，AAM 的设计思路（尤其是身份绑定 + 最小能力集两条）可以立刻借鉴，但需注意两点本土适配：① Cloudflare Access 依赖其全球网络，国内部署需替换为自建 IdP（如阿里云 RAM / 微信企业身份）+ 自建策略引擎；② 数据驻留要求下，行为异常检测的基线数据不能出境，需在境内独立建设监控管道。即便如此，四条基线的架构思想是跨平台通用的——不是因为 Cloudflare 做了什么，而是因为这四条回答的都是智能体安全的本质问题。
RBAC 是静态的、粗粒度的——"张三是开发者角色，所以可以访问代码仓库"。AAM 是动态的、任务粒度的——"张三通过智能体发起的这次部署，只能在 staging 环境执行、只能操作 frontend 目录、有效期 10 分钟"。AAM 不替代 RBAC，而是在其上叠加一层任务级收缩。
需要，但不用一次性建完四条。优先落地基线二（身份绑定）和基线四（最小能力集），这两条不需要大量历史数据，开发成本可控，且能防住 80% 以上的越权场景。基线和行为检测可以在日活 > 50 后再建。
会，但这是有意为之的摩擦。AAM 的设计哲学就是"用安全摩擦换可控性"——每次新增一个能力，都应该经过一次明确的授权声明。实际工程中可以在开发 / 测试环境放宽约束，生产环境严格执行，通过 CI/CD 流水线中的权限检查防止"忘了收紧"。
目前（2026 年 8 月）国内云厂商还没有发布直接对标 AAM 的产品。但阿里云 RAM + 函数计算的临时 token、腾讯云 CAM 的细粒度策略，都可以作为自建策略引擎的底层组件。关键在上层需要一套面向任务粒度的授权框架——目前这部分只能自建。
理解四条基线是第一步。对于已经在做 AI Agent 平台搭建的团队，更大的挑战在于：如何把这些安全基线嵌入日常开发流程，而不是作为"上线前的最后一次检查"。我们自己在交付企业级平台时踩过的坑包括：LLM 的 function calling 天然倾向于调用它能看到的所有工具（所以白名单必须在框架层强制，不能靠 prompt 约束）、JWT 在多跳调用链中容易丢失（需要在框架中做 context propagation 而不是每次重新签发）、以及——最容易忽略的——输出也需要跟输入一样做权限过滤。这些工程细节在 GPT-5.6 入侵 Hugging Face 事件的技术复盘 中有更具体的攻击面分析——安全威胁不是假想敌，而是已经在发生的现实。
蓝曜炬辉在 Agent 平台搭建的工程实践中，将上述基线沉淀为一套可复用的安全中间件——包括任务级权限引擎、用户身份透传层和会话成本异常监控。如果你的团队正在评估平台安全架构方案，可以查看我们的 Agent 平台搭建案例 或通过 联系我们 与工程师直接交流。