[mrunalp]

Human merge required. Agents must not merge this RFC or enable automatic merging. A human must manually click Merge.

Problem

Every OCE capability starts with an Installation administrator. External sign-in admits only identities attached to accounts an administrator created first, only the bootstrap administrator can create Namespaces, and only an Installation administrator can give an Agent's service account operate on its Secrets and credential sources (MEMBER_GRANT_REFUSED). IAM already evaluates Group bindings, but nothing writes Groups.

Change

Adds RFC-0026: Default users sign in through identity provider mappings and own their Namespaces and its row in specs/README.md. The RFC proposes:

• Administrator mapping rules from GitHub, Google, and OIDC provider groups to OCC Groups, applied at each sign-in. Accounts are created for matched identities, and mapped memberships follow the provider.
• A built-in Default User Role (namespace:create) bound to a Default users Group, and built-in Namespace member and Namespace owner Roles. The creator of a Namespace becomes its owner, up to a configured limit.
• Team Namespaces whose mapped Group holds the Namespace member Role.
• At deploy, OCC writes the Agent's exact operate grants only when a built-in Namespace Role allows the caller, so existing custom Roles gain nothing. OCC removes those grants when nothing references the source anymore.
• Members and owners can edit Agent sandbox network additions within the Installation ceiling until the Guardrails work adds Namespace ceilings.
• Personal or shared connection templates, so the Namespace protects connected OAuth accounts instead of per-Agent ownership checks.

Existing sign-in flows, allowlists, and administrator-created accounts and Namespaces are unchanged. The built-in Roles, Group writes, and account creation at sign-in change the IAM Driver contract. Template sharing changes the RFC-0023 connection template contract. This draft is opened for early feedback. Implementation will follow in separate PRs.

Verification

Documentation only. Prettier --check passes on the changed files. The repository word counter could not run locally because @sindresorhus/slugify is missing. An approximate count puts the RFC under the 2,500-word limit.

Risks

None at merge time; the RFC changes no code. The proposal widens who can create Namespaces and grant Agent access. The RFC limits this to built-in Roles that only OCC or an Installation administrator can bind, and it lists the open questions for product and security review.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR proposes provider-mapped account provisioning, Namespace ownership, automatic Agent credential grants, and personal or shared OAuth connections.

Example: An Installation administrator maps GitHub team acme/platform to Default users.

• Before: A new team member needs an administrator-provisioned account and cannot independently create and own a Namespace.
• After: Under the proposal, the member receives an account at sign-in and can create a Namespace with its owner Role.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The proposal is grounded in current source and introduces no runtime regression; minor documentation corrections and an unresolved product decision remain.
Proof confidence	🐚 platinum hermit (4/6)	This documentation-only RFC explicitly defers implementation and specifies future PostgreSQL, Keycloak, and Kubernetes workflow verification; it makes no claim of implemented runtime behavior.
Patch quality	🐚 platinum hermit (4/6)	2 actionable review findings remain.

Product

Kind: Feature · Worth it: Needs a maintainer decision
User problem: Ordinary team members need administrator intervention to obtain an account, create a usable Namespace, and grant their Agents access to credentials.
Reason: The problem is source-backed, but the proposed Roles, mapping settings, delegation authority, and OAuth sharing semantics are new product contracts without recorded owner approval.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep this draft open for maintainer discussion: it addresses a verified capability gap, has two minor documentation defects, and leaves substantive access-model decisions unresolved.

Priority: P2
Reviewed head: df40b69f6dea435e31d73e4947ae862f6ff01f92
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should OCE adopt provider-mapped Default users and Namespace ownership with automatic credential delegation, and should Namespace isolation replace the personal-Agent OAuth restrictions?
• Recommendation: Review the connected onboarding model: Decide the member and owner authority, offboarding behavior, and administrator access to connected accounts together with the IAM and OAuth proposal owners.
• Why: The draft deliberately expands account admission and delegation, while administrator access to personal connections remains unresolved; neither this PR's discussion nor the overlapping proposals records owner acceptance.

Before merge

