mcp: the stdio door resolves an API key with no `tenancyPosture` — an ex-member's org-stamped key is admitted with its own unvetted 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/mcp/src/plugin.ts:53

resolveStdioExecutionContext is an API-key-only door — it builds the header map itself:

const authz = await resolveAuthzContext({ ql, headers: { 'x-api-key': apiKey } });

There is no session path and no posture. Of the six sites this is the sharpest: every caller on this transport is an API key by construction, and the resolved tenantId flows into assembleExecutionContext as the request's tenant.

The fix is not local: the function receives ql, apiKey and localization and holds no kernel handle, so a posture has to be threaded from start() where ctx is in scope — a signature change plus its call sites.

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/mcp/src/plugin.ts:53 ⇒ domain:cli. 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 the packages/mcp one. The same reading confirms the census the card states — only packages/rest/src/rest-server.ts:2497 and packages/runtime/src/security/resolve-execution-context.ts:179 pass tenancyPosture.

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

Rationale for Bug over Feature (the mechanical boundary test): the change does not widen the accept set or the public surface — it restores a guard the contract already declares, so declared returns to enforced. priority:p1 rather than the parent's p0: the p0 arm (the single-kernel REST wiring) is repaired and merged; these six remaining doors are the same defect through transports that are not the default open-core boot path.

⚠️ For the dispatching seat, ⛔ not a fence: the card's own note that a naive try { … } catch { undefined } re-creates #13906's permissive-on-failure defect is the constraint to carry into the dispatch order. Triage has ⛔ not measured whether a posture is derivable at this seam.

---

Generated by Claude Code