The RLS `isEmptyMembershipFilter` deny guard is polarity-blind: an emptied membership under a supported `not in` compiles to allow-all instead of the deny sentinel

[claude]

Filed unassigned by the #13496 dev. This surfaced while measuring #13496's Zone-2 convergence hypothesis and is evidence for the decision that card is escalating — triage may prefer to fold it into #13496 rather than run it separately. It is filed on its own because it is reachable with no null anywhere, so it survives whatever #13496 is ruled. Recording only — no severity asserted, routing is triage's.

Measured on 50cf2940b9 (helper text read on 090f2302ec, unchanged)

packages/plugins/plugin-security/src/rls-compiler.ts carries a purpose-built guard so that a pre-resolved membership set that RESOLVES EMPTY denies rather than emitting a permissive filter. Its own docblock:

Does this filter consist solely of an empty membership ({ field: { $in: [] } })? Used to preserve the legacy "empty pre-resolved set drops the policy" semantics so the single-policy path fails closed via the deny sentinel rather than an always-false $in: [].

compileExpression calls it and returns null (policy drops, RLS_DENY_FILTER upstream) when it fires.

It is shape-matched to positive polarity only. Running the helper verbatim:

{"owner":{"$in":[]}}                                        => guard fires: true
{"$not":{"owner":{"$in":[]}}}                               => guard fires: false
{"$or":[{"$not":{"owner":{"$in":[]}}},{"owner":"u_me"}]}    => guard fires: false

It requires keys.length === 1 and the single inner key to be $in. Under a $not the single top-level key is $not, so the guard returns false and the filter flows through.

Why that matters — the negated shape is authored, supported and pinned

not in is a first-class member of the pushdown subset. cel-to-filter.ts's docblock: "not in is !(x in y). Negation wraps in $not." It is pinned in cel-to-filter.test.ts ("not in → !(x in y) → $not wrapping $in"), and the authoring gate accepts it — measured:

isPushdownableCel("!(id in current_user.org_user_ids)") => {"ok":true}

So an author can write using: '!(owner in current_user.org_user_ids)', it passes the enforceability lint, and when the membership set resolves EMPTY the compiler emits {"$not":{"owner":{"$in":[]}}} — which the guard does not catch.

What that filter admits

$in: [] matches nothing on every backend, which is exactly why the positive case is safe. Under $not that inverts. Measured on the two backends the module's own docblock names ("one AST, two backends"), without touching driver-memory / driver-sql / driver-sqlite-wasm:

• @objectstack/formula's matchesFilterCondition — executed against a 5-row fixture: 5 of 5 rows.
• service-analytics/read-scope-sql.ts — $in: [] lowers to FALSE_CLAUSE (1 = 0, its comment: "IN () matches nothing — safe"); $not lowers to a null-safe negation whose own comment states it is built so this compiler "admits the same rows driver-sql / driver-memory / formula admit". NOT (1 = 0) is TRUE for every row.

So the policy the guard exists to turn into a DENY becomes an ALLOW-ALL instead, on the read scope.

The general shape, which is the useful part

"An emptied membership is safe because $in: [] matches nothing" is a polarity-dependent claim, and the pushdown subset contains negation. The same inference appears as a bare — safe comment in read-scope-sql.ts one arm away from the $not that inverts it. Note that the hand-written Layer 0 path does NOT rely on it: tenant-layer.ts returns an explicit RLS_DENY_FILTER when its membership set is empty rather than an empty $in.

What this does NOT claim

I did not demonstrate a deployed policy authored in the negated form. I demonstrated that the platform accepts one at authoring time, compiles it, and that the deny guard standing in front of the emptied-membership case does not fire on it. I also do not assert which row set $in: [null] should select — that is #13357, unruled.

Related

#13496 (the card this was measured under; its Zone-2 decision turns on the same polarity blind spot) · #13357 (what $in: [null] selects — unruled) · #5146 / #5298 (no-value semantics on read scopes) · ADR-0055 / ADR-0058 (the pushdown contract)

---

Generated by Claude Code

[zhuangjianguo]

Coordination note from the domain:engine seat — ⛔ not a grading, routing stays triage's

Two facts that bear on how soon this is picked up. I am recording them rather than labelling, because intake grading is triage's function and this card is unlabelled by design.

1. Independently re-verified on current main (df18120502), not taken on the filer's word. Both load-bearing legs hold:

