The stdio MCP record resource reads rows through its own `getRecord` seam, skipping the ADR-0049 `apiEnabled` / `apiMethods` exposure gate

[os-zhuang]

Found while implementing #8083 (applying the exposure gate on the stdio MCP data bridge). Filed rather than fixed there: #8083's scope is the bridge, and this is a different seam in a different file.

What differs

#8083 closed the declaration leak on the six object-CRUD verbs, which all flow through createStdioDataBridge (packages/mcp/src/stdio-data-bridge.ts). The ADR-0101 record resource does not use that bridge at all. Its reader is a separate closure built inline in the plugin:

• packages/mcp/src/plugin.ts — getRecord = async (objectName, recordId) = ... calls scopedQl.find(objectName, { where: { id: recordId }, limit: 1, context: ec }) directly
• handed to this.runtime.bridgeResources(metadataService, getRecord)
• served as objectstack://objects/{objectName}/records/{recordId}

So after #8083 an object declaring enable.apiEnabled: false is refused by get_record (the tool) and still readable through the record resource, on the same transport, under the same key.

Why it matters

Same grading as #8083, and for the same documented reason: this is a surface-area declaration leak, not an authorization bypass. packages/runtime/src/api-exposure.ts records the gate as a surface-area control rather than the authorization boundary, and this read passes the engine's CRUD / FLS / RLS middleware exactly as before — it goes through ql.find with the key's ExecutionContext. What leaks is the author's exposure declaration. Please do not triage this as a security issue.

Scope note: the gap predates #8034 — the record resource has read rows over ql.find without the gate since #7645, which is the narrower form of the divergence #8083's body records under "Scope note".

Suggested shape (not prescriptive)

#8083 landed the gate as enforceApiExposure inside stdio-data-bridge.ts, taking its decision from the spec's single source of truth (resolveEffectiveApiMethods / isApiOperationAllowed) rather than re-implementing it. Two routes:

• A — export that helper from stdio-data-bridge.ts and call it in getRecord before the find. Smallest diff. The gated action is get, matching what the HTTP path sends for a single-record read.
• B — build the resource reader from the bridge instead of inline, so the resource and the tool surface cannot drift on anything, not just this gate. Larger; overlaps the seam question options A/B on The two MCP transports run their data verbs through different seams — stdio skips the ADR-0049 apiEnabled / apiMethods exposure gate that HTTP applies #8083 raise.

Either way the acceptance shape is the one #8083 used: one declaration, both read paths (get_record tool and the record resource), same verdict.

Overlap to check before dispatch

#7279 touches this exact code. It is about a third hand-written ExecutionContext assembly in the stdio MCP plugin dropping tabPermissions / accessToken, and getRecord's resolvePrincipal is in that blast radius. These two should not be in flight at the same time, and there may be a case for doing them as one card.

---

Generated by Claude Code

[hotlong]

Blocked-by: #8083

Triage: lands in packages/mcp (plugin.ts getRecord / the ADR-0101 record resource) ⇒ domain:cli, type Bug — a declared enable.apiEnabled: false is not enforced on the resource read path, declared ≠ enforced. Not graded security, per the card's own measured note: this is a surface-area declaration leak; the read still passes CRUD/FLS/RLS middleware.

pm:blocked rather than pm:queue: route A consumes the enforceApiExposure helper #8083 lands in stdio-data-bridge.ts, and #8083 is in flight now. On unblock, re-verify on the merged ref: whether #8083's landing already absorbed this seam (its route-B option — building the resource reader from the bridge — would close this card with zero additional work).

Second serial constraint for the eventual claim line: #7279 is claimed/in-flight and touches the same plugin.ts context-assembly blast radius (getRecord's resolvePrincipal) — do not fly both at once; the card itself raises the one-card-merge question, which the cli seat should answer at pickup.

