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

[huangyiirene]

Observation-class finding, filed unassigned with no pm:queue — for triage to grade and route. Handed up by the dev on #7639 / PR #7896 as an explicit "for you to grade, not for me to decide" residual, and graded by the services PM as not a blocker for that PR (reasoning below) but worth its own card.

What was measured

packages/runtime/src/domains/automation.ts:135-147 applies the #5519 anonymous baseline to the whole /automation domain — not per route, not per field. automation.ts:489-496 then answers run-detail with deps.success(run), handing back the ExecutionLogEntry verbatim: no projection, no redaction, no masking, on any field, anywhere on that path. A repo-wide grep for redact/mask/sanitize across service-automation and the domain returns zero non-comment hits.

So the only question this surface asks is "are you authenticated?". Any authenticated caller who knows a run id reads whatever that run's log entry holds — including, via the variables snapshot and via output, the triggering record's fields, without that record's own field-level security applying.

Why it is worth a card

The exposure is not new and was not introduced by #7639/PR #7896, which is exactly why it needs its own card rather than a veto on that PR:

• output has always carried record fields whenever a flow author declared the record (or a projection of it) as an output variable — so the FLS-bypass property predates the paused-variables work.
• steps, flow definitions and the rest of the /automation read surface sit behind the same single gate.
• What PR fix(services): a paused run's variable snapshot is readable on run-detail (#7639) #7896 changed is the conditionality: the paused snapshot carries the triggering record and its flattened fields unconditionally, where before reaching the same data required an author opt-in. Same data class, same door — broader traffic through it.

Framing this as "a problem with the variables key" would be the inaccurate version. The accurate question is a domain-level policy one:

Should the /automation read surface apply the underlying record's FLS (or any per-object permission) rather than only an authentication check?

That is a product/security design call with real cost on both sides — narrowing it changes what every existing operator tool can read, and per-field filtering of a free-form variable map is not obviously well-defined (keys are <nodeId>.<key>, record, previous, $runId, seeded inputs; only some of them correspond to a record field at all).

What the other door does today

The identical snapshot has a second, differently gated door: sys_automation_run.variables_json (sys-automation-run.object.ts:164-169) persists it verbatim for every paused run, and that read goes through the system object's permissions. So the platform currently answers the same question two ways depending on which door you knock on — which is itself the sharpest evidence that a deliberate policy has never been stated for this surface.

Explicitly NOT claimed here

• No credential class is exposed. Measured on finding: a suspended flow run's variables are unreadable on run-detail — the paused recordLog omits them while the continuation keeps them #7639: connector credentials live in the connector registry and are never handed to a flow; the http node's signingSecret/headers are config inputs interpolated from variables and never written back (builtin/http-nodes.ts:115-170, output is {response, status}). A secret reaches variables only if a flow author puts one there — and by that same route it reaches output. This card is about record-field FLS, not secret leakage.
• No regression is asserted. Everything above is true of origin/main before PR fix(services): a paused run's variable snapshot is readable on run-detail (#7639) #7896 as well, for any flow whose author declared record data as output.

Suggested routing

Landing site is packages/runtime/src/domains/automation.ts (the gate) and possibly plugin-security (whatever would supply the record's FLS), so this likely is not domain:services even though it surfaced there — the service-automation engine is not where the gate lives. Triage's call.

If graded for work, this probably wants needs-user-decision before implementation rather than a dispatch: the narrowing decision has a real blast radius, and per #4829 the time to put it in the maintainer's inbox is when there is pull — which there now arguably is, since PR #7896 makes the exposure unconditional.

Evidence

Measured 2026-08-12 by the dev on PR #7896 (origin/main base 68a1edb), reading packages/runtime/src/domains/automation.ts, packages/services/service-automation/src/engine.ts, builtin/http-nodes.ts, and sys-automation-run.object.ts. Full measurement recorded in the <!-- os-dev-report --> comment on #7639 and in PR #7896's body.

Source

Split out of #7639 (PR #7896) — the dev's named residual, deliberately not decided inside that card.

[hotlong]

Triage: graded to needs-user-decision + routed domain:cli (the gate lives in packages/runtime/src/domains/automation.ts — runtime is cli-lane; whatever supplies FLS comes later, from wherever the ruling points). The card's own instinct is right: this is a domain-level read-authorization policy that has never been stated, it is a security/permission boundary (human floor — not auto-adjudicable), and PR #7896 turning the snapshot unconditional supplies the pull that #4829 says is the moment to ask.

Four-lens block (①–④ per #7498):

• ① Platform long-term coherence — the platform currently answers the same question two ways depending on the door: /automation run-detail = "authenticated is enough", sys_automation_run.variables_json = system-object permissions. One stated policy collapses the incoherence; leaving it unstated grows it with every new automation read route.
• ② Measured business pull — measured, not speculative: any authenticated caller with a run id reads the triggering record's fields with no FLS applied, and since PR fix(services): a paused run's variable snapshot is readable on run-detail (#7639) #7896 that data is in every paused run rather than only author-opted-in outputs. No customer report yet; exposure class is real.
• ③ AI-agent error-resistance — "per-field filtering of a free-form variable map" is not mechanically decidable (only some keys correspond to record fields at all); a policy an agent can implement wrongly-but-quietly is worse than a coarse one it cannot. The decidable options are coarse: gate the read on a permission, or don't.
• ④ Startup scope discipline — the cheapest coherent option is convergence, not invention: gate /automation run-detail (and kin) on the same permission the sys_automation_run object read already answers with, so two doors give one answer and no new FLS machinery is built.

Recommendation: converge the doors — require the caller to pass the sys_automation_run object-read permission for run-detail (and audit the other /automation reads against the same rule), explicitly rejecting per-field filtering of the variables map as ill-defined. Narrowing cost (existing operator tooling must hold that permission) is the price of having a policy at all; if the maintainer prefers "authenticated is enough" as the deliberate policy, writing THAT down also closes this card.

Not dispatchable until ruled; exits the finding stock into the decision box (label kept as finding+needs-user-decision deliberately: it is both a graded observation and an open ruling, the #7732 combo shape).

---

Generated by Claude Code

[hotlong]

Maintainer ruling — 2026-08-12

Ruled: converge the two doors — the /automation read surface requires the same permission the sys_automation_run object read answers with; per-field filtering of the variables map is rejected as the mechanism.

Provenance: maintainer, triage PM session chat (session_01NKGoRBFZELVKivDkiAswdz), 2026-08-12, verbatim: 「7918 A,7917 ②,7900 收敛两扇门,7929 来源标记」. Recorded by the triage seat; needs-user-decision/finding → pm:queue swapped in the same write.

Implementation boundaries:

• Landing: packages/runtime/src/domains/automation.ts — run-detail first (the measured exposure), then audit every other /automation read route against the same rule; routes that stay authenticated-only after the audit need a stated reason in the PR, not silence.
• The permission consulted is the sys_automation_run object-read grant (however plugin-security exposes that check to the runtime domain) — one policy, two doors, one answer.
• ⛔ Do not build per-field filtering of variables — explicitly rejected by this ruling (mechanically undecidable per the card's measurement).
• Migration note the PR must state: operator tooling that previously read run detail with bare authentication now needs the grant — call it out in the changeset so deployments can pre-grant.
• Refusal tests assert code + status; positive control: a caller WITH the grant reads exactly what they read today.
• Fork clause: if implementation shows the object-permission check cannot be reached from the runtime domain without a new cross-package seam, report the shape before building it — don't invent a second permission system silently.

---

Generated by Claude Code