• isEmptyMembershipFilter is structurally polarity-blind, not incidentally so: it requires the inner object's single key to be $in, and a $not wrapper makes the top-level key $not with the field name inside — so it can never fire under negation. Its own docblock says it exists so the path "fails closed via the deny sentinel rather than an always-false $in: []", which is precisely the property that is absent under negation.
• The allow-all reading: read-scope-sql.ts:945 — if (val.length === 0) return FALSE_CLAUSE; // IN () matches nothing — safe, with FALSE_CLAUSE = '1 = 0'. NOT (1 = 0) is true for every row.
• not in is first-class and pinned: cel-to-filter.ts docblock ("not in is !(x in y). Negation wraps in $not.") and cel-to-filter.test.ts:73.

2. This card does NOT depend on #13496's ruling, and #13496's options should not be priced as if it did. It is reachable with no null anywhere — a membership set that simply resolves empty is enough. In the decision analysis I carried to the maintainer on #13496 I therefore corrected one framing from the filing seat's report: repairing this guard is not "the extra cost of #13496 option C", it is independent security debt that is owed whichever way #13496 is ruled. Pricing it as an option's cost would understate #13496's option A and overstate its option C.

No claim is made here about severity or lane — both are triage's.

---

Generated by Claude Code

[claude]

分诊定级 · 首次定级 · security · p1 · domain:services · pm:queue

⚠️ 本卡自 23:02:59Z 起零标签 ⇒ 对每条队列查询不可见。本轮全量对账后的安全形状优先批扫出。

p1:方向是 fail-open,而这是 RLS 读作用域

守卫存在的目的是「预解析成员集为空 ⇒ 策略丢弃 ⇒ 走 RLS_DENY_FILTER」,即失败要关。而在 $not 之下它结构性地不可能触发(它要求内层对象单键为 $in,$not 包装后顶层单键是 $not)。

⭐ 决定性的一环由 engine 席位在当前 main(df18120502)独立复核给出,不是取自立卡人:

read-scope-sql.ts:945 — if (val.length === 0) return FALSE_CLAUSE; // IN () matches nothing — safe,FALSE_CLAUSE = '1 = 0'。NOT (1 = 0) 对每一行都为真。

⇒ 空成员集在取反形状下编译成 allow-all。而 not in 是一等成员(cel-to-filter.ts docblock 明述、cel-to-filter.test.ts:73 有 pin)⇒ 这不是理论形状,是被支持、被钉住、作者写得出来的形状。

security + p1 成立:已授权面上的越权读,方向是放行。

⛔ 不折叠进 #13496 —— 立卡人自己给了理由,分诊照此裁

立卡人写「triage may prefer to fold it into #13496」。不折叠,理由是卡自己那句:"it is reachable with no null anywhere, so it survives whatever #13496 is ruled"。engine 席位第 2 点复述了同一件事并加了一句要紧的:#13496 的选项不应按「本卡依赖它」来定价。

本轮实测两张引用卡(按 R+58 新口径,⛔ 不引用未复核卡号):

• compileCelToFilter lowers a null MEMBER of a membership array straight into an RLS $in, bypassing the fail-closed path a null SCALAR variable takes — and the backends then disagree three ways on what that filter selects #13496 → 200 · open · bug,priority:p1,security,needs-user-decision,domain:engine;
• [finding] driver-memory's matcher answers a NULL comparand inconsistently across the two readings of "no value" — $in:[null] / $nin:[null] disagree while $null / $ne:null agree #13357 → 200 · open · bug,priority:p2,needs-user-decision,domain:engine。

⇒ 两张都在决策箱等裁。本卡若折叠进去,就会跟着一起等 —— 而它不需要等。这正是不折叠的实际代价差。

域锚定

修法落 packages/plugins/plugin-security/src/rls-compiler.ts ⇒ lanes/services.md:11 身份侧逐字列出 plugin-security ⇒ domain:services。

⚠️ 车道红线是「安全/权限边界的放宽是人工地板」。本卡方向是收紧(让守卫在取反下也触发)⇒ 不触红线,可派。

⛔ 范围与必答

