finding: `GET /automation/:name/runs/:runId/screen` still discloses record-derived values to any authenticated caller who knows a run id

[hotlong]

Observation-class finding, filed unassigned with no pm:queue — for triage to grade and route. Named residual of #7900 (PR pending), deliberately not decided inside that card because closing it needs a different mechanism from the one #7900's maintainer ruling names.

What #7900 closed, and what it left

The 2026-08-12 ruling on #7900 converged the /automation run-state reads on the sys_automation_run object-read grant. GET /:name/runs/:runId and GET /:name/runs now require it. The ruling also asked for the rest of the domain to be audited against the same rule, with a stated reason for anything that stays authenticated-only.

GET /:name/runs/:runId/screen is the one route the audit left authenticated-only, and the reason is on the route in packages/runtime/src/domains/automation.ts:

• It is the end user's surface, not the operator's. The pause exists because the flow is asking this caller to fill a form in; the trigger response already handed them the same screen inline, and the route exists so a browser refresh does not lose it. Requiring an operator grant here would refuse the screen to the very person the flow paused for — a breakage, not the narrowing the ruling prices in ("operator tooling … now needs the grant").
• Its write sibling already answers on a different axis: resume is gated in the engine by the suspension's declared resumeAuthority (automation: the generic run-resume route needs an authorization gate keyed on the suspended node #3801 / automation: resumeAuthority defaults to 'any', so every future pausing node ships fail-open — ADR-0044 says this is "tracked separately" and nothing tracks it #5561) — a per-run authority model, not an object grant. Read and write on the same pause answering to two unrelated permissions would be the incoherence 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 exists to remove.

The residual, measured

The route is not inert with respect to record data. AutomationEngine.getSuspendedScreen(runId) returns (await this.loadSuspendedRun(runId))?.screen — the ScreenSpec persisted with the suspended run — and that spec is built with values interpolated against the live flow variables at suspend time (packages/services/service-automation/src/builtin/screen-nodes.ts: interpolate(cfg.defaults, variables, context) and, per field, interpolate(f.defaultValue, variables, context)).

So a flow whose screen prefills from the triggering record (defaultValue: '{record.email}', a defaults map over {record.*}) writes those values into the spec, and the route answers them to any authenticated caller who knows the run id — there is no check anywhere on this path that the run belongs to, or was paused for, the caller. Same shape as the #7900 exposure, one route over and a narrower payload: interpolated screen defaults rather than the whole variable map.

Not claimed: that this is a regression (it is true of origin/main before #7900 as well), or that it exposes any credential class (the #7900 analysis of connector credentials applies here unchanged).

What closing it would take

Not the sys_automation_run grant — that is the mechanism this route was audited out of, for the reasons above. The shape that fits is the one the resume path already has: a per-run authority read gate, i.e. "may this caller see the screen this run is paused on?", answered from the suspension's own resumeAuthority / assignee state rather than from an object permission. That is a design call about the screen-flow runtime (ADR-0019 territory), not an application of the #7900 ruling, which is why it is a separate card.

Possible cheaper interim, if triage wants one before that design lands: scope the route to the run's own trigger identity (ExecutionLogEntry.trigger.userId) with the sys_automation_run grant as the operator override — narrow, decidable, and it does not refuse the end user. Recorded as an option, not a recommendation; the authority model is the real answer.

Evidence

Measured 2026-08-12 while implementing #7900, on origin/main base 4b5702a, reading packages/runtime/src/domains/automation.ts, packages/services/service-automation/src/engine.ts (getSuspendedScreen) and packages/services/service-automation/src/builtin/screen-nodes.ts.

Source

Split out of #7900 — the implementing dev's named residual, recorded in the route's own comment and in that card's PR audit table.

[hotlong]

Triage: needs-user-decision, routed domain:cli (route lives in packages/runtime/src/domains/automation.ts, same lane as #7900), type Bug. Human floor: security/permission boundary — the card's own analysis shows the #7900 mechanism was deliberately ruled out for this route, so closing it is a new access-model decision, not an application of an existing ruling.

Question: how should GET /automation/:name/runs/:runId/screen be gated, given the object-read grant would refuse the end user the flow paused for?

Options:

• A — per-run authority read gate derived from the suspension's own resumeAuthority / assignee state (the axis resume already answers to, automation: the generic run-resume route needs an authorization gate keyed on the suspended node #3801/automation: resumeAuthority defaults to 'any', so every future pausing node ships fail-open — ADR-0044 says this is "tracked separately" and nothing tracks it #5561). The coherent end state; ADR-0019-class design work.
• B — interim narrow gate: run's own trigger identity (ExecutionLogEntry.trigger.userId) OR the sys_automation_run grant as operator override. Recorded on the card as an option.
• C — accept authenticated-only, document the exposure.

Four-lens block:

1. Platform long-term coherence — A aligns read and write on one authority model (read/write on the same pause answering to two unrelated permissions is the incoherence 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 removed elsewhere); B is narrow but sits on the same identity axis as resume; C leaves the seam the 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 ruling just closed one route over.
2. Measured business pull — exposure is real but narrow: needs a flow whose screen interpolates record values into defaults, plus a leaked/guessed run id. No customer report. The class was judged worth closing on the sibling routes this week.
3. AI-agent error-resistance — AI-authored flows will interpolate {record.*} into screens as a matter of course; a structural gate (A or B) prevents the class, documentation (C) does not.
4. Startup scope discipline — B is small and decidable today; A is a design program. Choosing A now grows scope; choosing C declares an accepted disclosure.

Recommendation: B now, A recorded as the direction (B does not preclude A; both refuse the same stranger and admit the same end user). If B is taken, the acceptance test is: stranger with valid auth + run id ⇒ denied; triggering user ⇒ screen; holder of sys_automation_run read ⇒ screen.

本评论来自分诊座位（scheduled session session_0199Rq2oEnNNRmdhmWwqUwvQ），不构成认领。

---

Generated by Claude Code

[hotlong]

Maintainer ruling recorded — Option B adopted now, A recorded as the direction. Provenance: maintainer, 2026-08-12 (live, in this PM session), on the consolidated decision digest: 「接受你的全部建议。」 — adopting the triage recommendation (comment 5265162333).

Binding ruling: GET /automation/:name/runs/:runId/screen is gated to the run's own trigger identity (ExecutionLogEntry.trigger.userId) OR a holder of the sys_automation_run read grant (operator override). Option A — the per-run resumeAuthority read gate — stays recorded as the coherent end state (ADR-0019-class design); B does not preclude it.

Acceptance (verbatim from the escalation, now binding): stranger with valid auth + run id ⇒ denied; triggering user ⇒ screen; holder of sys_automation_run read ⇒ screen. Landing: packages/runtime/src/domains/automation.ts (cli lane, same as #7900).

本评论来自分诊座位（scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

---

Generated by Claude Code