Do not mention the experiment because this column will exist after the experiment goes live. Just mention that some deployments may want revoke what is considered "normal permissions"

Done. Rewrote the comment to drop the experiment reference and focus on the durable purpose: deployments can use this column to revoke capabilities that would otherwise be considered normal organization member permissions.

Existing orgs are backfilled this way

P1 [CRF-1] No validation that entries in DefaultOrgMemberRoles are legitimate role names. Two traced consequences:

1. Privilege escalation. With the experiment enabled, PATCH /organizations/{id} with {"default_org_member_roles": ["organization-admin"]} stores the value. GetAuthorizationUserRoles produces organization-admin:<org_id> for every member. rolestore.Expand resolves it against builtInRoles (roles.go:32, 543). Every member gets org-admin permissions. Individual role revocation is defeated: a demoted admin retains privileges through this column.

2. DoS. A role name containing a colon (e.g., "foo:bar") produces foo:bar:<org_id> after SQL concatenation. RoleNameFromString (roles.go:79) rejects it with "too many colons." The error propagates through UserRBACSubject to the apikey middleware (apikey.go:474), which returns a hard 500 for every authenticated request from every member of the org. Recovery requires direct database access.

The experiment gate limits blast radius today, but provides no structural protection against misuse. Compare with putMemberRoles, where canAssignRoles validates every role name against the built-in registry and checks ActionAssign on ResourceAssignOrgRole.

Fix: validate each entry against rbac.RoleByName(RoleIdentifier{Name: role, OrganizationID: org.ID}) before writing. Consider constraining to a subset of rbac.DefaultOrgMemberRoles since the stated purpose is shrinking the floor, not granting arbitrary roles. (Hisoka P1, Kurapika P1, Mafuuu P2, Meruem P2, Knov P2, Knuckle P2, Razor P2, Pariston P3, Bisky P3)

🤖

This is a good callout. We need to check if the role can be assigned by the caller

Done. Two-layer fix in 4d52fbe8b8:

API layer (enterprise/coderd/organizations.go): added a built-in-only validation after the experiment gate. Each entry in req.DefaultOrgMemberRoles must resolve via rbac.RoleByName; anything else (custom role, malformed name with extra colons) returns 400 Invalid default_org_member_roles entry. This blocks the DoS attack path directly: "foo:bar" never reaches the SQL. Callout comment notes the temporary restriction so a future change can extend to custom org roles. Test in enterprise/coderd/organizations_test.go::TestPatchOrganizationsByUser/DefaultOrgMemberRoles/NonBuiltInRoleRejected.

dbauthz layer (coderd/database/dbauthz/dbauthz.go): rewrote UpdateOrganization to (1) authorize ActionUpdate on the org, then (2) when DefaultOrgMemberRoles differs from the existing value, compute the added/removed diff (as rbac.RoleIdentifiers scoped to the org) and route through the same canAssignRoles helper used by InsertOrganizationMember and UpdateMemberRoles. So the caller must hold ActionAssign on ResourceAssignOrgRole.InOrg(orgID) and must individually pass rbac.CanAssignRole for each added or removed role. This closes the escalation path: even with the experiment on, a non-admin caller can't slip organization-admin into the default set unless they were already permitted to assign org-admin individually. Test in coderd/database/dbauthz/dbauthz_test.go::UpdateOrganization now asserts both ActionUpdate and ActionAssign are required.

Replaced the hand-rolled defaultOrgMemberRolesDiff with rbac.ChangeRoleSet per Steven's review. The dbauthz UpdateOrganization path now wraps the stored []string as RoleIdentifiers via a tiny scopedOrgRoleIdentifiers helper and passes them straight through rbac.ChangeRoleSet -> canAssignRoles. Head: e6dfeb2988.

P3 [CRF-2] DefaultOrgMemberRoles is an exported mutable var slice used in security-relevant comparisons.

var DefaultOrgMemberRoles = []string{orgWorkspaceAccess}

The experiment gate in patchOrganization (organizations.go:70) compares the request against this value via slices.Equal. dbgen.Organization uses it as the creation default. Any code path that mutates the backing array (append, index assignment, variable reassignment) silently corrupts both the gate comparison and the creation default for all subsequent requests.

No current code mutates it, but Go exported var slices are a known mutation hazard. Seven of twelve reviewers flagged this independently.

Fix: return a copy from a function:

func DefaultOrgMemberRoles() []string { return []string{orgWorkspaceAccess} }

