Safe defaults for non-technical builders: apps needing per-user access control have no platform primitive (related to #455, #469)

[v1bh0r]

Summary

The README promises that "non-technical users can safely 'go nuts' and nothing bad will happen." For containment, the sandbox and connector model back that up: they stop an app from leaking data outward.

One common class of app falls outside that promise: an internal app with differentiated access between the people you share it with, such as per-user privacy, approvals, or an HR-style "only I see all of it" view. Cloudflare OS gives these apps no identity primitive, so the agent either builds no per-user access control or reinvents authentication. A non-technical builder can't tell which one they got, and the agent tends to describe the result as if it handles access control.

I'm raising this as a product design question about safe defaults and expectation-setting, so a non-technical builder doesn't leave with the impression that an app enforces per-user access when it doesn't. The sandbox and the documented collaborator trust model can stay as they are. I think #455 ran into the same boundary from the app side.

Where the gap shows up

A non-technical user asks the agent, in plain language, for an app with internal roles, for example "a team feedback app where only HR reads everything and everyone else sees only their own entries." The platform has no concept of who is using the app, so the agent takes one of two paths:

1. No real access control. The app gates on a field the browser supplies, such as an "I am HR" checkbox, and the agent's summary may still claim "authorization checks."
2. Homemade authentication. The app adds a second login with its own password hashing and sessions, the workaround Expose the authenticated viewer identity to collaborative Gadgets #455 documented, along with the UX and lifecycle problems that come with it.

Both models I tried went straight to building one of these. A non-technical builder can't tell "the platform enforces this" apart from "the app drew a checkbox", and that gap produces the false sense of security.

#455 hit the same boundary from the app side

In #455, a user building a team-chat gadget found the same missing primitive:

The agent explained that the Gadget has no authentication system and that Cloudflare Access/SSO would need to be added as a separate auth layer. … a separate authentication system inside every collaborative Gadget seems like the wrong boundary. Cloudflare OS has already authenticated the visitor and evaluated whether they may open the Gadget as its owner or as a build / use collaborator.

After building the workaround end to end, they concluded:

A collaborator now has to create a second account after Cloudflare OS has already authenticated them … the missing primitive is a narrow, OS-minted viewer/session capability … the server-side Gadget RPC facet should derive authorship from that authenticated connection; the browser client should never submit its own author identity.

#455 frames this as a feature request for durable collaborative apps. From a non-technical builder's side, it's also an expectation problem: Cloudflare OS invites non-technical users to build and share apps, and the apps that most need per-user access control are the ones it can't help with today.

Overlap with #469

#469 proposes a central RBAC/ABAC layer: administrators define which users and groups can use which agents, connectors, MCP tools, resources and data scopes, and gatekeepers enforce it using identity from Cloudflare Access. It makes a point this discussion shares: "the LLM should never be responsible for enforcing these permissions."

Both depend on the same prerequisite: trusted identity, with role or group context, reaching the point of enforcement. For #469 that point is a gatekeeper. For #455 and this discussion, it's an app's server code. The scopes differ:

• Enterprise RBAC/ABAC for Cloudflare OS — centralized permissions for users, agents, MCP tools and data #469 covers administrators governing access to connected systems and their data from one place.
• This discussion covers the apps people build on top, and what the product tells a non-technical builder those apps enforce.

Central connector policy wouldn't cover data an app stores itself, and app identity alone wouldn't give administrators the governance #469 describes. A viewer-identity capability that carries role context, and later group context, could serve both.

What would help

In rough order of leverage:

1. A minimal viewer identity minted by the OS, the capability Expose the authenticated viewer identity to collaborative Gadgets #455 asks for: an opaque stable subject, a display name and a role, derived on the server and never submitted by the client. With it, generated apps can enforce per-user access without a second login.
2. Say what the platform doesn't enforce. When a request implies per-user privacy or role-based visibility the platform can't enforce yet, the agent should say so in plain words. The docs could also mark where the "safely go nuts" claim ends and app-level access control begins, so operators can decide which use cases to open to all their users.

The platform already sets one safe default from what a workspace holds. Under the owner-invites-only latch from #523, once a workspace reads data a connector flags as sensitive, only the owner can add collaborators and share links stop admitting anyone. A comparable default for apps that keep their own records, such as owner-only sharing until the owner opts in, would extend that idea to app data.

Related work

• App launcher and standalone Gadget use mode #139 proposes an Apps launcher and a standalone runtime that separate using an app from building it. That's the builder and consumer split this discussion assumes.
• DO NOT MERGE: Workspace invitations and gadget sharing prototype #800, a draft prototype, separates inviting workspace members from sharing individual apps, and adds owner-only sharing controls.
• Design Proposal: Least-Privilege Collaboration for Observer-Gated Artifacts #74 covers collaborators with overlapping but different permissions, the same problem at the connector level.

Questions

• Is viewer identity for apps (Expose the authenticated viewer identity to collaborative Gadgets #455) on the roadmap? Would it carry the build/use role so apps can do per-user authorization, or is it scoped to presence and attribution?
• Do you intend app-level identity (Expose the authenticated viewer identity to collaborative Gadgets #455) and gatekeeper-level identity and policy context (Enterprise RBAC/ABAC for Cloudflare OS — centralized permissions for users, agents, MCP tools and data #469) to come from one shared mechanism?
• Apart from that, would you be open to the agent and the share UX stating what they do and don't enforce when a request implies per-user access control?
• Do you have a documented stance on which kinds of apps suit non-technical builders, and which assume a builder who understands the collaborator trust model?

I evaluated this on main at 835de9e8 on a local instance, and can share a walk-through of a role-based app if that helps.