--- layout: post.njk source: https://yage.ai/share/cloudflare-os-authorization-20260808.html speaker: yage.ai title: |- Agent 读过的数据，分享后还能给谁看？Cloudflare OS 的授权实践与源码真相 date: '2026-08-10' summary: 文章探讨了 Cloudflare OS 如何通过引入操作系统的角色隐喻，将 Agent 的数据授权实践从一次性的调用检查延伸到读取登记与共享准入两个环节。核心思想是建立一个覆盖数据读取后整个生命周期的观察记录与双向不变量机制，从而在工作区层面实现对数据源的精细化控制和安全共享策略的落地。 area: tech-engineering category: ai-application tags: - agent-architecture - data-sharing - security-governance - workflow-tools people: [] companies_orgs: - Cloudflare products_models: - Cloudflare OS media_books: [] draft: true status: evergreen --- 前阵子 Cloudflare 把 Cloudflare OS 开源了。在写完上一篇关于 Cloudflare Agent 架构演进 的文章之后，我把他们的代码克隆下来研究了一圈。最触动我的地方在于一个容易被忽略的硬核痛点：Agent 读过的数据，在团队二次分享、导出或者继续对话时，到底该怎么授权？ 平时咱们做 Agent，习惯拿 Model Context Protocol（MCP）或者 API 网关在前面挡一把，觉得只要 Agent 调 API 的那一瞬间校验了身份就万事大吉。但在实际的团队协作里，这种工具调用的静态关卡一旦遇到落盘的数据和生成的产物，很快就会失去控制。Cloudflare 发布说明提供了一个可借鉴的思路：借用操作系统的角色隐喻重新组织应用架构，把原本一次性的调用检查，延伸到读取登记与共享准入两个环节。需要说明的是，它目前没有覆盖所有外发出口的统一检查，webFetch、模型调用、blueprint 发布等走各自不同的控制路径。把代码翻透之后，我想从一线开发者的视角，聊聊这套设计背后的真实机制，以及咱们在自己架构里落地时到底该怎么取舍。 ## 薪资表生成后共享：工具调用检查为何在这一刻失效？ 传统工具调用检查 vs Cloudflare OS 的读取登记与分享重验 咱们从团队日常里一个常见的场景说起。HR 负责人 Alice 具备薪资库权限，在 Agent 工作区里调数据仓库 API 算了一张团队平均薪资看板。她觉得做得很棒，顺手把工作区链接发给了团队主管 Bob。但 Bob 在公司里并没有看薪资的权限。当 Bob 点开链接的那一秒，现有的安全防线就失去了作用。 无论是传统的 API 网关还是 MCP 协议，校验都发生在 Agent 伸手拿数据的瞬间。当时 Alice 在场，权限校验顺利通过，数据读出来生成了看板。等看板做好、工作区发给 Bob 时，工具调用早就完成了。眼前只有一份生成好的看板，系统丢掉了三样东西：记不住数据源来自哪里、跟踪不到哪些图表染了敏感数据、也无法在 Bob 进门时拿 Bob 的凭据去重测数据源。 这就是典型的读取时合法，落地后失忆。一旦数据进了工作区，光靠 API 调用的那一下拦阻，根本管不住后面的分享与二次泄露。要解决这个问题，防线必须覆盖数据读取后的整个生命周期：当数据读进工作区变成产物，需要把控的已经超出了某一次接口调用，延伸到了整个运行环境。 ## 为什么叫 Cloudflare OS？看清它的操作系统隐喻 Cloudflare OS 部件与传统操作系统的对照 这正是 Cloudflare 把它叫作操作系统的原因。当 Agent 拥有了长期运行的小程序、共享工作区和外部数据连接时，它的运行环境本身就是一个微型 OS。正如他们在发布说明和内部采用说明里说明的那样，叫 Cloudflare OS 并非要搞一个替代 Linux 或 macOS 的系统，而是给共享 Agent 应用建立一套清晰的底层抽象。 翻看源码可以发现，Cloudflare OS 沿着 Agent 处理请求的物理动作推进，将传统操作系统的核心组件做出了具体的工程实现： 用户接入的 Workspace 相当于操作系统的用户 Session 和共享工作目录，承载着会话历史、上下文文件、生成的小应用以及外部资源连接。系统的前后端（workshop-frontend 和 workshop-backend）则分别扮演 Shell 与内核子系统的角色，负责接收用户输入与调度底层资源。 当 Agent 需要访问 GitHub、Notion 或 Slack 等外部服务时，它并不能直接接触底层长期凭据，而是通过 Gatekeeper 发起请求。Gatekeeper 就像设备驱动，向环境注入类似 env.PROJECT 的对象能力绑定，负责执行实际的外部读取，并在敏感写入时触发用户审批。每次外部读取完成后，Gatekeeper 都会将数据源头向内核报备。 当 Agent 在运行中动态生成带有前端、后端逻辑与数据库的交互式小应用 Gadget 时，这些小程序就像是在隔离沙箱里运行的进程。如果用户希望将应用模板分享给他人，但不带走自己的运行数据与凭据，系统会导出 Blueprint，这便相当于可执行文件的代码模板。 而在后台统筹这一切的，是运行在 Cloudflare Durable Objects 上的持久化进程 Overseer。Overseer 扮演着操作系统内核的角色，保存着工作区的完整状态、协作者关系，以及由各个驱动报备上来的历史观察集合。这么一设计，驱动按合同应当读了什么都向内核报备，内核再拿着这本账本去把控工作区的入口。需要说明的是，这套完整报备依赖每个驱动的正确实现，core 并不能强制保证分页、子 session、缓存等边缘路径上不漏记。安全防线找到了收敛的支点，但这个支点的牢固程度取决于驱动的实现质量。 ## 把授权拉长到读取后与共享时：观察记录与双向不变量 在这个支点上，Cloudflare OS 解决 Alice 和 Bob 困局的思路是：不在分享瞬间去解析看板内容，而是在内核里维持一套双向不变量。 第一个动作发生在读取数据时。每当 Agent 通过驱动去外部取数据，驱动必须显式调用 authorizeObservation() 接口。内核把这次读取的数据源 ID 和所需权限存进持久化的 Observation Set 清单里。工作区不仅记录了用户发过什么 Prompt，还记下了这个工作区吸收过哪些受控数据源。 第二个动作发生在打开与分享拦截路径上，内核实施双向把关： 入口重验（协作者打开时）：当 Bob 尝试打开 Alice 分享的工作区时，Overseer 会取出该工作区积累的所有观察记录，用 Bob 的身份凭据逐一向底层 API 发起重新校验。只要 Bob 缺少其中任何一个数据源的读取权限，Overseer 就会阻断 Bob 打开该工作区。 后序阻断（共享后新读取）：如果工作区已经被 Alice 和 Bob 共享，当 Alice 在后续对话中想让 Agent 读一个新的敏感源时，Overseer 在 Gatekeeper 准备读取前就会拦截该请求，因为允许这次读取会导致工作区的观察集合超出 Bob 的权限范围。 闭锁降级（Fail-closed 机制）：对于某些标记为仅 Owner 可读的高敏感数据源，一旦在工作区中读取后，Overseer 会立即锁定该工作区，禁止添加新的协作者，同时切断外部公开的网络获取接口。 有了这套机制，系统不用费劲去理解看板内容，只要发现 Bob 的权限包不住工作区历史吸纳的数据源清单，就能在入口处把风险掐断。 ## 坐标系定位：它与 Capability、Taint Tracking 及 MCP 的关系 理解了 Cloudflare OS 的这套做法，咱们从安全理论和工程实践的角度，可以给它找个准确的位置。 重新捋一遍它的物理过程：调用前不给全局密钥给受控句柄（如 env.PROJECT）；读取后在工作区追加数据源清单；分享和打开时拿清单跟接收者的身份做匹配；导出 blueprint 时只剥离数据和凭据，不做身份匹配。在安全坐标系里，这三步物理动作分别对应了对象能力代理、粗粒度观察污点标记和身份权益追溯。它没有停留在调用完就管不到的传统 API 关卡，也没有去走给每个字符做动态跟踪的高成本路线。它选在工作区这个粒度做记账，是在实现成本和实用安全之间做了一次务实的折中。 明白了这个定位，也就看清了它和当下火热的 Model Context Protocol（MCP）的关系：MCP 规范（2026-07-28）的核心在于工具调用的标准化、OAuth 授权以及调用前的 Scope 协商，管的是如何规范地去拿数据。Cloudflare OS 管的是拿完数据之后的故事，在 MCP 上层叠加了一层观察追溯和共享准入。两者在上下游各司其职，形成互补。 在处理通用的 MCP 绑定时，Cloudflare OS 在 MCP 共享策略定义 里采取了保守的态度：它不允许用户直接把带凭据的 MCP 连接分享给别人。如果你想分享 Gadget，只能分享不带凭据和数据的 Blueprint 代码模板，让新协作者用自己的账号去重新绑定。 ## 落地蓝图：如何为你自己的 Agent 架构补齐这一层？ 看清这套设计的机制后，咱们搭建自己的企业级 Agent 架构时，可以顺理成章把安全治理划分为三个平面： ``` [ 1. 调用前平面 Pre-call Plane ] Capability 代理 / 动态 Scope / 凭据隔离 (如 env.PROJECT) │ ▼ (数据读取) [ 2. 读取后平面 Post-read Plane ] Gatekeeper 显式记录 ──► Overseer 动态 Observation Set 清单 │ ▼ (上下文/产物分享) [ 3. 传播与出口平面 Pre-egress Plane ] Workspace / 产物准入校验（Cloudflare OS 已做） ──► 统一 Egress Sink Policy（需自行补齐，Cloudflare OS 当前未做） ``` 调用前平面：继续贯彻 Capability 思想。别在 Agent 上下文中直传全局 API 密钥，统一用有限权限的代理句柄或临时凭据。 读取后平面：在数据接入层强制埋点。只要发生了外部数据读取，必须向服务端持久化上下文写入 Observation Set，把账本记明白。 传播与出口平面：在工作区打开、分享时调用统一的策略引擎，比对受众身份与历史账本。向外发请求的统一出口检查需要自行补齐——Cloudflare OS 当前只做了 share/open 准入，webFetch、模型调用等外发渠道走各自不同的控制路径。 当然，咱们也没必要在所有项目里都搞这么重。结合实践，建议大家按场景做取舍： 场景类型 是否需要观察追溯与受众重验 架构建议 单用户受控终端 / 本地 CLI 不需要 传统的 API Key 加本地沙箱足够，没必要加内核开销。 单人使用但具备公开 Web 导出 简易需要 重点把守出口检查，防止公开 Fetch 泄露数据。 企业多人共享 Workspace 必须构建 必须建立 Observation Set 清单，并在打开与分享节点做身份重验。 跨部门数据协同分析 必须构建（需升级） 在工作区记账的基础上，把标记做细到文件或产物粒度，避免过度污染。 从工具调用的瞬间拦截，走向工作区级的观察追溯与共享准入，是 Agent 从个人助手走向企业生产力系统绕不开的一关。Cloudflare OS 用一套贴切的操作系统隐喻帮咱们把路探了出来，它推进了授权模型，但尚未完成从资源、产物到所有出口的端到端闭环。至于如何把出口守严、把标记做细，就看咱们在实际工程里的手艺了。