cloudflare-os is a worked implementation of the tenancy plane: nine verified design priors, plus a substrate requirements list

[forkwright]

Finding

cloudflare/cloudflare-os (Apache-2.0, ~390k lines TypeScript, actively developed) is a
production-hardened implementation of the problem dioptron has specced and not built: co-tenancy
between a human operator and an AI agent sharing one sandboxed session over persistent capability
grants. Nine of its design decisions transfer at the interface and contract level, independent of
its runtime. Its hardest sub-problem — what sharing an agent-populated workspace actually means,
resource by resource — has a 556-line worked specification with an explicit strategy taxonomy.

Per PRIOR-ART.md, this is the Read path: pattern sources, read for architecture, no code
imported and nothing depended on. Every citation below resolves at pinned commit
1ba6ac02f, and each was independently re-opened by an adversarial verifier that refuted by
default; one candidate pattern was dropped and one claim corrected (noted inline).

Candidate table

Repo	Licence	Extract for	Disqualifiers
cloudflare/cloudflare-os@1ba6ac02f	Apache-2.0	capability-grant scoping, approval-queue state machine, durable action log, co-tenancy sharing model, permission graph, fail-closed role typing	Isolation and RPC substrate is Cloudflare Workers-native (Durable Objects, Dynamic Worker Facets, Cap'n Web, Workers Bindings) and does not port to a sovereign local-first runtime. Every pattern below is stated at the contract level; the plumbing is not reusable. The observer model is a design doc partially deployed upstream, not battle-tested across all connectors.

Patterns

P1 — Object-capability injection via typed loopback binding. Every resource reachable by
agent-authored code is injected as a named env entry whose stub is constructed with typed props
{overseerId, target, caller} and re-resolves the live session from the owning durable actor on
each call, rather than carrying a copied credential. overseer.ts:2139 (getEnvForLoader),
:2153 (getEnvForAgent), :1800 (visibleBindings), :2124 (makeBindingLoopback), :6995
(GatekeeperLoopback). Verdict: adopt-now as a spec pattern.
Verifier correction, carried: the finder's claim "no binding is ever ambient" is too strong.
AGENTS.md:26,32 documents a legitimate ambient class, admin-configured. The accurate invariant is
upstream's own: ambience is legitimate only by user/admin configuration, never self-asserted by
the provider (AGENTS.md:16). The injection mechanism is unchanged either way.

P2 — Simulate-then-approve action queue. Side-effecting calls split into submit (returns
immediately, optionally against a provider-simulated post-action state so the agent keeps working
and can queue dependent actions) and apply (only after human approval). An advisory
awaitDecision flag lets a provider that cannot simulate its own effects suspend the turn instead
of proceeding against stale state; a restart return from reject/revert handles unwindable
simulated state. gatekeeper.ts:734,814,825,847, ActionDescription.awaitDecision:1164,
autoApprovable:1178. Verdict: adopt-now. See the separate note below — this one reaches
beyond dioptron.

P3 — Auto-approval as dual-signal, strictly-ordered, attributed drain. An action auto-applies
only when BOTH the provider's own per-call autoApprovable verdict AND a user-enabled per-tag rule
exist. The drain applies in strict id order and stops at the first ineligible or failing action
rather than skipping ahead. Application is attributed to whoever enabled the rule, not to the agent
that triggered it. auto-approval.ts, whole 97-line file. Verdict: adopt-now.

P4 — One durable record is the approval queue AND the audit trail. Every read
(authorizeObservation:2745) and every side-effecting call (submitAction:2958) becomes one
sequentially-numbered ActionRecord with caller provenance, lifecycle state, and description, in a
single storage.actions collection serving the pending-approval UI, the auto-approval eligibility
check, and the permanent audit log. Verdict: adopt-now. This is our own one fact, one place
applied to capability-mediated action, and it forecloses the class where an audit log and an
approval queue silently disagree.

P5 — Sensitive-data one-way lockdown ratchet. A provider can mark one observation maximally
sensitive; this flips a sticky workspace-scoped flag that blocks the observation if the workspace
is already shared, forbids all future sharing, and drops the workspace to reads-only with no
outbound fetch — specifically so the agent cannot become an exfiltration path through a different
capability than the one that read the data. gatekeeper.ts:1069-1099; checked at overseer.ts:2745,
:2900 (getWebFetchEnv), :2960. Verdict: adopt-now, explicitly as a floor. Upstream's own
docs call it a stopgap beneath P6.

P6 — Read-through-sharing / observer verification. Sharing a workspace does not
transitively grant a new party everything the agent already read through it. Each provider
independently verifies the new party's own credentials against everything historically observed
(addObserver, refusing if insufficient), using a verifier object minted by the new party's own
account rather than asserted by the workspace — so identity flows from the resource's trust domain,
not a central broker. Reads the party still cannot see are individually excluded rather than
tripping the blunt lockdown, and verification re-runs on every session open so revocation is caught.
A five-way strategy taxonomy (§9.2) tells an implementer which shape fits which resource: A refuse
all non-owners, B single-ACL-unit check, C track-and-verify per sub-resource, D no-op for low
stakes, N not applicable — including an explicit admission that some resources (Gmail, ZoomInfo)
have no per-user ACL oracle and must fall back to A. docs/observers.md, 556 lines;
gatekeeper.ts:685,745-790. Verdict: adopt-now.
Disqualifier, and it matters: upstream ships this as a design document only partially deployed
across connectors — most still rely on P5's blunt flag. Adopting it means productionising a
documented idea, not copying a proven one.

P7 — Lazy-revocation permission graph with fixed-point role propagation. Collaborator access is
a directed graph of typed edges from an implicit owner root; roles totally ordered; effective role
computed live at session-open as a fixed point (each edge grants min(edge role, sharer's current effective role), maximised over a user's edges, iterated to convergence) and never denormalised
into storage. Revocation severs edges without cascade-delete, so it is reversible; a preview/confirm
flow shows who else becomes unreachable before committing. docs/sharing.md:54-136,
SharingManager.computeEffectiveRoles. Verdict: adopt-now for the algorithm.

P8 — Default-deny-by-compile-error role interfaces. A restricted-role session object is typed
as implementing the full privileged interface but throws Unauthorized outside an explicit
allowlist. Because the type system demands every method be implemented, adding a new privileged
method fails to compile until someone consciously decides the restricted role's behaviour.
docs/sharing.md:28-30. Verdict: adopt-now. Ports to Rust as implementing the whole trait, or
exhaustively matching a capability enum so a new variant cannot compile unhandled. This converts
"someone forgot to gate the new endpoint" from a live security bug into a build failure.

P9 — MCP capability scoping by resource-URL grammar. An MCP server grant is scoped to a
resource-URL pattern, not "the whole server"; tools are classified read/action from server-declared
annotations, but only a deployment-vetted trust tier may self-declare. Verdict: adopt-now.

N1 — The substrate itself: non-adopt. Durable Objects, Dynamic Worker Facets, Cap'n Web and
Workers Bindings are the isolation and RPC layer under all of the above. This is not a component to
route; it is a requirements list for whatever local actor/sandbox substrate dioptron eventually
picks — single-threaded stateful actor with transactional storage, cheap per-tenant instantiation,
capability-passing RPC. Recording it as a requirements list is the useful form.

Dropped by verification: one further candidate ("ephemeral content-addressed sandbox instances
for speculative execution") did not survive; its citation did not establish the claim.

Why this matters

Dioptron is eleven specced layers plus a tenancy plane, with zero code. The most expensive thing a
zero-code repo can do is design its hardest subsystem from first principles when a worked answer
exists. P6 in particular is a direct hit on the sub-problem dioptron will meet first, and it comes
with the honest part attached — a taxonomy that names where the answer is structurally "refuse"
rather than "verify".

There is a second consumer, and it is not dioptron. P2 answers a hole this fleet has documented
as open. metis-ops/CLAUDE.md records, from measurement, that under --dangerously-skip-permissions
an ask decision is auto-approved and blocks nothing, so the ask class is an audit-trail entry
rather than a gate — and that the standing operator session runs exactly that way because the
harness is too friction-heavy otherwise. cloudflare-os's README.md:75 names the same trade-off
in the same terms and answers it structurally rather than with policy: the agent never blocks,
because submit returns immediately against simulated state while apply waits for the human. That
decouples agent progress from approval latency, which is the actual reason skip-perms gets turned on.
That belongs in a kanon/metis-ops issue about the hook policy, not here; filed separately and
cross-referenced.

Desired correction

1. Add a design-priors section to dioptron's specification carrying P1–P9 with these verdicts, and
   N1 as a substrate requirements list. Follow the shape in STANDARDS.md § Sovereign SQL engine
   reference map — repo, licence, extract-for, disqualifiers — so the read-not-import boundary stays
   auditable.
2. Treat P6's taxonomy as the skeleton of the tenancy-plane spec rather than as one input among
   nine. It is the only artifact in the set that is itself a specification.
3. Record N1 as the acceptance criteria for the substrate choice, before a substrate is chosen.

Done when: dioptron's spec carries the candidate table and a per-pattern verdict, and the
tenancy-plane section names which of A/B/C/D/N applies to each capability class it intends to
support.

Provenance

Mined 2026-08-15 from a shallow clone pinned at 1ba6ac02f. Nothing copied; no dependency proposed.
Method and obligations per crates/basanos/standards/PRIOR-ART.md (branch docs/prior-art-standard).

[forkwright]

P10 — Credential-generation-bound bearer tokens with provenance-scoped capability gating

A tenth pattern routes to the tenancy plane from a different upstream than the nine above, so it is
recorded here rather than left out of the candidate table.

Source: unslothai/unsloth@6f443b5cc. Licence: read the boundary carefully. The repo is
dual-licensed — the root unsloth/ package (kernels, models) is Apache-2.0, but everything under
studio/ carries an AGPL-3.0-only per-file SPDX header, confirmed across studio/backend/state,
studio/backend/auth, studio/backend/core/inference and studio/src-tauri, plus root COPYING
and README.md:450 stating the split. This pattern is sourced from studio/, so it sits on the
AGPL side. Nothing is copied either way; the mechanism is reimplemented from the description
below, and the boundary is recorded because a later reader considering a stronger form of adoption
needs it visible.

Evidence: studio/backend/auth/authentication.py:178-308.

Mechanism. Every verified bearer token resolves to a (subject, credential_generation) pair,
where the generation is a hash of the exact credential secret the token verified against. Any
route that persists a new credential must bind its write to that generation, so a password or key
rotation landing mid-request cannot let a request authenticated against the old secret bless a
write on behalf of the new one. That is a TOCTOU close on credential rotation, and it is the
non-obvious half: a naive subject + expiry JWT does not have it.

The second half is provenance-scoped capability. The same bearer-token mechanism issues tokens with
different origins — a UI-session JWT, a desktop JWT (desktop: true claim, authenticated against a
local secret rather than the account password), or an API key — and routes grant different
capabilities purely by provenance rather than by role. Only a UI session may configure a local
stdio MCP server, which means an arbitrary host command outside the sandbox; only a non-API-key
caller receives the backend's ambient download token as a fallback. Invalid-key errors are
deliberately indistinguishable across all real keys so there is no key-existence oracle, with the
single exception of the well-known placeholder key, which gets a distinguishing message.

Verdict: adopt-later. Trigger: dioptron produces its first working implementation of
operator-versus-agent token issuance, moving past the current spec-only state. Not before — there is
nothing to bind a generation to yet.

Disqualifiers. The AGPL boundary above. Beyond that, the JWT-plus-SQLite-stored-secret mechanics
are implementation detail and not the transferable part; what transfers is exactly two design
decisions — bind the token to the credential version, and gate capability by token provenance
rather than by a role name. The provenance gating in particular is only sound while the set of
provenances is small and closed; it does not generalise into a role system, and trying to grow it
into one would reintroduce the problem P7's permission graph solves properly.

Relation to the nine above. P1 scopes what a capability is; this scopes who is holding one
and whether their credential is still current. They compose rather than overlap: P1 without this
has no answer to rotation, and this without P1 has no answer to ambient authority.