Sharing Without Sharing Everything

Cloudflare OS treats sharing a data-bearing Gadget as an information-flow problem, not merely as a change to a permission table. This chapter follows a collaborator from an owner’s sharing decision through account selection, Gatekeeper verification, re-verification, and future observations. The practical judgment is whether the recipient can independently see the information the Gadget has already read—not simply whether the owner intended to let them open the UI.

A share permission is an intention, not proof of observability

A normal sharing table answers an important but limited question: has the owner, or someone with delegated authority, created a path by which this person may open the workspace? Cloudflare OS represents that intention through collaborators, share links, and roles. But a Gadget may have already read data from a private document, repository, database, or other service. The fact that the owner wants to share the Gadget does not prove that the recipient’s own account could read the same data.

That distinction matters because a Gadget can store or re-display observations after the original Gatekeeper call has ended. A UI-only collaborator might open the application hours later and see state that was populated from an external resource. If the workspace admitted that collaborator solely because a share link was redeemed, the application would become a data relay: the owner’s permission would silently substitute for the recipient’s lack of permission at the source.

Cloudflare OS therefore gives collaborator admission two conditions. The person must be reachable in the workspace’s sharing graph, and they must be configured as an observer who has passed the relevant Gatekeeper checks. The first condition captures the owner’s intent. The second tests whether the recipient’s own service accounts can observe the data the Gadget has already exposed.

The verification is deliberately delegated to the Gatekeeper that understands the resource. The Overseer generates an opaque observer identifier and supplies a verifier derived from the collaborator’s own connected account. The identifier is not the person’s email or profile name; it is a handle for the observer relationship inside this Gadget. The Gatekeeper receives the verifier from the same service domain that created it and decides whether that account may observe the information it has tracked.

Before verification can run, the recipient may need to choose which of their own connected accounts should satisfy each resource. A person may have a work and personal account for the same vendor, or several accounts with different rights. The configuration step asks them to choose rather than treating the owner’s account as transferable. If a selected account has disappeared or the Gatekeeper rejects it, the opening is denied or the user is offered a bounded chance to repair the connection. The observer record is persisted only after all required checks succeed.

This is a different meaning of “share.” The owner shares access to an application surface, but the recipient supplies evidence that they are independently entitled to observe the external data that surface may reveal.

Scope follows the capability surface

Cloudflare OS distinguishes at least two collaborator roles. A build collaborator receives the fuller editing and management surface: chat, code, bindings, and actions.