Data Read by Agents: Who Can See It After Sharing? Cloudflare OS Authorization Practices and Source Code Truth

Recently, Cloudflare open-sourced Cloudflare OS. After writing my previous article on the evolution of Cloudflare Agent architecture, I cloned their code repository and took a deep dive. What struck me most was an easily overlooked, hardcore pain point: once an Agent reads data, how should authorization actually be handled when it is re-shared with a team, exported, or during continued conversations?

When building Agents, we usually place a Model Context Protocol (MCP) layer or an API gateway out front, assuming everything is fine as long as identity is verified at the moment the Agent calls an API. However, in actual team collaboration, these static checkpoints for tool calls quickly lose control when confronted with persisted data and generated artifacts. The Cloudflare announcement offers a valuable approach: leveraging operating system metaphors to reorganize the application architecture, extending what was once a one-time invocation check into two stages—read registration and sharing access control. It should be noted that it currently does not cover unified inspection across all outbound channels; webFetch, model invocations, blueprint publishing, etc., follow their own distinct control paths. After combing through the codebase, I’d like to share the real mechanisms behind this design from a front-line developer’s perspective, as well as how we should make trade-offs when implementing it in our own architectures.

Sharing After Salary Sheet Generation: Why Tool Call Checks Fail at This Moment

Let’s start with a common everyday scenario in team collaboration. Alice, the HR lead, has access to the payroll database. In an Agent workspace, she calls data warehouse APIs to compute a team average salary dashboard. Feeling satisfied with the result, she casually sends the workspace link to Bob, a team manager. However, Bob does not have authorization to view salary data within the company. The second Bob clicks the link, existing security defenses fail.

Whether using traditional API gateways or the MCP protocol, verification occurs at the exact moment the Agent reaches out to fetch data. At that point, Alice was present, permission checks passed smoothly, and data was retrieved to generate the dashboard. By the time the dashboard is ready and the workspace is shared with Bob, the tool invocation has long been completed. Standing before a pre-generated dashboard, the system has lost three things: it cannot remember where the data source originated, cannot track which charts were tainted by sensitive data, and cannot re-test the data source against Bob’s credentials when Bob enters.

This is a classic case of “valid at read time, amnesiac once landed.” Once data enters a workspace, relying solely on that single API call boundary cannot control subsequent sharing and secondary leakage. To solve this problem, defenses must cover the entire lifecycle after data is read: when data is ingested into the workspace and converted into artifacts, what needs to be controlled extends beyond a single API call to the entire runtime environment.

Why Is It Called Cloudflare OS? Understanding Its Operating System Metaphor

This is precisely why Cloudflare calls it an operating system. When an Agent possesses long-running mini-apps, shared workspaces, and external data connections, its runtime environment itself functions as a mini OS. As explained in their announcement and internal adoption post, naming it Cloudflare OS is not about building a replacement for Linux or macOS, but rather establishing a clear foundational abstraction for shared Agent applications.

Examining the source code reveals that Cloudflare OS progresses along the physical actions of how an Agent handles requests, producing concrete engineering implementations for core operating system components:

The user-facing Workspace is equivalent to an OS user Session and shared working directory, hosting conversation history, context files, generated mini-apps, and external resource connections. The frontend and backend of the system (workshop-frontend and workshop-backend) play the roles of Shell and kernel subsystem respectively, responsible for receiving user input and scheduling underlying resources.

When the Agent needs to access external services like GitHub, Notion, or Slack, it cannot directly touch underlying long-term credentials. Instead, it issues requests through Gatekeeper. Gatekeeper acts like a device driver, injecting object capability bindings like env.PROJECT into the environment, executing actual external reads, and triggering user approvals for sensitive writes. After every external read, Gatekeeper reports the data source back to the kernel.

When the Agent dynamically generates interactive mini-applications (Gadgets) containing frontend, backend logic, and databases during runtime, these mini-apps act like processes running inside isolated sandboxes. If a user wishes to share the application template with others without exporting their own runtime data and credentials, the system exports a Blueprint, which is equivalent to a code template for an executable file.

Coordinating all of this in the background is Overseer, a persistent process running on Cloudflare Durable Objects. Overseer plays the role of the OS kernel, retaining the full state of the workspace, collaborator relationships, and the historical collection of observations reported by various drivers. With this design, drivers contractually report everything they read to the kernel, and the kernel then uses this ledger to govern entry to the workspace. It should be noted that this complete logging depends on the correct implementation of each driver; core cannot forcibly guarantee that edge paths like pagination, sub-sessions, or caching won’t miss a record. The security defense finds a convergence point, but the robustness of this anchor depends on the quality of driver implementations.

Extending Authorization to Post-Read and Sharing: Observation Records and Dual Invariants

At this pivot point, Cloudflare OS’s approach to resolving the Alice and Bob dilemma is not to parse dashboard contents at the moment of sharing, but rather to maintain a set of dual invariants within the kernel.