• Reference the proposal that owns connection templates (P3) - RFC-0023 defines Credential Proxy and credential lifecycle contracts, not connection templates. The templates and personal-Agent checks being changed are proposed in RFC-0024: Connect a user's OAuth account to a personal Agent #3068. Link that proposal here so reviewers and the later implementation plan identify the correct contract dependency; its provisional RFC number can change.
• Update the RFC inventory total with the added row (P3) - Adding this Not implemented RFC increases the index to 26 entries, but the summary at line 39 still reports 10 implemented, 8 partially implemented, and 7 not implemented. Change the last total to 8 so the overview agrees with its inventory.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

• [P3] Reference the proposal that owns connection templates — specs/rfcs/0026-default-users.md:267-269
• [P3] Update the RFC inventory total with the added row — specs/README.md:68

Agent review details

How this fits together

OCC authenticates provider identities, evaluates resource permissions through the selected IAM Driver, and manages Namespaces and Agent deployments; the proposal connects provider membership to account creation, Roles, and credential delegation.

flowchart TB
A[Identity provider] --> B[OCC sign-in]
B -. Proposed mappings .-> C[Accounts and Groups]
C -. Proposed Roles .-> D[Namespace ownership]
D -. Proposed deploy grants .-> E[Agent ServicePrincipal]
E --> F[Secrets and credential sources]

Loading

Technical review

Best possible solution:

Resolve the onboarding and delegation model with the existing IAM owners, coordinate the overlapping proposals, and retain explicit Proposed status until a decision is recorded.

Do we have a high-confidence way to reproduce the issue?

This is a feature proposal; current-main source confirms its motivating limitations without establishing a regression or requiring a runtime reproduction.

Is this the best way to solve the issue?

Building on existing IAM and Namespace owners is coherent, but the broader delegation and OAuth isolation choices require agreement with the overlapping proposals before this can define an accepted contract.

Full review comments:

• [P3] Reference the proposal that owns connection templates — specs/rfcs/0026-default-users.md:267-269
  RFC-0023 defines Credential Proxy and credential lifecycle contracts, not connection templates. The templates and personal-Agent checks being changed are proposed in RFC-0024: Connect a user's OAuth account to a personal Agent #3068. Link that proposal here so reviewers and the later implementation plan identify the correct contract dependency; its provisional RFC number can change.
  Confidence: 0.99
• [P3] Update the RFC inventory total with the added row — specs/README.md:68
  Adding this Not implemented RFC increases the index to 26 entries, but the summary at line 39 still reports 10 implemented, 8 partially implemented, and 7 not implemented. Change the last total to 8 so the overview agrees with its inventory.
  Confidence: 1

Overall correctness: patch is correct
Overall confidence: 0.94

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 2b3b206b6352.

Security

None.

Evidence

What I checked:

• Pinned change and policy: The introduced diff adds one RFC and its index row, with no runtime changes. Root AGENTS.md was read completely; no nested AGENTS.md or maintainer-notes directory was found for these paths. The requested single-reviewer restriction was honored. (specs/rfcs/0026-default-users.md:1, df40b69f6dea)
• Current sign-in requires an attached account: snapshotExternal looks up the exact provider and subject in occ.account and returns undefined when no attachment exists; it does not provision an account. Existing PostgreSQL authentication coverage also asserts refusal of a missing subject. (packages/occ/src/state/human-authentication.ts:612, 2b3b206b6352)
• Current Namespace creation: createNamespace checks namespace:create, creates the Namespace, initializes default Presets, and queues reconciliation without creating an owner binding. The authoritative design distinguishes implemented IAM from remaining platform capabilities. (packages/occ/src/index.ts:4676, 2b3b206b6352)
• Overlapping proposals remain unmerged: RFC-0025: Optional Namespace Agent author role #4045 proposes an explicitly assigned Namespace Agent Author Role, while RFC-0024: Connect a user's OAuth account to a personal Agent #3068 proposes browser OAuth connections and personal-Agent restrictions. Their bodies and relevant discussion establish overlapping decisions, not an implemented replacement for this proposal.
• Connection-template contract attribution: RFC-0023 defines Credential Proxy admission, credential preparation, and dispatch; it does not define connection templates. Those templates and personal-Agent restrictions are proposed in RFC-0024: Connect a user's OAuth account to a personal Agent #3068. (specs/rfcs/0026-default-users.md:269, df40b69f6dea)
• Feature ownership history: Merged history shows freeqaz-openai's existing-account external sign-in work and kevinlin-openai's Namespace IAM management and guided provisioning work. Local content-history searches and blame encountered unavailable older blobs; GitHub commit patches independently verified the retained authored lines used for routing. (packages/occ/src/state/human-authentication.ts:612, 0586167bd78c)

