Design Proposal: Least-Privilege Collaboration for Observer-Gated Artifacts

[olajidechris]

Design proposal: Least-privilege collaboration for observer-protected artifacts

This proposes an optional workflow for deriving capability-gated artifact variants after observer authorization failures, without changing the existing observer authorization model.

Summary

The observer model in Cloudflare OS is a strong fail-closed design for preventing information leakage through generated artifacts.
This proposal does not change that invariant.

This is about a workflow problem that appears when collaborators have overlapping but non-identical permissions: sharing fails (correctly), and teams may then choose between broad permission grants or moving work outside the platform.

I’m proposing an optional, recipient-driven path for deriving a constrained version of an artifact while preserving current observer authorization behavior.

Current workflow (simplified)

Owner creates artifact
        │
        ▼
Artifact observes protected resources
        │
        ▼
Owner shares artifact
        │
        ▼
Recipient fails observer authorization
        │
        ▼
Access denied

Security-wise, this is correct.
Workflow-wise, repeated failures can create pressure toward coarse permission expansion.

Problem statement

In practice, collaborators often need partial artifact utility, not full source-equivalent access.

Examples:

• A manager can access production metrics but not an experimental dataset included in the artifact.
• An engineer can review technical components but lacks access to business-sensitive inputs used in the same artifact.

In both cases, granting broader standing permissions may be unnecessary, but the all-or-nothing share outcome can make that the lowest-friction path.

Proposed direction: recipient-driven constrained derivation

If recipient authorization fails, keep denial as the default.
Optionally allow a second path only when the owner has pre-enabled it:

1. Recipient requests a constrained version.
2. Recipient declares only capabilities they choose to disclose as already held.
3. Owner/system attempts derivation under those declared capabilities.
4. Original artifact remains unchanged.
5. Owner is not shown recipient “missing permissions.”

Intended information-flow direction

Recipient
   │
declared capabilities
   ▼
Owner/system

Not:

Owner/system
   │
missing permissions
   ▼
Recipient

Non-goals

• Changing observer authorization semantics.
• Automatic permission escalation or access requests.
• Revealing missing permission sets to artifact owners.
• Replacing existing deny-by-default behavior.

Why this may align with observer principles

• Observer checks still gate direct sharing.
• No expansion of recipient privileges is implied.
• Collaboration remains inside platform controls.
• Least-privilege workflows may become easier than broad grants.

Risks / abuse considerations (for review)

I’d especially value feedback on whether this introduces new information-flow channels:

• Can repeated constrained-derivation attempts leak sensitive structure?
• How should capability declarations be validated/audited?
• Could over-sanitization create misleading artifacts that appear authoritative?
• Where should policy enforcement live (Gatekeeper, artifact pipeline, or both)?

Open questions

1. Is this a real workflow pain maintainers are already seeing?
2. Is this direction compatible with current Gatekeeper/observer boundaries?
3. Are there known information-flow pitfalls this overlooks?
4. Is related work already planned (partial sharing, constrained derivation, policy-mediated redaction)?
5. If worth pursuing, would a formal ADR/RFC in-repo be preferred over Discussion-first iteration?

---

If this is out of scope, I’d still appreciate guidance on the preferred long-term UX for collaboration when permissions overlap but do not match.

---

Link to LinkedIn article: https://www.linkedin.com/pulse/designing-safer-collaboration-ai-agents-people-from-openai-olajide-a0ede

[Ashutosh0x]

This is a great proposal. One thing worth calling out from a security perspective:

The current observer approval flow in session.ts constructs approval descriptions by interpolating server-controlled values (serverName, toolName, endpoint) directly into Markdown strings ? these bypass the quoteUntrusted() / codeSpan() / plainInline() sanitizers defined in tools.ts (see #42 and #129).

If observer-gated artifacts expand the set of approval prompts (e.g., "Agent X wants to share artifact Y with workspace Z"), the same pattern would apply: any user-controlled or server-controlled string rendered in an approval prompt needs to go through quoteUntrusted() to strip Markdown injection payloads (HTML tags, bidi overrides, horizontal rules, strikethrough).

For the token-signing aspect of observer gates, a few considerations:

• Nonce binding: each approval token should be bound to a specific (action, resource, requester) tuple and single-use, to prevent replay
• Expiry: short-lived tokens (e.g., 5 minutes) limit the window for approval token theft
• Integrity: HMAC-SHA256 over the approval payload using the Durable Object's key material would be lightweight and sufficient ? no need for asymmetric crypto here since the signer and verifier are the same DO

The existing connectionGeneration counter pattern in account.ts (used to invalidate stale OAuth connections) could serve as a model for approval token versioning.