finding: a `flow`-type action's AutomationContext gets the same stamped `record` stub when the caller cannot read the row — and the flow face has no `recordLoadDenied`

[os-support-ai]

Observed while implementing #14143 on 66ecc50a. ⛔ Unclaimed. Filed rather than fixed: #14143's dispatch order binds that card to the handler predicate, and this is one surface over.

What #14143 fixed, and where it stops

#14143 adds ctx.recordLoadDenied to the script/body action face: when the dispatcher's caller-scope load of the subject row does not deliver it, the handler is told, instead of only receiving ctx.record = { id: recordId } (the id being stamped on precisely because the load failed).

Both dispatch doors now route their load through one producer, loadActionSubjectRecord (packages/runtime/src/action-execution.ts). But the flow branch consumes the same record object and carries no equivalent signal:

• packages/runtime/src/action-execution.ts — MCP run_action, the action.type === 'flow' branch passes record into dispatchFlowAction;
• packages/runtime/src/domains/actions.ts — REST /actions, same;
• dispatchFlowAction then hands it to automation.execute(action.target, { record, ... }) as the run's AutomationContext.record, and seeds params from the same object via seedFlowActionParams.

So a flow started by a row-scoped action on a row its invoker cannot read receives record = { id: <recordId> } — shaped exactly like a legitimate record-less start, with nothing on the context distinguishing the two.

Why it is a smaller claim than #14143, not the same one

A flow action is deliberately not system-elevated: the flow engine receives the caller's identity and honours runAs (ADR-0049), so a runAs: 'user' flow re-derives the caller's scope on its own reads and the stub simply resolves to nothing. The exposure is narrower and conditional:

• an author declaring runAs: 'system' on the target flow gets elevation plus a record stub the invoker could not read, and no context key to guard on;
• any flow node branching on record.id being present reads the same always-true predicate action dispatcher stamps ctx.record.id after a failed caller-scope load, so the natural authorization guard (if (!ctx.record?.id) refuse()) is always true on a row the caller cannot read #14143 removed from the handler face.

⛔ Not claimed

• ⛔ No exploitation claim. No exploitability work was done. Same posture as action dispatcher stamps ctx.record.id after a failed caller-scope load, so the natural authorization guard (if (!ctx.record?.id) refuse()) is always true on a row the caller cannot read #14143: this is a predicate/observability gap, not an incident report.
• ⛔ Not a claim that runAs: 'system' is wrong — it is a declared, documented authoring decision.
• ⛔ Not a proposal to narrow the flow dispatch path. Whether the right answer is an additive AutomationContext key mirroring recordLoadDenied, a documentation change on runAs: 'system', or nothing at all is a design question for triage; action dispatcher stamps ctx.record.id after a failed caller-scope load, so the natural authorization guard (if (!ctx.record?.id) refuse()) is always true on a row the caller cannot read #14143 ruled only the handler face and ruled the narrowing direction out of that card's scope.

Dedupe

One targeted search_issues (repo-scoped REST search answered 403 for this seat, so the channel switch is declared here). 11 results, positive control holds — #14143 itself and the runAs/automation-elevation family (#14201, #14011, #5494, #7900, #3783, #4366) came back, so the query matched semantically rather than returning a silent zero. Nearest neighbours excluded:

• lint: flow-update-readonly-when-field skips runAs:'system' flows entirely, but the conditional strip has no isSystem exemption #14201 (open) — flow-update-readonly-when-field skips runAs: 'system' flows in lint. Same runAs vocabulary, different site (a build-time rule, not the dispatcher's context assembly).
• finding: the whole /automation read domain is gated only by "authenticated" — run-detail returns the triggering record's fields without that record's own FLS #7900 (closed) — /automation run-detail returns the triggering record's fields without that record's own FLS. Adjacent in spirit; different surface (a read API over stored runs, not the record handed to a run at start).
• Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494 / [automation/audit] runAs:'system' 流回写的审计行无归因(user_id/actor 双空),console 历史显示「未知用户」 #4366 / Approvals status mirror drops the acting user, forcing every downstream record-change flow to runAs:'system' #3783 — attribution of what a runAs: 'system' run writes. This is about what such a run is given.

⛔ No duplicate.

Repro sketch

Declare a type: 'flow' action on an object with OWD private, targeting a flow with runAs: 'system'. Invoke it as a caller who cannot read the target row, with that row's id. The run's AutomationContext.record should be observed as { id: <recordId> } rather than absent — identical to a record-less start.

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): graded → pm:blocked · priority:p2 · security (topic marker, no exploit asserted) · domain:spec · type Feature. finding removed.

Blocked-by: #14143

The design question is answered by inheritance, not reopened. #14143's dispatch ruled the handler face: direction 1 (additive signal that the caller-scope load was refused) is the route; direction 2 (refuse before dispatch, i.e. narrowing a published path) is not for a lane to take. The flow face is the same mechanism one surface over — the same loadActionSubjectRecord producer, the same stamped stub — so it inherits the ruling with its reason: an additive key on the flow run's context that mirrors the handler face's signal, so a runAs: 'system' flow has something to guard on; ⛔ no narrowing of dispatchFlowAction, ⛔ no claim that runAs: 'system' is wrong. If the implementer finds a real semantic difference (e.g. the only viable fix is to refuse the start), that is a fork report back to the decision inbox, not a unilateral choice.

Why domain:spec and why blocked: AutomationContext is declared in packages/spec/src/contracts/automation-service.ts (single owner), so adding the key expands a published contract surface — Clause-②: yes at dispatch (contract-review tier). And the key must carry the producer's denial signal, which #14143 (PR #14247, in flight) introduces; landing this first would invent a second spelling. The unlock scan returns it to pm:queue when #14143 closes; the spec seat then names the key in the same spelling the handler face shipped.

---

Generated by Claude Code

[huangyiirene]

Unlock scan (R+90, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): released → pm:queue. Blocker #14143 CLOSED completed at 01:43:22Z via merged PR #14247 ("tell an action handler when its caller-scope record load was refused") — direction 1, the additive signal, as its dispatch ruled.

Card face re-verified on the merged ref (origin/main = 72adb7f), and this is the reading that matters — the producer's spelling now exists, and the flow face still does not carry it:

	reading
handler / sandbox face	recordLoadDenied built in action-execution.ts (:1240–:1258) and exposed to a body through actionRecordLoadSignal (:1267) ✅
flow face	dispatchFlowAction is still called at :1396 with the plain { objectName, record, params, recordId, ec, envId } — no load signal
the contract	AutomationContext (packages/spec/src/contracts/automation-service.ts) declares record / previous / object / event / userId / positions / permissions / tenantId … and no recordLoadDenied ⇒ holds

⇒ Exactly the condition this card was parked for: the key must mirror the producer's spelling rather than invent a second one, and that spelling is now on main. Everything else in the triage stands — the ruling is inherited, not reopened (additive key, ⛔ no narrowing of dispatchFlowAction, ⛔ no claim that runAs: 'system' is wrong; a measured need to refuse the start is a fork report to the decision inbox). Clause-②: yes — AutomationContext is a published spec contract, so the spec seat dispatches at the contract-review tier.

---

Generated by Claude Code