Security Model: ObjectStack uses a layered security model inspired by Salesforce. Permissions are evaluated in order: Object Permission → Organization-Wide Defaults → Record Ownership / Scope Depth → Sharing (rules + manual shares) → Row-Level Security → Field-Level Security. Unlike Salesforce, there is no automatic hierarchy layer — the business-unit tree widens access only where a sharing rule's unit_and_subordinates recipient or a scope-depth grant explicitly invokes it (positions are flat, ADR-0090 D3).

Super-user bypass: When modifyAllRecords is set it satisfies write checks (allowEdit/allowDelete, and the lifecycle class allowTransfer/allowRestore/allowPurge) on any record; viewAllRecords (or modifyAllRecords) satisfies allowRead on any record — both bypass ownership and sharing. See packages/plugins/plugin-security/src/permission-evaluator.ts.

The bypass is posture-gated for row-level security (ADR-0066 D2 ①): RLS policies are short-circuited only on objects whose posture permits it — access: { default: 'private' }, tenancy.enabled: false (platform-global), or better-auth-managed. On an ordinary tenant business object, authored and baseline RLS still applies (e.g. member_default's owner-scoped write policies keep org_member holders owner-scoped on update/delete even when another set grants modifyAllRecords), and the Layer 0 tenant wall always ANDs on top. See Sharing & OWD and plugin-security/src/security-plugin.ts (computeLayeredRlsFilter).

Lifecycle operations are pending: the transfer / restore / purge operations do not exist in ObjectQL yet (roadmap M2). Their RBAC gate is already mapped in the permission evaluator — the moment the operations ship they are denied unless the matching flag (or modifyAllRecords) is granted — but authoring these flags today grants nothing (#1883).

Enforcement status: only criteria rules are enforced today. Declared owner-type rules, and rules with group / guest recipients, are skipped at seed time with a warning (ADR-0049 — never silently advertised as live). See Sharing Rules.

Beyond declarative rules: Two other sharing mechanisms exist but are not SharingRule types. Manual sharing is a runtime grant — sys_record_share rows created with source: 'manual' (see packages/plugins/plugin-sharing/src/sharing-service.ts). Territories are a separate matrix model (TerritorySchema in packages/spec/src/security/territory.zod.ts) with their own account/opportunity/case access levels, parallel to the business-unit model. Owner/criteria rules are re-evaluated on insert/update via internal sharing rule hooks.

These are the only four canonical values (ADR-0090 D4). The legacy spellings read / read_write / full were removed — the conversion pipeline rewrites them to public_read / public_read_write on upgrade, and an unknown value resolves to private (fail-closed). A custom object that omits sharingModel resolves to private at runtime (D1), and os validate's security-posture check requires every custom object to declare it explicitly. These models are enforced by plugin-sharing + plugin-security and dogfood-proven over the real HTTP stack.

Opening Up Access: OWD restricts the baseline. Sharing rules, scope-depth grants, and manual sharing can only open up access — never restrict it further than the OWD.

Performance: For reads, steps 2–6 are compiled into a query filter (owner-match ∪ materialized shares, AND-ed with RLS) at query time, not evaluated record-by-record. By-id writes are verified with a pre-image check: the target row is re-read through the write-scope filter before the mutation. This keeps security checks efficient even on tables with millions of rows.