Problem
The organization_admin default permission set carries a wildcard superuser grant (packages/plugins/plugin-security/src/objects/default-permission-sets.ts ~L150-160):
objects: {'*': {allowRead: true,allowCreate: true,allowEdit: true,allowDelete: true,viewAllRecords: true,modifyAllRecords: true,},
...
}and is auto-granted to everysys_member whose role contains owner/admin (plugin-security/src/auto-org-admin-grant.ts). The viewAllRecords/modifyAllRecords superuser bit short-circuits Layer 1 business RLS and sharing.
In the isolated posture, Layer 0 contains it (the W2 fix, cloud #2937 lineage — tenant-layer.ts requires the PLATFORM_ADMIN rung to cross the wall). But in any wall-less posture (single, or a hand-built multi-org shape) nothing contains it. Combined with automatic personal-org creation on signup, a wall-less multi-org deployment makes effectively every user an environment-wide superuser while operating in an org where they hold owner/admin.
Verified on main (2026-07-27). This is finding F2 of ADR-0105; the ADR marks it P0, shipping in the open edition independent of the rest of the ADR (decision D4).
Fix direction (ADR-0105 D4)
viewAllRecords/modifyAllRecords mean "bypass ownership, sharing, and business RLS within the caller's org access set" — never "cross the org boundary".- The Layer 1 superuser bypass no longer implies skipping the org predicate in any posture where one applies (already true in
isolated per ADR-0095 W2; extend the invariant). - Wall-less postures get a de-VAMA'd
organization_admin variant from auto-org-admin-grant, closing the personal-org amplification path. - Crossing org scope remains exclusively the
PLATFORM_ADMIN rung on posture-permitting objects — unchanged.
Risk / guardrail
D4 touches the superuser hot path. Land behind the authz-matrix-gate snapshot exactly as ADR-0095 did — any visibility delta outside the intended F1/F2 corrections is a bug.
Acceptance
Refs: ADR-0105 (F2/D4), ADR-0095 (W2), ADR-0066 (superuser bypass), cloud #2937.
Problem
The
organization_admindefault permission set carries a wildcard superuser grant (packages/plugins/plugin-security/src/objects/default-permission-sets.ts~L150-160):and is auto-granted to every
sys_memberwhose role containsowner/admin(plugin-security/src/auto-org-admin-grant.ts). TheviewAllRecords/modifyAllRecordssuperuser bit short-circuits Layer 1 business RLS and sharing.In the isolated posture, Layer 0 contains it (the W2 fix, cloud #2937 lineage —
tenant-layer.tsrequires thePLATFORM_ADMINrung to cross the wall). But in any wall-less posture (single, or a hand-built multi-org shape) nothing contains it. Combined with automatic personal-org creation on signup, a wall-less multi-org deployment makes effectively every user an environment-wide superuser while operating in an org where they hold owner/admin.Verified on
main(2026-07-27). This is finding F2 of ADR-0105; the ADR marks it P0, shipping in the open edition independent of the rest of the ADR (decision D4).Fix direction (ADR-0105 D4)
viewAllRecords/modifyAllRecordsmean "bypass ownership, sharing, and business RLS within the caller's org access set" — never "cross the org boundary".isolatedper ADR-0095 W2; extend the invariant).organization_adminvariant fromauto-org-admin-grant, closing the personal-org amplification path.PLATFORM_ADMINrung on posture-permitting objects — unchanged.Risk / guardrail
D4 touches the superuser hot path. Land behind the
authz-matrix-gatesnapshot exactly as ADR-0095 did — any visibility delta outside the intended F1/F2 corrections is a bug.Acceptance
authz-matrix-gatesnapshot delta reviewed and limited to the intended corrections.Refs: ADR-0105 (F2/D4), ADR-0095 (W2), ADR-0066 (superuser bypass), cloud #2937.