fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using

[objectstack-fleet]

Closes #19942
Clause-②: no (narrowing)

What changed

The runtime now does what the published contract says. When an applicable policy declares no check, the write post-image check (step 3.6, computeWriteCheckFilter) compiles that policy's using as its check. This applies to the INSERT row, which is judged after beforeInsert, and to the new row of a by-id UPDATE. The contract is RowLevelSecurityPolicySchema.check: "defaults to USING clause if not specified". PostgreSQL has the same rule for a policy without WITH CHECK.

Before this change, the gate compiled only policies that declared check. Measured on the repro: with using: "record.status != 'closed'", an INSERT of status = 'closed' was admitted and stored.

Changes to packages/plugins/plugin-security:

• security-plugin.ts: a new selector, writeCheckPolicies, decides which applicable policies the post-image check compiles.
• security-plugin.ts: step 2.7 (the by-id pre-image gate) records its ownership-floor decision (preImageFloorOpts), and step 3.6 reads it.
• security-plugin.ts: the two early floor drops in computeLayeredRlsFilter (the public_read_write OWD and the covering controlled-by-parent master gate) now ask a single predicate, platformFloorYieldsToObjectWriteModel. The post-image check asks the same predicate. The pre-image behaviour is byte-identical.
• rls-compiler.ts: the compileFilter comment ("defaulting to using when omitted") now matches a reachable call path. "Declares check" is now tested with policyDeclaresClause, the same test the selector uses.

