如果 AI 用它读过的资料创建了新应用，谁能查看这个应用？
将企业内部 AI 连接到 GitHub 仓库或客户数据时，似乎只要一开始收紧权限就足够了。但当代理读取这些资料、创建仪表板、与同事共享或发送给外部服务时，问题就不同了。因为无法查看原始内容的人，仍可能从处理后的结果中看到其中的信息。
Cloudflare OS 有意思的地方在于，它并不止于向代理隐藏 API 密钥。它会记录代理实际观察到的资源，并将该记录用于之后创建的工作区、应用和输出的查看与传输策略。这是一种将权限附着在数据移动路径上，而非初始调用上的设计。
Sandstorm 的失败并非因为“用户不会编程”
Cloudflare OS 的谱系可以追溯到 Kenton Varda 创建的 Sandstorm。Sandstorm 是一个自托管平台，将文档和应用作为小型独立实例运行，并为每个实例划分访问权限。
不过，在 2017 年业务终止时，官方回顾指出的直接失败原因并不是这个想法已经过时。产品仍然处于粗糙的 Alpha 阶段，企业销售比预期更困难，而且缺少让产品和销售稳定下来的资金与时间。其说明还提到，数百次企业试用和兴趣表达几乎没有转化为实际购买。
Varda 在 2026 年的一篇公开文章中，将 Cloudflare OS 描述为利用 Workers 和 AI 对 Sandstorm 的重制版。它像 Sandstorm 的“Grain”一样细粒度隔离应用实例，但这一次用户可以请求代理直接修改所需的应用。
Cloudflare 在 2026 年 5 月向全体员工提供了第一个版本。根据公司说明，来自多个职能的数千人使用它创建文档和幻灯片、自动化重复工作，以及制作小型应用。不过，该公司没有公布精确的活跃用户计算方法，也没有公布采用前后的生产率变化。
Gatekeeper 将访问、观察和后续流动连接起来
公开的 Cloudflare OS v2 由处理公司上下文的代理工作区、安全与治理层，以及个性化应用平台组成。其中，考虑企业内部采用的团队首先应查看安全层中的 Gatekeeper。
| 阶段 | Gatekeeper 控制的内容 | 需要确认的问题 |
|---|---|---|
| 访问前 | 将凭证与代理及生成的代码隔离，并提供针对特定仓库、议题或操作等范围狭窄的 capability | 代理能否看到原始令牌，或调用范围之外的资源？ |
| 使用数据时 | 记录代理实际观察到的资源 | 是否不仅追踪工具调用记录，还追踪读取的原始资源？ |
| 使用结果后 | 将观察记录应用于结果查看、邀请协作者、外部请求和交给其他代理的策略 | 没有原始权限的用户能否打开或导出派生结果？ |
例如，如果代理读取敏感表格后创建了仪表板，其他用户打开该仪表板时，可以再次检查其对原始资源的访问权限。这种方式避免了派生结果仅因代理已经读过就自动公开。
将这种差异简化为“MCP 有风险而 Gatekeeper 安全”并不合适。MCP 服务器也可以保存凭证。Cloudflare OS 更进一步的部分是，它不仅将策略关联到工具调用许可，还关联到观察过的资源，以及这些数据之后会流向何处。
评估采用时应问的三个问题
- 代理和生成的代码能否直接读取 OAuth 令牌？
- 系统是否会保留观察过哪些行、文件和仓库，而不仅是调用了哪些工具？
- 源数据派生出的应用和输出，是否也继续受到相同的共享与对外传输限制？
Gadget 将应用代码和用户数据分开处理
在 Cloudflare OS 中，代理创建的个性化应用称为 Gadget。每个 Gadget 都有独立的 Dynamic Worker 运行时和 SQLite 状态，从而按应用划分运行环境和状态。
如果想为同事创建相同的应用，可以共享 Blueprint。此时复制的是代码，原用户的数据、对话记录、凭证和已连接的资源都不会包含在内。这就区分了直接共同使用完成的应用，与交付一个空白副本。
具有外部副作用的操作也可以由 Gatekeeper 进行协调。在等待审批时，它可以模拟结果，使代理继续后续工作，并支持用户稍后逐项或批量批准。不过，并非所有写入操作都始终需要人工批准。哪些操作需要批准取决于所连接的 Gatekeeper 和组织策略。
不接入外部数据，先创建第一个 Gadget
在用于了解该架构的首次实践中，不从连接 GitHub 或 Google OAuth 开始会更简单。你需要准备Cloudflare 账户、管理员电子邮件地址，以及用于 workers.dev 地址的实例名称。还请提前了解，创建第一个白板的那一刻就会执行模型推理。
运行前请检查计费和使用上限。官方部署页面的默认模型可通过 AI Gateway 使用，无需单独的 API 密钥，但用量可能会计入部署者的 Cloudflare 账户。输入 Anthropic 或 OpenAI API 密钥是可选项，之后可以再添加。
- 在官方部署页面登录 Cloudflare。打开Cloudflare OS 部署页面，使用 Cloudflare 账户登录，然后批准所请求的仪表板访问权限，以便部署到自己的账户。
- 输入实例名称和管理员电子邮件，然后部署。实例名称将用于部署后的
workers.dev地址。同时输入要用作管理员的电子邮件地址，然后开始部署。该托管路径无需本地构建，即可部署到自己的 Cloudflare 账户。 - 使用管理员电子邮件登录。打开已部署的
workers.dev地址，输入管理员电子邮件，然后使用 Cloudflare Access 发送的一次性 PIN 登录。访问后，也请在/admin中确认同一电子邮件是否被识别为管理员。 - 在默认工作区输入第一个请求。在未连接外部服务的状态下，请求Make a collaborative whiteboard app.。这是仓库提供的示例提示词，模型用量可能从这次请求开始产生。
- 成功的标准不是生成，而是运行。确认生成的白板 Gadget 能够打开，并且你可以亲自添加或移动元素。仅在下一步确实需要内部资料时，再配置相应的 Gatekeeper 和 OAuth 凭证。
现在全面投入生产仍为时过早。截至 2026 年 8 月，公开版本仍处于早期访问阶段，在自有服务器上使用 workerd 运行的生产部署文档和工具也尚未完成。采用 Apache-2.0 开源许可并不意味着运营成本免费。在试点阶段，应一并评估实际的 Workers、存储和 AI 用量，以及固定版本和信任边界。
该带走的是权限的生命周期，而非“AI 操作系统”这个名称
Cloudflare OS 与其说是传统计算机操作系统，不如说是一款将代理工作空间和应用隔离层比作操作系统的产品。因此，比起名称或内部使用规模，更应该先确认的是权限会维持多久、延伸到何处。
仅凭目前公开的资料，无法独立证明 Gatekeeper 的安全性。外部安全审计结果、按组织规模划分的运营成本、公开 v2 的实际活跃用户和生产率变化也都尚未得到确认。不过，它仍为设计企业内部 AI 平台的团队留下了一个明确的问题：不要止步于“谁能调用这个工具？”，还要将“谁能看到用该工具读取的数据所创建的结果，以及这些结果能被发送到哪里？”纳入权限模型。
如果想进一步深入了解
Cloudflare OS: an open platform for agents, apps, and work 可以通过官方案例了解三个组成部分、Gatekeeper 的观察记录和 Gadget 共享策略。 blog.cloudflare.com
cloudflare/cloudflare-os 这是适合查看许可证、示例提示词、本地运行方式和早期访问限制的官方仓库。 github.com
Deploy Cloudflare OS to Cloudflare 运行前可查看当前托管部署所需的实例名称、管理员电子邮件，以及默认模型的计费说明。 os.cloudflare.app
Sandstorm is returning to its community roots 这是创始人亲自整理的回顾，讲述了 Sandstorm 业务终止时的产品成熟度、企业销售和资金问题。 sandstorm.io
