plugin-sharing: the exec-context seam supplies no `tenancyPosture` to `resolveAuthzContext` — an ex-member's org-stamped API key keeps its claim

[hotlong]

Censused under #15256 (maintainer ruling 2026-09-04, item 5). That card repaired the REST single-kernel seam; this is the same hole through another door.

This site

packages/plugins/plugin-sharing/src/sharing-plugin.ts:847

const authz = await resolveAuthzContext({ ql, headers, getSession });

Real request headers, so x-api-key is accepted (readHeader(headers, 'x-api-key'), api-key.ts). No posture.

⚠️ Worth noting when this is triaged: this plugin ALREADY resolves a tenancy probe a few hundred lines up (ctx.getService('tenancy') behind SharingTenancyProbe, ADR-0105 D1 late binding) for its own wall reconciliation. So this site may be the cheapest of the six — but the probe's shape and the classification decision-1-option-A requires still have to be reconciled, which is why it is filed rather than patched blind.

The mechanism, unchanged from #15256

resolveAuthzContext gates BOTH posture-conditional API-key refusals on a tenancyPosture its caller supplies:

• organization_required — packages/core/src/security/api-key.ts, if (!tenantId && tenancyPosture)
• organization_membership_ended — packages/core/src/security/resolve-authz-context.ts, if (keyPrincipal?.tenantId && input.tenancyPosture)

No posture supplied means neither guard runs. The key's tenantId is sys_api_key.active_organization_id copied verbatim — the caller's own stored claim, never vetted against current membership. So under a wall-enforcing posture (isolated), an API key stamped with an organization its owner has left is admitted, carrying that organization as its tenant.

The census this came from

Of the eight non-test resolveAuthzContext callers on main, exactly two supply a posture:

• packages/rest/src/rest-server.ts — both wirings, after [decision · p0] an ex-member API key reads AND writes another organization's rows on the single-kernel wiring under isolated — the wall compares against the caller's own unvetted claim #15256
• packages/runtime/src/security/resolve-execution-context.ts — already did

The other six do not. This issue is one of them; the ruling directed one issue per site.

Why #15256's PR did not fix it inline

Ruling item 5 says fix in that PR if it is one line per site. It is not. A correct derivation has to carry decision-1-option-A's classification (#13906): a tenancy service that was never registered is branded and resolves quietly to "no posture", while one that was registered and FAILED to build must raise AuthzStoreUnavailableError (503). A naive try { ... } catch { undefined } at this seam re-introduces precisely the permissive-on-failure defect #13906 was filed to repair — a failure reading as "this check does not apply".

Refs: #15256 (the ruling and the repaired REST seam) · #15163 (the framework measurement) · #13906 (decision 1 option A) · ADR-0105 D2/D3 · ADR-0123 D2.

Blocked-by: #15256

[hotlong]

Unblocked: pm:blocked → pm:queue. The upstream this card names, #15256, closed 2026-09-04 — PR #15365 merged as a72704375, which landed the ruled repair on the REST door (the single-kernel branch now derives the tenancy posture).

What that does and does not do for this card. #15365 repaired one caller of resolveAuthzContext — the REST transport. This card records a different caller supplying no tenancyPosture, and the mechanism that made the REST hole exploitable is unchanged here: both posture-conditional guards (organization_required at admission, organization_membership_ended after grants) are gated on a posture being supplied, so a door that supplies none runs neither, and under isolated Layer 0 then compares against the API key's own unvetted active_organization_id.

Scoping context, measured after this card was filed — it narrows who is exposed and should shape the fix's urgency, not its correctness:

• The wall-enforcing posture requires the org-scoping service. Nothing in this repository registers it — only consumers gate on it (ctx.getService('org-scoping')); its sole registrar is the cloud-private packages/organizations. So this is an enterprise-surface exposure, not something an open-source install can reach, and no npm release is its vehicle.
• Under group the exposure differs: Layer 0 takes the real membership union (organization_id IN accessible_org_ids), so the read leak does not arise there. ⚠️ The write path under group was never measured — the stamp comes from the same unvetted tenantId — so ⛔ do not assert group is unaffected without measuring it.

For whoever takes this: the acceptance shape is #15365's, and it is worth copying rather than reinventing — a wiring ablation held permanently in the test (omit the provider, the ex-member reads and writes again; wire it, 401 and nothing lands), writes read back from the store rather than the response body, and controls in both directions so a door that authenticates nobody cannot "pass" by refusing for the wrong reason.

Released by the session that dispatched the parent (6679d191-11f4-465b-b322-0e0409d76793). domain:* and priority remain triage's.

[os-zhuang]

Triage: lands in packages/plugins/plugin-sharing/src/sharing-plugin.ts:847 ⇒ domain:services (plugin-sharing folded into that lane on 2026-08-19, when domain:identity was retired from circulation). Graded Bug · priority:p1.

Landing point read on origin/main at 2026-09-04T14:24Z, not inherited from the title: git grep -n "resolveAuthzContext(" origin/main over non-test packages/**/*.ts returns 10 sites, and this card's is sharing-plugin.ts:847.

⚠️ One reading the card does not carry, and the dispatching seat should not be surprised by. The same grep shows a second plugin-sharing call site — src/exec-context-seam.testkit.ts:96. It is a testkit rather than a live door, so it is outside the census of eight non-test callers, but it is inside the package and will need the same posture threading or an explicit note saying why not. ⛔ Triage has not judged which.

Blocked-by: #15256 is discharged, verified rather than assumed: #15256 is CLOSED (completed, 13:58:49Z) with PR #15365 MERGED. ⇒ pm:queue is correct.

Bug by the mechanical boundary test — the accept set does not widen, a declared guard returns to enforced. priority:p1 rather than the parent's p0: the p0 arm is repaired and merged.

---

Generated by Claude Code