Zero edits under packages/spec, content/docs/** and content/docs/releases/**.

How a defaulted using composes, exactly

This covers one principal's check. The delegator's check (ADR-0090 D10) and the Layer 0 tenant post-image check are still AND-ed with it, unchanged.

1. Some applicable policy for the operation declares check. Only the declared checks take part, OR-combined. That is today's result, byte for byte. A USING-only sibling adds nothing to the check.
   • Under PostgreSQL's permissive OR, the sibling's using would be OR-ed in. That can only widen the check: a grant spelled id != null would erase every declared check beside it.
   • The narrower reading was taken. It is an open question for the seat; see the report.
2. No applicable policy declares check. Every applicable write-class policy with a using takes part, its using compiled as its check, OR-combined.
3. The platform ownership floor (owner_only_writes) takes part in case 2 exactly when the by-id pre-image gate kept it.
   • It is dropped when the declared write authority answered allow (an edit-depth share, modifyAllRecords), on a public_read_write OWD, and under a covering controlled-by-parent master gate. Otherwise it stays in.
   • Why it stays: an app-authored USING-only update policy is used as a WIDENER, OR-ed with the floor at the pre-image. Leaving the floor out of the check would turn that widener into a restriction on the creator's own rows.
   • Why it is dropped in those three cases: keeping it would refuse, one step later, the cross-creator writes that Row-level write gate consults neither modifyAllRecords nor sys_record_share.access_level — both declared write-widening mechanisms are inert #5492, A controlled_by_parent detail's own ownership floor is never droppable, so a cross-creator by-id UPDATE of a child is refused before the master gate — Modify All Data included #8757 and assertControlledByParentWrite's master write-RLS leg keeps the platform ownership floor, so a principal who may PATCH a master by id is refused on its children (#8679 divergence, sibling leg) #8865 opened.
4. Unchanged.
   • select policies never gate a write's new row.
   • A bulk update with no single id is still not post-image checked.
   • The modifyAllRecords bypass on private and platform-global objects returns before the selector runs.

Census (the triage's p0 condition), tree aeaaa44292

Added by the seat after the contract review: the census also covers two published authoring factories in packages/spec/src/security/rls.zod.ts:613-666. RLS.ownerPolicy (operation: 'all', USING-only) and RLS.allowAllPolicy (all, 1 == 1) both emit write-class USING-only policies. Their defaults see no reachable change: 1 == 1 is always true, and owner_id is stamped and guarded by step 3.5. A caller who passes a custom ownerField to RLS.ownerPolicy is now held to it on writes.

Searched: packages/**, examples/**, apps/**, the published skills/**, and the CLI and create-objectstack scaffolds. The table lists every write-class (insert / update / all) policy that declares using and no check.

Where	Policy	Operation	using	Tenant isolation?	Reachable write, and what now happens
plugin-security member_default	owner_only_writes (platform floor)	update, org_member	created_by == current_user.id	no (ownership)	Takes part only where the pre-image kept it (rule 3). An update that re-points created_by away from the caller is now refused.
plugin-security member_default, organization_admin	sys_user_preference_self	all	user_id == current_user.id	no (self)	Yes, allowCreate / allowEdit are granted. A preference row created for another user, or moved to another user, is now refused (403). It was admitted.
plugin-security member_default, organization_admin	sys_api_key_self	all	user_id == current_user.id	no (self)	The member revoke patch (#8053). A patch that also carries user_id of another user is now refused (403). It was admitted with user_id stripped later; see the dogfood change below.
plugin-security member_default	sys_user_self	all	id == current_user.id	no (self)	Self edit of sys_user (whitelisted columns). The new row keeps its id, so there is no change.
plugin-security member_default, organization_admin	sys_session_self, sys_two_factor_self, sys_device_code_self, sys_oauth_consent_self, sys_oauth_application_self	all	user_id == current_user.id	no (self)	Not reachable today. These are better-auth managed tables, and both sets deny create and edit at the object layer (denyWritesOnManagedObjects).
plugin-security member_default, organization_admin	sys_organization_self	all	id == current_user.organization_id	borderline, see below	Not reachable today. Create and edit on sys_organization are denied at the object layer for both sets.
packages/metadata/src/__fixtures__/hotcrm-17.1-built-permissions.artifact.json (a fixture, not shipped)	marketing_campaign_updates, marketing_campaign_member_updates	update	id != null	no	Always true, so there is no change.

No write-class USING-only policy was found in examples/app-showcase (task_own_rows and invoice_own_rows are select; invoice_owner_immutable declares check), packages/verify (a select probe), skills/objectstack-data/rules/security.md (own_records declares check; org_isolation is select) or any CLI scaffold.

Tenant-isolation verdict: the p0 condition does not fire.

• Every shipped organization_id == current_user.organization_id policy is select: sys_member_org, sys_invitation_org and sys_team_org.
• The tenant wall is Layer 0, and it has its own post-image write check (step 3.7). The [finding] $ne with an array comparand splits across backends: driver-sql and driver-memory refuse (400), driver-mongodb answers, formula matches every row — and both shared faces pass it #19886 stage-1 measurement (P3) recorded a forged-organization INSERT refused 403 by it.
• The one borderline row is sys_organization_self. It compares against current_user.organization_id, and it is in the platform's own tenant-policy provenance set (isPlatformTenantPolicy, which strips it when isolation is off). But:
  • it scopes the organization table to its own row, and the declaration's own comment says these carve-outs "are NOT tenant walls";
  • writes to that table are refused at the object layer for both sets that carry it.
• Listed so the seat can judge it rather than find it.

Writes refused after this change

A single-row INSERT or a by-id UPDATE whose resulting row falls outside the using of every applicable write-class policy, when none of those policies declares check. The refusal is 403 PERMISSION_DENIED, the existing row-level CHECK envelope, and nothing is stored. There is no transition switch. An author who wants a write to leave a policy's scope declares a check.

In the platform defaults, this reaches the sys_user_preference and sys_api_key rows in the census, and a created_by re-point under the floor.

Tests

Final head 19236d91ad.

New file packages/plugins/plugin-security/src/rls-check-defaults-to-using.test.ts. It uses a real ObjectQL engine and SecurityPlugin and runs on driver-sql (better-sqlite3) and driver-sqlite-wasm: 22 tests, 11 cells on each driver.

• The repro: USING-only record.status != 'closed' refuses an INSERT with status: 'closed'. The test asserts code: 'PERMISSION_DENIED' and status: 403, and that nothing is stored. It admits 'open'. The same holds for an insert-class policy.
• The UPDATE new row: moving an in-scope row to 'closed' is refused and the stored row does not move. An in-scope update is admitted.
• A tenant-style USING-only policy (organization_id == current_user.organization_id) refuses a cross-organization INSERT and admits one into the caller's own organization. Layer 0 is not armed in this harness, so the refusal comes from the defaulted check.
• A declared-check control: the policy is judged on its check, not on its using, as before.
• Composition: a USING-only sibling adds nothing to a declared check (rule 1).
• The floor: the creator still updates their own deal out of the widener's scope, and a non-creator admitted only by the widener cannot move the deal out of it (rule 3).

Fixture triage, two existing tests:

• security-plugin.test.ts, "owner_id is always auto-injected on insert": its tenant_isolation policy is all and USING-only. The insert payload now carries the caller's organization, which the org-scoping stamp would write before the check, and the test asserts it arrives unchanged.
• packages/qa/dogfood/test/api-key-owner-revoke.dogfood.test.ts: the mixed smuggle patch is split in two. Re-owning (user_id of another user) is refused 403 PERMISSION_DENIED and changes nothing. key smuggled beside revoked is still admitted with key stripped.

Reverse verification. Each run used scripts/ablation-replace.mjs from committed state, and each restore was proven: the blob equals HEAD and git diff HEAD is empty.

Mutation	Result
The using fallback in writeCheckPolicies replaced with an empty list (the pre-fix behaviour)	10 failed, 12 passed of 22. Every refusal witness failed on both drivers: the repro, the insert-class policy, the UPDATE new row, the cross-organization INSERT and the widener non-creator. All admit controls stayed green.
The floor excluded unconditionally	3 failed: the creator cell on both drivers, plus authored-row-write-verdict.test.ts "TRANSFERRED_UPDATE_IS_ADMITTED_BY_THE_COMPOSED_PATH".
The floor kept unconditionally (the pre-image drop ignored)	8 failed across the whole plugin-security suite: 6 in controlled-by-parent-detail-write-authority.test.ts (#8757 / #8865) and 2 in row-write-widener-composition.test.ts (#5492).

Suites and gates:

• pnpm --filter @objectstack/plugin-security test: 121 files, 2314 tests passed.
• pnpm --filter @objectstack/plugin-security typecheck: exit 0, and check:test-typecheck OK.
• @objectstack/organizations test: 108 passed. @objectstack/plugin-sharing test: 913 passed.
• @objectstack/dogfood, full run before the dogfood fix: 1 failed (the case above), 1102 passed. After the fix, that file passes 9 of 9.
• eslint on the 5 touched TypeScript files: 0 errors and 0 warnings, read from --format json. The config is not type-aware (no parserOptions.project), so this narrowing leaves no untouched file's verdict unmeasured. The full pnpm lint is left to CI.
• node scripts/pm/dispatch-gates.mjs --commands: 66 derived commands. 64 exited 0. 2 exited 3, which is PREREQUISITE NOT MET and so NOT MEASURED: check:dual-build-cjs-loads and check:type-check-debt need a whole-workspace build.

Acceptance notes

• packages/lint/src/validate-rls-predicate-enforceability.ts, header item 4, still says computeWriteCheckFilter "collects only the policies that declare a check". It is a comment, now incomplete. The rule's using consequence text does not mention that an uncompilable using on an insert / all policy with no check now also refuses every insert (it fails closed). Carrier: none.
• The update post-image is still the caller's payload merged with the pre-image, judged before beforeUpdate (plugin-security: the UPDATE-side RLS check post-image is pre-image + change set evaluated before beforeUpdate, so a hook-stamped scoping field can move a row into an organization the caller does not hold #16790). The sys_api_key case shows the effect: a column the D2 whitelist would strip now refuses the patch at the check instead.
• The spec describe and the two reference pages say an omitted check "defaults to USING". That is now true, except in the mixed case of rule 1. The mixed case is raised in the report, not edited here.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-security, touching 6 documentable anchor(s).

6 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/permissions/field-level-security.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/permissions/index.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/permissions/permissions-matrix.mdx (via computeLayeredRlsFilter (symbol, a method of class SecurityPlugin))
• content/docs/permissions/sharing-rules.mdx (via computeLayeredRlsFilter (symbol, a method of class SecurityPlugin))
• content/docs/plugins/packages.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/ui/forms.mdx (via SecurityPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via SecurityPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 15 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json c1641868a3da71537c9c6c572d2bd2044103236b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c6e3661a6abec88181444dcb04ded8a1cbb2278a — the merge of head 62d12779800c9baa147fc5e3367fffca38b0aac3 into base c1641868a3da71537c9c6c572d2bd2044103236b, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin c6e3661a6abec88181444dcb04ded8a1cbb2278a && git checkout c6e3661a6abec88181444dcb04ded8a1cbb2278a
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c1641868a3da71537c9c6c572d2bd2044103236b 62d12779800c9baa147fc5e3367fffca38b0aac3 && git checkout -B drift-repro c1641868a3da71537c9c6c572d2bd2044103236b && git merge --no-ff 62d12779800c9baa147fc5e3367fffca38b0aac3

node scripts/docs-audit/affected-docs.mjs --json c1641868a3da71537c9c6c572d2bd2044103236b

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs c1641868a3da71537c9c6c572d2bd2044103236b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 62af5581f92a7ef0e365357276ddfe358689f7f8

The review ran in two rounds, by an isolated reviewer at the served tier. The reviewer saw only card #19942 (triage 5806292861, claim 5806865969, os-dev report 5807642793), this PR, and the repository rules. The domain:services seat adopts the verdict.

• Round 1, at 19236d91ad: FAIL. One blocking defect: the change was declared Clause-②: no with a patch changeset, but it narrows what the write gate accepts.
• Round 2, at this head: the delta reviewed is 19236d91ad..62af5581f9, which is changeset-only, plus the PR body the seat edited.

① Derived judgments

• Composition (writeCheckPolicies):
  • If any applicable policy declares check, only the declared checks decide, byte-identical to today.
  • Otherwise, each applicable write-class policy's using becomes its check, and they are OR-combined.
  • The ownership floor is tied to the decision step 2.7 records.
  • The runtime implements ADR-0058 D4's 「defaulting to using when omitted」.
• Newly admitted writes: none. The only change turns a null check into a filter, which can refuse and never admits.
• Newly refused writes, all stated in the changeset:
  • any USING-only write-class policy;
  • the platform _self policies: sys_user_preference user_id forgery, and the sys_api_key re-owner patch, which now returns 403;
  • a by-id UPDATE re-pointing created_by under the ownership floor. Before, the readonly strip removed the value silently; now the post-image is judged first and the write returns 403 (plugin-security: the UPDATE-side RLS check post-image is pre-image + change set evaluated before beforeUpdate, so a hook-stamped scoping field can move a row into an organization the caller does not hold #16790).
  • an uncompilable using on an insert/all policy with no check, which now refuses every insert (fail-closed).
• Census: no shipped tenant-isolation policy is USING-only on a write class. Every _org policy is select, and sys_organization is managed by better-auth. The published factories RLS.ownerPolicy / RLS.allowAllPolicy (rls.zod.ts:613-666) are named in the PR census; their defaults have no reachable change. Triage's p0 condition does not fire.
• Mixed-case divergence: a USING-only sibling beside a declared check contributes nothing. That diverges from the per-policy wording in the describe, the TSDoc, rls.mdx, permission.mdx and ADR-0058 D4. It is pre-existing, fail-closed and accepted for landing. It is carried by spec(security): RLS check defaults to using per policy in the contract, but the write check ignores a USING-only policy when a sibling declares check — state the composition, or rule OR semantics #19953, together with the stale validate-rls-predicate-enforceability.ts:32-33 header.

② Semver level

minor plus fix(plugin-security)!: and a BREAKING banner. The changeset and the PR body both carry Clause-②: no (narrowing), and there is exactly one ADR-0087 marker, not-required (no-migration-prescription). This matches the precedent a016f08 (#16805), clause2-line.mjs, AGENTS.md:1084-1096, and check-changeset-no-major.mjs:47-75.

Gates at this head:

• check-adr-0087-registration ✓ [BREAKING+bang+clause-②-narrowing]
• check-changeset-no-major ✓ no major. The level axis reads the narrowing arm from the PR body.

③ Boundary flags

The PR touches six files: the changeset, 4 files under packages/plugins/plugin-security/src/, and one dogfood test (a fixture that had to change). Zero packages/spec, zero content/docs/**, zero governed surface. The scope matches triage.

Implemented-by: claude/issue-19942-rls-check-defaults-to-using
Reviewed-by: session_01AhQASwqJr2Z7XfGWUdvnbF

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 62d12779800c9baa147fc5e3367fffca38b0aac3

What this record covers: this head, 62d1277980. The earlier record for 62af5581f9 covers the full PR. This round reviews only the delta 62af5581f9..62d1277980, which fixes the two CI reds at that head. The same isolated served-tier reviewer did the review, and the domain:services seat adopts the verdict.

① Derived judgments

• security-plugin.ts is comment and placement only, and this was proven. With block and line comments stripped, the two blobs are byte-identical. The [ADR-0095 D1] docblock is back above computeRlsFilter. The helper now cites commit 6feac910b6 (which exists, dated 2026-08-15) instead of #8757, which is allocated-but-absent (404). The prose says so. The full diff adds no #8757 citation.
• The plugin-auth pins are tightened, not weakened. Every touched pin still asserts exact values. Pin 1 keeps [0] = { $and: [{ id: ME }, { id: ME }] } unchanged and adds [1] = { id: ME }. The org-peer absence assertions now hold over both reads. The guard pin matches the full array exactly.
• The second read cannot widen anything. It is step 3.6's memoized getCallerPreImage → readRowById, a bare { id } read under the caller's context (security-plugin.ts:3087, :5991, :6009-6015). It runs only after step 2.7 has admitted the row. Its only consumer is satisfiesCheck(postImage), which can refuse and never admits. It exists because sys_user_self (all, USING-only) now gets the defaulted check.
• PIN 2 (the peer row) is untouched and is still refused at the row scope with a single read. The insert pin is still [].
• The changeset needs no change. The own-row update is still admitted, and the refused-writes list is complete. The changeset blob is unchanged, so the ADR-0087 and no-major verdicts from the previous head carry.

② Semver level

Unchanged and correct: minor, fix(plugin-security)!:, a BREAKING banner, and Clause-②: no (narrowing) in both the PR body and the changeset. There is exactly one ADR-0087 marker, not-required (no-migration-prescription).

③ Boundary flags

The full diff is 7 files: the changeset, 4 plugin-security source files, the dogfood test, and the plugin-auth test. It touches zero packages/spec, zero content/docs/** and zero governed surface. The plugin-auth pin update is fixture triage forced by the defaulted check. The mixed-case composition divergence and the stale lint header are carried by #19953.

Implemented-by: claude/issue-19942-rls-check-defaults-to-using
Reviewed-by: session_01AhQASwqJr2Z7XfGWUdvnbF

VERDICT: PASS

---

Generated by Claude Code