All six call sites change from rbac.DefaultOrgMemberRoles to rbac.DefaultOrgMemberRoles(). (Hisoka, Kurapika, Meruem, Knov, Razor, Gon, Mafuuu)

🤖

Done in 4d52fbe8b8. Converted to a function returning a fresh slice on each call. Updated all 12 call sites (coderd/rbac/roles.go, coderd/database/dbgen/dbgen.go, enterprise/coderd/organizations.go, coderd/provisionerdserver/acquirer_test.go, coderd/httpmw/authorize_test.go x2, coderd/httpmw/organizationparam_test.go, cli/server_createadminuser_test.go x2, enterprise/coderd/organizations_test.go x2). Doc comment now also states the "sole authoritative source / every InsertOrganization site must supply this value" invariant per CRF-4.

P3 [CRF-4] Comment omits the sync invariant and authoritative-source documentation.

The PR description says the comment documents a sync requirement with the migration's column DEFAULT, but (a) no such sync requirement is stated in the comment, and (b) the column has no DEFAULT. The Go constant is the sole authoritative source of the default value. Every InsertOrganization call site must use it. A reader adding a new insert path or raw SQL script has no warning.

Suggested rewrite:

// DefaultOrgMemberRoles is the authoritative default for
// organizations.default_org_member_roles. The column has no DB-level
// DEFAULT, so every InsertOrganization call site must supply this value.

(Gon, Leorio)

🤖

Folded into the CRF-2 change in 4d52fbe8b8. The new DefaultOrgMemberRoles doc comment reads:

// DefaultOrgMemberRoles is the deployment-wide default for the
// organizations.default_org_member_roles column, applied to every new
// organization at creation time. The column has no SQL DEFAULT, so this
// is the sole authoritative source: every InsertOrganization call site
// must supply this value unless a caller-chosen override is required.
// Returned as a fresh slice each call to prevent accidental mutation of
// the shared default through append or index assignment.

Nit [CRF-8] Guard comment restates the if-condition. The code is self-documenting: the three-line conditional with slices.Equal, rbac.DefaultOrgMemberRoles, and Experiments.Enabled(...) communicates intent clearly. The second sentence ("standard floor + organization-workspace-access elevation") references architectural terms that don't appear locally.

Suggested trim:

// Deviations from rbac.DefaultOrgMemberRoles require the
// minimum-implicit-member experiment.

(Gon)

🤖

Done in 4d52fbe8b8. Trimmed to your suggested:

// Deviations from rbac.DefaultOrgMemberRoles require the
// minimum-implicit-member experiment.

Nit [CRF-9] The doc comment // DefaultOrgMemberRoles, when non-nil, replaces the org's default member roles. produces confusing generated API docs. Codegen expands the CamelCase name, creating: "Default org member roles when non-nil, replaces the org's default member roles." The field name merges into the sentence, making "when non-nil" read like a conditional on the roles themselves.

Fix: // When non-nil, replaces the org's default member roles. (Leorio)

🤖

Keeping as-is for now. The codegen-friendly rewording is a worthwhile fix but is incidental to this PR; will land alongside the next codersdk-touching change.

Note [CRF-10] default_org_member_roles applies uniformly to all org members, including service accounts. When an admin shrinks an org's defaults for Gateway Accounts (e.g., removes organization-workspace-access), service accounts in that org also lose those roles. This aligns with the PR description's "per-org, not per-user" intent, but is worth confirming explicitly in the follow-up that gateway-account orgs won't have service accounts that need workspace access. (Pariston, Meruem, Razor)

🤖

Confirmed. By design: default_org_member_roles is per-org and unioned for both organization-member and organization-service-account. Shrinking the column affects every member of the org including service accounts. TestGetAuthorizationUserRolesUnionsDefaultOrgMemberRoles now exercises both code paths.

Note [CRF-11] The PR description states the migration adds a column with DEFAULT ARRAY['organization-workspace-access']::text[]. The actual migration adds the column without a DEFAULT, backfills existing rows, then sets NOT NULL. The Go code (rbac.DefaultOrgMemberRoles) is the sole authoritative source, supplied at every InsertOrganization call site. The NOT NULL constraint provides fail-closed behavior (raw SQL inserts that omit the column will fail). Consider correcting the PR description to avoid misleading future readers about the migration's behavior. (Leorio, Hisoka, Mafuuu, Meruem, Pariston, Razor)

🤖

PR description updated to reflect the actual nullable -> backfill -> NOT NULL pattern and the rbac.DefaultOrgMemberRoles() function as the sole authoritative source.