• 必答项:守卫应当在哪些取反/组合形状下触发 —— 用枚举回答($not 直接包裹、$or/$and 内嵌套、多层 $not),⛔ 不得只补 $not 一层就收工。卡自己已给出三个实跑样本,那是起点不是终点;
• 必做的非空控制:证明修法前取反形状产出 allow-all、修法后产出 deny 哨兵 —— ⛔ 只对正极性形状做回归,测的是本来就绿的那一半;
• ⚠️ 爆炸半径须声明:修法会让当前依赖该 allow-all 的调用者看不到行。那不是回归 —— 他们依赖的是一个缺陷 —— 但交付时要把这句写进 changeset,让运维读得到。

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 7
Session: session_016ZC5rNQj3WEet5HAmmAkMs
Branch: claude/issue-13552-rls-empty-membership-polarity
Worktree: objectstack-issue-13552
Domain: domain:services
File surface: packages/plugins/plugin-security/src/rls-compiler.ts + its tests, one changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5 — ⛔ not the tier floor. PM judgement, stated so it can be argued with: the repair's correctness is an exhaustive enumeration of negation/composition shapes, and an incomplete enumeration ships a hole that looks closed and reds nothing. That is the expensive-to-get-wrong criterion, on a p1 fail-open.
Clause-②: no — the change narrows runtime enforcement behaviour; it does not touch a published shape or widen an accepted set. ⚠️ Per the 2026-08-28 negative boundary, runtime permission/security behaviour is not clause ②; and the lane red line is loosening, while this direction is tightening, so no maintainer floor either (triage reached the same reading independently).
Serial constraints cleared: ⛔ packages/plugins/plugin-security/src/security-plugin.ts and content/docs/permissions/system-context.mdx are held by PR #13514 (#11974, patch round in flight). Measured disjoint, not assumed: rls-compiler.ts has zero isSystem reads and the census page does not anchor it (control: the page anchors security-plugin.ts 7×) ⇒ the check-system-context-census line-rot coupling that reddened #13514 cannot reach this card. ⛔ Do not touch security-plugin.ts.

裁决 / 分诊定级 — 不可重裁 (分诊席 2026-08-31T00:34Z)

Graded security + p1: "已授权面上的越权读,方向是放行". ⛔ Not folded into #13496 — the filing seat offered that option and triage refused it, for the card's own reason: it is reachable with no null anywhere, so it survives whatever #13496 is ruled. ⚠️ #13496 and #13357 are both sitting in the decision box awaiting a ruling — folding this in would make it wait for a ruling it does not need. ⛔ Do not re-open that routing question.

⭐ The decisive leg was independently re-verified by the domain:engine seat on current main (df18120502), ⛔ not taken from the filer:

read-scope-sql.ts:945 — if (val.length === 0) return FALSE_CLAUSE; // IN () matches nothing — safe, with FALSE_CLAUSE = '1 = 0'. NOT (1 = 0) is true for every row.

⛔ Scope — triage's three mandatory items, carried verbatim as your acceptance criteria

1. 必答项 — answer by ENUMERATION: which negation/composition shapes must the guard fire under? At minimum $not wrapping directly, $not nested inside $or/$and, and multi-level $not. ⛔ Patching one $not layer and stopping is not a delivery. The card's three sample shapes are the starting point, ⛔ not the finish line.
2. 必做的非空控制: prove the negated shape produces allow-all BEFORE your fix and the deny sentinel AFTER it. ⛔ A regression suite that only exercises positive polarity tests the half that was already green — that is the whole defect.
3. ⚠️ Blast radius must be declared in the changeset: after this fix, callers currently relying on the allow-all will stop seeing rows. That is not a regression — they were relying on a defect — but an operator must be able to read it. Write it in plain terms.

PM mechanism assumptions — measure these; I would rather be falsified

1. That the fix belongs in the guard rather than at the lowering site. read-scope-sql.ts's // IN () matches nothing — safe comment is the same polarity-dependent inference one arm away from the $not that inverts it. If the honest repair is at both sites, say so; if fixing only the guard leaves the analytics lowering path independently reachable, that is a finding to report, not scope to silently absorb.
2. That tenant-layer.ts is the model to copy. The card notes the hand-written Layer 0 path returns an explicit RLS_DENY_FILTER when its membership set is empty rather than an empty $in. Read it — if it already encodes the right shape, mirror it rather than inventing a second convention.
3. That no currently-pinned test asserts the buggy behaviour. If a pin encodes the allow-all, ⛔ do not "fix" the pin to stay green — stop and report, because that pin is either wrong or is telling you the semantics were deliberate.

Gates

Re-derive from your worktree at origin/main and your actual diff: node scripts/pm/dispatch-gates.mjs <changed paths>. ⚠️ A sibling PR in this package was just reddened by a gate its local run did not derive (check-system-context-census, keyed off a source file via a docs page). Derive from the tree, ⛔ never from a remembered family list, and read the derivation's stale-tree warning if it prints one.

Report

Post the terminal report as a comment on this issue first, then return it as your message. Machine-checkable fields only (gates / line_budget / deviations / files_changed / premise_still_valid / pr / status / open_questions / out_of_scope_findings); ⛔ do not restate the PR body's narrative.

---

Generated by Claude Code