The first action occurs when data is read. Whenever the Agent fetches external data via a driver, the driver must explicitly call the authorizeObservation() API. The kernel stores the data source ID and required permissions for this read in a persisted Observation Set manifest. The workspace records not only what prompts the user sent, but also which controlled data sources this workspace has absorbed.

The second action occurs along the open and share interception paths, where the kernel enforces dual gatekeeping:

1. Entry Re-verification (When a Collaborator Opens): When Bob tries to open the workspace shared by Alice, Overseer retrieves all accumulated observation records for that workspace and re-verifies them one by one against the underlying APIs using Bob’s credentials. If Bob lacks read permission for even a single data source, Overseer blocks Bob from opening the workspace.
2. Subsequent Blocking (New Reads After Sharing): If the workspace is already shared between Alice and Bob, and Alice asks the Agent to read a new sensitive source in a subsequent conversation, Overseer intercepts the request before Gatekeeper prepares to read, because allowing this read would cause the workspace’s observation set to exceed Bob’s permissions.
3. Fail-Closed Degradation (Fail-closed Mechanism): For certain highly sensitive data sources marked as Owner-only readable, once read into the workspace, Overseer immediately locks the workspace, forbidding the addition of new collaborators while cutting off external public network retrieval interfaces.

With this mechanism, the system does not need to strain to understand dashboard contents; as long as it detects that Bob’s permissions cannot cover the history of data sources absorbed by the workspace, it can nip the risk in the bud right at the entry point.

Coordinate Positioning: Its Relationship with Capability, Taint Tracking, and MCP

Having understood Cloudflare OS’s approach, we can place it accurately within the coordinate system of security theory and engineering practice.

Let’s recap its physical process: before invocations, provide controlled handles (such as env.PROJECT) instead of global keys; after reading, append data source manifests to the workspace; during sharing and opening, match the manifest against the recipient’s identity; when exporting blueprints, strip data and credentials without performing identity matching. In the security coordinate system, these three physical actions correspond to object capability proxies, coarse-grained observational taint tracking, and identity entitlement provenance. It does not stop at traditional API checkpoints that lose control post-call, nor does it pursue high-cost dynamic character-level tracking. By choosing bookkeeping at the workspace granularity, it makes a pragmatic compromise between implementation cost and practical security.

Understanding this positioning also clarifies its relationship with the currently popular Model Context Protocol (MCP): the core of the MCP specification (2026-07-28) lies in tool call standardization, OAuth authorization, and pre-call scope negotiation—governing how to fetch data in a standardized manner. Cloudflare OS governs the story after data is fetched, overlaying observation provenance and sharing access control on top of MCP. The two fulfill their respective roles upstream and downstream, complementing each other.

When handling generic MCP bindings, Cloudflare OS takes a conservative stance in its MCP sharing policy definition: it does not allow users to directly share MCP connections containing credentials with others. If you want to share a Gadget, you can only share a Blueprint code template stripped of credentials and data, allowing new collaborators to re-bind using their own accounts.

Implementation Blueprint: How to Add This Layer to Your Own Agent Architecture

After clarifying the mechanics of this design, when building our own enterprise Agent architecture, we can logically divide security governance into three planes:

       [ 1. Pre-call Plane ]
   Capability Proxy / Dynamic Scope / Credential Isolation (e.g. env.PROJECT)
                    │
                    ▼ (Data Read)
       [ 2. Post-read Plane ]
   Gatekeeper Explicit Logging ──► Overseer Dynamic Observation Set Manifest
                    │
                    ▼ (Context / Artifact Sharing)
       [ 3. Pre-egress Plane ]
   Workspace / Artifact Access Verification (Done by Cloudflare OS)
   ──► Unified Egress Sink Policy (Needs self-implementation; Cloudflare OS currently hasn't)

1. Pre-call Plane: Continue implementing Capability principles. Avoid passing global API keys directly into Agent contexts; consistently use restricted proxy handles or temporary credentials.
2. Post-read Plane: Enforce instrumentation at the data ingestion layer. Whenever external data is read, write an Observation Set entry to the server-side persistent context to keep an accurate ledger.
3. Pre-egress Plane: Invoke a unified policy engine when opening or sharing workspaces, matching audience identity against historical ledgers. Unified outbound request egress checking needs to be added yourself—Cloudflare OS currently only implements share/open access control, while outbound channels like webFetch and model invocations follow separate control paths.

Of course, there is no need to make things this heavy in every project. Based on practical experience, here are recommended trade-offs by scenario:

Moving from moment-of-invocation interception toward workspace-level observation tracking and sharing access control is an inevitable hurdle as Agents evolve from personal assistants into enterprise productivity systems. Cloudflare OS has mapped out a path for us using an apt operating system metaphor. It advances the authorization model, though it has not yet achieved an end-to-end closed loop spanning resources, artifacts, and all egress points. As for how to tightly guard egress and refine tracking granularity, that will depend on our craftsmanship in practical engineering.