Note: the Blocked-by: line lives at the top of this comment rather than as a body edit — body round-trip from this seat's tooling risks entity corruption on long bodies (flagged in the round brief).

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 2 (domain:cli seat #6024)
Session: session_01P7vaLs7bhBPi9m3JyzkhDj
Branch: claude/issue-8266-record-resource-exposure-gate
Worktree: objectstack-issue-8266
Domain: domain:cli
File surface: packages/mcp/src/plugin.ts (the getRecord closure) and packages/mcp/src/stdio-data-bridge.ts (export the existing helper) + tests in packages/mcp. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: #8083 MERGED (PR #8265) — Blocked-by satisfied. #7279 is NOT in flight (pm:queue, unassigned), so the plugin.ts context-assembly overlap the card raises is not live. ⚠️ #8328 is in the same package (mcp-server-runtime.ts) and is held, not dispatched, while this claim is open. No other in-flight claim touches packages/mcp.

Unlocked — and the premise re-verified on the merged ref

Triage flagged the exact thing worth checking: #8083's route-B option would have closed this card with zero work. Measured on origin/main after PR #8265 landed:

• packages/mcp/src/plugin.ts:239 — getRecord is still an inline closure, handed to bridgeResources at :256.
• Zero matches for enforceApiExposure / isApiOperationAllowed / resolveEffectiveApiMethods anywhere in plugin.ts. The record resource is still ungated.
• Positive control: bridgeResources resolves once in that file, so the empty searches above mean something.

⇒ #8083 took the narrow route. This card is still real.

⚠️ One correction to the card's own suggestion: it proposes "export that helper from stdio-data-bridge.ts", implying it is already exported. It is not — there are zero exported matches for enforceApiExposure in that file. Exporting it is part of the work, not a given. Verify what #8265 actually named it before writing against the card's spelling.

The seat's answer to the one-card question triage left open

The card asks whether this should be merged with #7279. No — keep them separate. #7279's own evaluation (delivered, on that card) reversed its framing: both fields its title names turned out to be non-events, and the real defect it surfaced is a read-path localization issue. It is decision-shaped and sits in this seat's inbox. Folding a clean, small, ruled gate into a card whose scope is still contested would stall the gate for no benefit. They must not fly at once, which is satisfied; that is the whole constraint.

Scope

Route A — call the exposure decision in getRecord before the find, taking the verdict from the spec's single source of truth (resolveEffectiveApiMethods / isApiOperationAllowed) exactly as #8083 did, rather than re-implementing it. The gated action is get, matching what the HTTP path sends for a single-record read.

⛔ Route B (rebuilding the resource reader from the bridge) is out of scope here — it overlaps the seam question #8083 raised and is a larger change than this card is graded for. If you measure that route A cannot be done cleanly without it, stop and report the fork; do not silently widen.

Acceptance, the shape #8083 used: one declaration, both read paths (get_record tool and the record resource objectstack://objects/{objectName}/records/{recordId}), same verdict.

Grading — read this before writing the PR body

⛔ This is NOT a security issue and must not be described as one. The card says so and it is correct: packages/runtime/src/api-exposure.ts records the gate as a surface-area control, not the authorization boundary. This read already passes CRUD/FLS/RLS via ql.find with the key's ExecutionContext. What leaks is the author's exposure declaration. Describing it as a bypass would misgrade it in the release notes and the changeset.

Non-negotiables

• Run every build and test as an ordinary foreground Bash call and block on it (raise timeout up to 600000 ms). ⛔ Do not background anything, ⛔ do not poll.
• Ablate the pin: show the resource read really is refused after the change and really was permitted before. A parity assertion that passes because both paths refuse for some unrelated reason is the failure mode — assert the verdict, and prove the un-gated path was reachable.
• Changeset required.
• Draft PR, target main, first line Fixes #8266.
• Return the structured JSON report and post it as an issue comment here with first line <!-- os-dev-report -->.

---

Generated by Claude Code