Labels

Label changes:

• add P2: This is a substantive architectural improvement requiring normal-priority owner review, with no shipped runtime regression introduced by the documentation patch.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.

Label justifications:

• P2: This is a substantive architectural improvement requiring normal-priority owner review, with no shipped runtime regression introduced by the documentation patch.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed October 30, 2026, 10:40 AM ET / 14:40 UTC.

[kevinlin-openai]

• Members of the built-in Default users Group can create Namespaces, and each creator becomes that Namespace's owner

  • still conflicted about this. namespace per user provides nice isolation but this does mean that for 100k personal agents, we're creating 100k namespaces + related k8 resources which means we'll need to shard k8 clusters. we want to support this topology but hesitant to make it the default
• the pattern that creators of a resource should have all permissions of said resource should be a general rule and not a one off for namespaces

• An administrator marks each connection template personal or shared. OCC cannot tell from the provider whether an account belongs to one person, so the template decides how far a connection may reach:

  • doesn't make sense to me that we restrict connection templates. this as i understand it how a connection to a provider is setup, not the actual connection itself. connections can be personal vs shared, connection templates should not have that restriction
• we don't need to restrict role bindings without resources from fixed namespace roles - this should be a general capability. if specific resource binding is omitted, then the permission applies to all resources in a given namespace

[kevinlin-openai]

• what happens when membership is revoked from the oidc side or the oce side?

[mrunalp]

@kevinlin-openai thanks for the review. I updated the RFC in 5b76d71, after talking it through. Here is the result for each point:

• A Namespace for each person. It isn't the default anymore. Default users now get Agent create in the shared default Namespace, through a built-in Agent Creator Role. IAM keeps people apart at the resource level there, and the existing NetworkPolicies already stop one Agent from reaching another in the same Kubernetes namespace. An operator can still let people create their own Namespaces, with the Installation setting defaultUser.namespaceCreate (off by default). That supports the sharded topology without making it the default.
• Creators get every permission on what they create. This is now a general rule. Every create (Namespace, Agent, Configuration, Secret, credential source, Preset, ServiceAccount) binds the creator to one built-in Owner Role in the same transaction. The binding is exact for a resource and Namespace-wide for a Namespace. An Agent's revisions and sandbox policy are checked against the Agent's bindings, so an owner can read the revisions their own deploys create.
• Connection templates. Agreed. I removed the personal/shared template section. Templates and connection sharing are out of scope here and belong to the connections work.
• Bindings without a resource. Agreed. In the Namespace IAM API, resourceKind and resourceId become optional for any Role, and Group subjects are allowed. Leaving the resource out applies the binding to every resource in the Namespace whose kind the Role names. Bindings without a Namespace stay limited to the ones OCC writes for Installation-level permissions.
• Membership revoked on the OIDC side or the OCE side. Removal stops new creates and keeps what the person created: Owner bindings, Namespaces and Agents stay until an administrator deletes them or moves the Owner binding.
  • OCE-side changes (removing a membership, disabling an account) take effect on the next request.
  • Provider-side changes take effect at the next sign-in, and sessions stay capped at eight hours.
  • The Default users list shows each person's last mapped sign-in, so administrators can spot accounts the provider has disabled.
  • SCIM, through Better Auth's @better-auth/scim plugin, is the planned follow-up for providers that push changes.

Quotas and limits, including the Namespace limit from the earlier draft, move to a separate RFC.