欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

Cloudflare开源Agent平台 权限跟着数据走

4 天前 智能体Cloudflare权限治理MCP开源

Cloudflare开源Agent平台 权限跟着数据走

Cloudflare OS企业Agent工作台场景

企业在内部推 AI 助手，第一步通常是找 IT 要 API key。这个动作看起来平常，却是后面所有麻烦的起点：key 的权限粒度太粗，一个 key 能读整个 GitHub 账号或者整个数据库，而且发出去就收不回来，审计日志里只能看到"谁调了接口"，看不到"谁看了什么数据"。

后来 MCP 出现，凭证不用再交给 agent 了。MCP server 自己持有凭据，只暴露一组定义好的工具，这解决了"key 被滥用"的一半问题。但 Cloudflare 在 8 月 5 日开源 Cloudflare OS 时，把另一半问题摆到了台面上：MCP 只告诉你 agent 能调用哪些工具，不告诉你 agent 观察到了哪些底层资源。工具权限和数据权限是两回事。

分享工作区时暴露的问题

Cloudflare OS 不是从零设计的。今年 5 月，Cloudflare 给全公司每个人发了一个内部版本，几千人每天都在用，很多是工程以外的同事。第一版跑下来，团队发现了一个此前没料到的坑：一旦 workspace、app、输出开始互相分享，MCP 的工具权限模型就不够用了。

一个 agent 读了数据仓库里的敏感表，然后用它生成一个实时 dashboard 分享给同事。MCP 层面看，这次访问完全合规——agent 有权限调用查询工具。但看 dashboard 的人，未必有权限读原始表。分享行为本身成了数据泄露通道。

权限跟着数据走

开源版 Cloudflare OS 的整个安全模型，就是围绕这个问题重写的。核心思路可以概括成一句：授权必须考虑数据接下来要去哪。

具体机制分三层。第一层，agent 默认零权限，连外网都出不去——服务端代码跑在禁用了全局出站网络的 Dynamic Worker 里，客户端代码跑在浏览器沙箱里。agent 想要访问某个资源，需要显式申请，管理员批准后，生成的代码拿到的是一个 typed binding，比如 env.PROJECT。这是个 capability 对象，代表"在特定策略下使用特定资源的权限"，凭证本身始终和 agent、和生成的代码隔离。

权限模型对比：工具权限 vs 数据权限

第二层是 Gatekeeper。它是个服务专属的 Worker，夹在 Cloudflare OS 和外部服务之间，理解那个服务的 API 和资源模型，持有 OAuth 凭证，负责执行策略、记录读取行为、审批有外部副作用的操作。给 agent 整个 GitHub 账号的权限太宽，Gatekeeper 可以只给单个仓库、只读 issue 不读源码、屏蔽特定字段、加限流、合并 PR 前要求人工审批。agent 和它生成的 app 看到的只是一个很小的 TypeScript API。

第三层是观察日志。Cloudflare OS 会记录 agent 观察到的每一个资源，这些记录跟着 agent 和它的产出走。别人打开这个 workspace 或者看它生成的 dashboard 时，Gatekeeper 会重新校验这个人对原始资源的访问权限。更进一步的策略是：读到了敏感数据，就禁止 agent 向外部写数据、邀请协作者、把任务转给别的 agent、发出站请求。数据一旦被读过，它的去向就被纳入了授权判断。

平台化的代价

这套模型的工程成本不低。每个外部服务都要写一个专属 Gatekeeper，理解它的 API 和资源模型——企业内部系统五花八门，这是个持续的维护工作。观察日志要记录每次资源读取，对高频调用的场景是额外开销。权限审批流程变多，用户每次要让 agent 干新的事都可能要等批准。

但换个角度看，这其实是把过去"靠人自觉"的安全责任搬进了平台。Cloudflare 的选择是：安全问题不能指望每个写 app 的人自己实现正确，平台必须兜底。对正在搭内部 Agent 平台的团队来说，这个取舍值得参考——MCP 解决了凭证托管，但数据流控制那一层，目前还得自己补。

开源版提供了核心仓库和一个基于 Cloudflare 内部实践的示例部署仓库，可以在自己账号里跑起来。模型侧走 AI Gateway，可以统一控制哪个模型处理哪类任务，把花费归属到人、团队和 workspace。真正的工作量在 Gatekeeper 的定制和上下文、技能库的整理上——源码只是起点。

观察日志粒度的问题

比较好奇的是观察日志的记录粒度。资源级别的记录（读了哪张表、哪个仓库）能支撑权限重校验，但 agent 把数据读进上下文、在模型内部推理、再生成新内容之后，这条数据实际上已经被"复制"进了模型的输出空间。现有机制校验的是"查看者对原始资源的权限"，而数据在 agent 内部加工后的衍生形态，审计上仍然是个模糊地带。日志记到什么粒度、保留多久、审计时怎么证明"没有泄露"，这些公开资料里还没有答案。对打算自建 Agent 平台的企业来说，这可能才是接下来最需要想清楚的问题。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。