service-datasource: the admin routes supply no `tenancyPosture` to `resolveAuthzContext` — an ex-member's org-stamped API key is admitted

[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/services/service-datasource/src/admin-routes.ts:387

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

Real request headers on the datasource ADMIN routes, so x-api-key is accepted. No posture, so an ex-member's stamped key authenticates and the route then gates on authz.systemPermissions.

Severity note, honestly: this family gates on system capabilities rather than on org-scoped rows, so the immediate consequence is an admitted principal rather than a cross-organization row read. That makes it less severe than #15256's data door — it does not make the admission correct.

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/services/service-datasource/src/admin-routes.ts:387 ⇒ domain:services. 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 service-datasource/src/admin-routes.ts:387.

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

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 (the single-kernel REST wiring) is already repaired and merged, so what remains are the non-default transports.

⚠️ Four cards of this family land in domain:services (#15349 #15350 #15351 #15352) and two in domain:cli (#15348 #15353). Within the services four, the shared-region test for a folded family dispatch is worth running before dispatching them one at a time — ⛔ triage has not run it, and the fold-or-serial answer is the executing seat's.

---

Generated by Claude Code