Security: business action bodies run context-less (unbounded RLS/FLS) — agent action effects escape the D10 ceiling

[os-zhuang]

Found by the ADR-0090 D10 adversarial security review.

What

Business action bodies (type: script/body) are dispatched via invokeBusinessAction with an engine facade — buildActionEngineFacade(ql) (packages/runtime/src/http-dispatcher.ts:897-920) — whose insert/update/delete/find call the engine with no ExecutionContext:

async insert(object, data) { const res = await ql.insert(object, data); … }        // no context
async update(object, id, data) { await ql.update(object, data, { where: { id } }); } // no context

A context-less engine call hits the SecurityPlugin's empty-principal fall-open (security-plugin.ts ~520) → all RLS / FLS / CRUD / tenant scoping and the D10 agent intersection are skipped. So an action body reads/writes with ambient unrestricted authority (the "SECURITY DEFINER / trusted code" model). The same context-less facade exists on the REST action route (http-dispatcher.ts:~3495).

Why it matters (agent angle)

With the D10 agent feature (#2843/#2845), an MCP agent can invoke actions (run_action, gated by actionPermissionError + actions:execute). Because the body runs context-less, the agent's data ceiling does NOT bound what an invoked action reads or writes — contradicting the safety framing in #2845 ("a data:read agent invoking a writing action is blocked at the write"). The real boundary for agents is invoke-time only (ai.exposed + the capability gate), not the data ceiling.

Decision needed

1. Accept the trusted-action model and correct the docs/feat(security): ADR-0090 D10 — delegate action capabilities to MCP agents #2845 framing (agent action power = invoke-gate + ai.exposed, not data-bounded); optionally revert feat(security): ADR-0090 D10 — delegate action capabilities to MCP agents #2845 to strict (deny cap-gated actions to agents).
2. Thread the caller's ExecutionContext into the action facade so bodies run bounded by the caller (and, for agents, the ceiling∩user intersection). Correct, but a larger change that may break actions relying on trusted-mode cross-cutting writes.
3. A hybrid: default bodies to the caller context, with an explicit opt-in runAs: 'system' for trusted actions.

This is also a general (non-agent) consideration: any action a normal user invokes runs unbounded internally — defensible as trusted code, but worth making explicit.

Refs

• packages/runtime/src/http-dispatcher.ts:897-920 (facade), :1010-1015 (actionContext), :985-1034 (invokeBusinessAction)
• Related: feat(security): ADR-0090 D10 — activate agent principal (OAuth → scope ceiling) #2843, feat(security): ADR-0090 D10 — delegate action capabilities to MCP agents #2845

[os-zhuang]

Analysis + recommended direction (not yet implemented)

This is (mostly) an intentional design, not a pure bug

Business action bodies run in a trusted mode (SECURITY-DEFINER-like). Many actions legitimately need elevated authority — "convert lead" creates records across objects, "close ticket" cascades. Running the body under the caller's RLS would break those. So the trusted-action model is defensible.

The real problem is only on the agent side

D10's promise is "an agent is bounded by its ceiling ∩ the delegating user." But once an agent can invoke an action, the body runs trusted (unbounded) — so the #2845 framing ("a data:read agent's action writes are blocked by the ceiling") is wrong. The agent's true action power = "whichever actions it may invoke (gated by actions:execute + the action's required capability ∩ the user's caps), each running with full authority inside."

Where the boundary belongs

invoke-time gating already bounds which actions fire. But the control that should decide "which actions are AI-triggerable" is ai.exposed — the app author explicitly opting an action into the AI surface. An author exposing "delete all customers" to AI is making a deliberate choice; one who doesn't is protected.

⚠️ Possible gap to verify: per the mcp-native-action-tools design note, the native MCP action tools were deliberately built to NOT gate on ai.exposed (dispatch keyed on name≠target). If the agent run_action path can invoke actions the author did not mark ai.exposed, then "trusted mode" is dangerous for agents — a trusted action the author never meant to expose to AI is still agent-triggerable. This needs a code read of the current run_action path before deciding whether it's a real gap.

Options

• (a) Revert feat(security): ADR-0090 D10 — delegate action capabilities to MCP agents #2845 to strict (agent holds no system caps → can't invoke cap-gated actions): half-measure — non-cap actions still run trusted, so it doesn't actually close the door, while removing useful agent capability.
• (b) Run action bodies as the caller (RLS-bounded inside): most correct for the intersection, but a large architectural change that breaks the trusted-action model many existing actions rely on. Not worth it for the agent concern alone.
• (c) Accept the trusted model + fix the framing + enforce ai.exposed for agents (recommended): document that action bodies are trusted code, so the agent's action boundary is honestly ai.exposed (author opt-in) + actions:execute + capability-intersection — NOT the data ceiling. Correct the feat(security): ADR-0090 D10 — delegate action capabilities to MCP agents #2845 wording. And make the agent run_action path require ai.exposed (if the verification above confirms it currently doesn't) — putting the boundary where it belongs (author authorization) instead of a false "data backstop." Small, honest, and genuinely tightens the agent action surface.

Recommendation

(c), contingent on a quick verification of whether the agent run_action path already respects ai.exposed. If it does → (c) is just a docs/framing correction. If it doesn't → the substantive hardening is adding that gate.

Found by the ADR-0090 D10 adversarial security review. Deferred pending direction.