[finding] runtime(security): two other doors that start a flow by name still let any signed-in member start a self-triggered system flow, after #22310 closes the trigger door

[objectstack-fleet]

Ruled: 6074046403 · letter A · 2026-10-09T04:06Z

Filing gate: ① a product defect, class (a), security: privilege escalation, with reach measured on public doors. ⚠️ P0 suspect: it is the escalation class #22310 was graded p0 for, at two other doors. Raised by #22310's dev (PR #22404, report on #22310) and carried by the domain:cli seat (seat post #6024, session_01BmsuLyUeuG5CNpZFMH1jzS). ⛔ Not a claim. Triage sets the grade and the lane, and routes the question below.

Disclosure: like #22310's ruling, this card stays at class level, naming door classes and functions only. The seat holds the named in-repo producer and gives it to the claiming seat.

Reader who acts: triage first, by its emergency path for a P0 suspect. Whether ruling B (#22310, 6070744023) also binds these doors is a security boundary, which the maintainer decides. The ruling text names only the trigger door and its in-process twin.

What is measured (PR #22404 head 0e92dbe4, a neutral fixture, a signed-in member who holds no permission set)

The member's own create on the target object is refused with 403 PERMISSION_DENIED. Through each door below, the elevated write lands.

door	target	member's answer
POST /api/v1/automation/:name/trigger (PR #22404, ruling B)	system autolaunched flow	403 PERMISSION_DENIED, 0 rows
POST /api/v1/actions/:object/:action, an action of type: 'flow'	system autolaunched flow	200, 1 elevated row
the same, targeting a system schedule flow	system schedule flow	200, 1 elevated row
a declared endpoint of type: 'flow', authRequired: true	system autolaunched flow	200, 1 elevated row (anonymous: 401)

• The MCP run_action bridge reaches the action door, so it answers the same.
• A named in-repo producer: an example application ships an authenticated flow endpoint whose target is an elevated self-triggered flow, and the endpoint declares no permissions. The live boot of that app was not measured; the class was measured with the fixture.

A consequence of ruling B on the console, measured from the source

• The console's buttons for a type: 'flow' action start the flow through the trigger door (POST /api/v1/automation/NAME/trigger), not the action door.
• So after PR fix(runtime): the trigger door refuses a self-triggered system flow to a non-system caller #22404, such a button targeting an elevated self-triggered flow answers 403 for every user, platform admins included. The same declared action still runs at POST /api/v1/actions/....
• In-repo examples/ at 117d34de has no UI flow action targeting such a flow. Downstream apps were not measured.

The question

Does ruling B's type × caller rule also bind the action door (and run_action) and the declared flow endpoint, which are doors an author designs, as ruling B treats screen and api flows? Or are those doors the author's explicit choice? And should the console's flow button go through the action door, where the action's own gates apply?

Duplicate check

REST GET /repos/objectstack-ai/objectstack/issues?state=all&since=2026-09-01 was paged to the end: 2,969 issues, PRs excluded, closed included. A local case-insensitive grep found:

• runAs … system … (action|endpoint) (both orders) and type: 'flow' … runAs: 0 hits each;
• door parity: 1 hit, QA run · card:12438 (15/15) · 6bff748b · 2026-09-29 · 6 PASS / 1 PARTIAL / 8 FAIL / 0 BLOCKED / 0 NOT-RUN #20674, a QA run record;
• run_action … (elevat|runAs): 1 hit, QA run · north-star path published 17.6.0 (11/13) · 617f25f8 · 2026-10-02 · 2 PASS / 8 PARTIAL / 1 FAIL / 0 BLOCKED / 2 NOT-RUN #21318, a QA run record;
• elevated … (action|endpoint): 1 hit, [Decision] security(runtime): may an app-authored body touch the stored-metadata family's tables at all — a hook bound to them, or an elevated body writing them directly (#21454 items 3 and 4) #21520, a decision on stored-metadata tables.

None is this.

Dedupe words: flow action elevated door · actions route runAs system · declared flow endpoint runAs system · run_action flow elevation · door parity flow dispatch

---

Generated by Claude Code

[objectstack-fleet]

维护者速读（决策卡 · 安全）

问题： #22310 的裁决 B 已经堵住了"手动触发入口"：非系统调用方不能启动自启动类（自动执行、记录变更、定时）的系统身份流程。可是还有两个按名字启动流程的入口没堵：

• 类型为流程的"动作"入口，AI 的 run_action 也走这里；
• 声明为流程的自定义端点。

实测：一个没有任何权限集的成员，自己直接写会被拒绝；但通过这两个入口，同一条写入以系统身份落地了。仓库里还有一个示例应用，自带这样一个没声明权限的端点。

• 裁决 B 的原文只点名了触发入口，所以这两个入口要不要同样拦截，属于安全边界，由您决定。
• 分诊定为 p0、security： 与 runtime: any signed-in member can run a runAs: 'system' flow through POST /automation/:name/trigger — the door checks only anonymity, so an elevated sub-flow is an elevated door for everyone #22310 同一类提权，同样任何已登录成员都能利用。

选项	做法	代价
A 同一原则覆盖所有入口（推荐）	动作入口（含 run_action）和流程端点按裁决 B 的同一规则拦截：非系统调用方不能启动这三类自启动系统流程。屏幕流程和 API 流程保持现状	实测的路径全部堵住；不改 spec，也不加新门禁。指向这类流程的控制台按钮对所有人都会被拒，作者要把流程改成屏幕或 API 类型，或改用子流程调用
B 作者设计的入口必须声明权限	动作和端点仍可启动系统流程，但没声明权限要求的，在保存或发布时就被拒绝	等于新增一道作文期门禁，要改 spec（Clause-②: yes）；存量动作和端点都要补声明
C 视为作者的显式选择	这两个入口不动，只修示例应用的端点，并把控制台的流程按钮改走动作入口	实测的提权路径仍然开着，只能靠每个作者自己记得加权限

推荐 A： 裁决 B 自己给的理由就是"这三类流程只靠自己的触发器或作为子流程运行，从不作为入口"。这个理由同样适用于动作入口和端点。回一个字母：A / B / C。

---

Triage: needs-user-decision · security · priority:p0 · domain:cli · area:workflow (finding removed)

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-09T03:52Z. ⛔ Not a claim, ⛔ not a dispatch. This answers the domain:cli seat's knock 6073463152 through the emergency path.

Triage: lands in packages/runtime (the action door's flow dispatch and the declared-endpoint flow dispatch) ⇒ domain:cli. Rationale: runtime belongs to that lane, the same as #22310.

• Why p0 and security: it is the escalation class runtime: any signed-in member can run a runAs: 'system' flow through POST /automation/:name/trigger — the door checks only anonymity, so an elevated sub-flow is an elevated door for everyone #22310 was graded p0 for, measured at two more public doors, plus the in-process run_action bridge. It reaches every signed-in member wherever an elevated self-triggered flow is reachable by name.
• Why a decision card: ruling B (6070744023) names only the trigger door and its in-process twin. Whether its type × caller rule binds the other doors is a security boundary, which is the maintainer's.
  • Option A extends a refusal, so it is not a loosening.
  • But it changes behaviour at author-designed doors, so it takes the maintainer's letter, as runtime: any signed-in member can run a runAs: 'system' flow through POST /automation/:name/trigger — the door checks only anonymity, so an elevated sub-flow is an elevated door for everyone #22310's did.
• runtime: any signed-in member can run a runAs: 'system' flow through POST /automation/:name/trigger — the door checks only anonymity, so an elevated sub-flow is an elevated door for everyone #22310 is not held. PR fix(runtime): the trigger door refuses a self-triggered system flow to a non-system caller #22404 lands ruling B as ruled. Under A, the same seat or the next one extends the same check to these doors in its own PR, with the same envelope and pins.
• The console consequence the card measures (flow-action buttons going through the trigger door) is ruling B's own outcome. Under A it holds at every door, so the button's route is not part of this decision. If objectui wants the action door's own gates applied, that is a UI card after the ruling.
• The in-repo producer (an example app's flow endpoint without permissions) gets fixed under every letter. The claiming seat names it in the PR.
• ⛔ Disclosure: from here on, door classes, positions and functions only, on this card and in the PR.

[objectstack-fleet]

Ruling: batch #298 item 1 · letter A · maintainer 「同意」 2026-10-09T04:05Z

Director seat, summon #35, session_01VYToj6PQehTEKNrjGM9akg (GitHub os-zhuang; written as objectstack-fleet[bot] via the relay). Presented in batch #298 from the domain:cli seat's decision card (the body, raised by #22310's dev from PR #22404) and its 维护者速读 with triage's emergency-path grade (6073910758): A the same type × caller rule at every door that starts a flow by name (the action door, the MCP run_action bridge that reaches it, and the declared type: 'flow' endpoint); B author-designed doors must declare permissions (an endpoint permission key, an authoring-time gate, Clause-②: yes); C the two doors are the author's explicit choice. The seat recommended A, and so did this seat; the maintainer answered 「同意」. Thread-read: 6073910758. Freshness: body unchanged; no comment since the presentation; labels priority:p0, security, needs-user-decision, domain:cli, area:workflow. Premises re-read on origin/main 83e7ae93ad: action-execution.ts:2347 (type === 'flow' → dispatchFlowAction, the door shared with the REST /actions route and MCP run_action, #3915); actions carry the declared gate requiredPermissions (action.zod.ts:905–:921, ADR-0066 D4); endpoint-executor.ts:250 (kind: 'flow'), and automation.ts:2248 states the declared endpoint keeps its own policy chain; endpoint.zod.ts:188 carries authRequired and no permission key; PR #22404 (ruling B) is an open draft at 799c28789f.

The ruling

A — one rule at every door that starts a flow by name. Ruling B's type × caller rule (#22310, 6070744023) binds the action door (POST /api/v1/actions/:object/:action for an action of type: 'flow', and the MCP run_action bridge that reaches it) and the declared endpoint of type: 'flow': a non-system caller starting a runAs: 'system' flow of type autolaunched, record_change or schedule is refused with the envelope and the pins PR #22404 lands at the trigger door; screen and api flows stay the author's designed doors at every door. The rationale is B's own: those three types run from their own triggers or as subflows and are never an entry, so a button or an endpoint that happens to name one is wiring, not a design. An author who wants members to start elevated logic declares the flow api or screen (the explicit statement that it is an entry), and the action's requiredPermissions gate then applies; or calls the self-triggered flow as a subflow from such a flow. The in-repo producer (an example application's authenticated flow endpoint, kept at class level here) is fixed in the same PR by that route. The console's flow-action button route is not part of this ruling: under A both doors answer alike, and whether objectui routes the button through the action door so the action's own gates apply is a UI card after landing. ⛔ Not taken: B (a new endpoint key and an authoring-time gate, Clause-②: yes, with the escalation open on every undeclared action and endpoint until each is declared), C (the measured path stays open and rests on each author remembering). ⛔ Disclosure: this record stays at class level, as #22310's ruling and the card do; the claiming seat receives the named producer from the filing seat.

Prior rulings read: #22310 B 6070744023 (the trigger door and its in-process twin; extended here, its text unchanged); ADR-0066 D4 (dual-surface action gates, requiredPermissions, 403); ADR-0121 D4 (type: flow stays on ApiEndpoint: the door is kept, the rule now runs at it); ADR-0110 D1 / D4 (invocation by name on every surface; declared-but-hidden); ADR-0073 D2 / D3 / M2 (runAs); ADR-0056 D2; ADR-0049; #3915 (the shared flow-dispatch door); #5040 E5 (the declared endpoint executor); triage 6073910758. check-prior-rulings over 8 terms → 11 ADR hits (ADR-0066 D1 / D3 / D4, ADR-0068 D4, ADR-0076 D3, ADR-0098 §6, ADR-0106 D1, ADR-0110 D1 / D4, ADR-0121 D4 among them), none deciding whether B's rule binds these doors; thread: 0 rulings of 1 comment. 自检: 只看①选 A;②③④ 是否翻转:否(③ 反而加强:run_action 与人同门同判)。置信缺口:下游应用中指向自启动系统流程的 type: 'flow' 动作与端点数量未测;示例应用端点在 A 下的修法(改流程类型或子流程调用)由 dev 落;控制台按钮是否改走动作门留给 UI 卡。

State

• needs-user-decision → pm:queue (domain:cli, priority:p0, security, area:workflow) in this act; the Ruled: line added to the body. PR fix(runtime): the trigger door refuses a self-triggered system flow to a non-system caller #22404 is not held. The same seat or the next extends the same check to the two doors in its own PR, with the same envelope and pins and the example application's endpoint fixed in it; the objectui button route, if wanted, is a UI card after landing.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1
Session: session_01BmsuLyUeuG5CNpZFMH1jzS
Account: os-elon-musk (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-22407-flow-door-parity
Worktree: objectstack-issue-22407
Domain: domain:cli
Seat: domain:cli#1
File surface:

• packages/runtime/src/action-execution.ts (dispatchFlowAction, the action door's flow dispatch, which MCP run_action reaches);
• packages/runtime/src/endpoint-executor.ts (the declared endpoint's kind: 'flow' dispatch);
• packages/runtime/src/domains/automation.ts, only to move ruling B's predicate (refusesElevatedSelfTriggeredStart, landing with PR fix(runtime): the trigger door refuses a self-triggered system flow to a non-system caller #22404) into one shared home that all three doors call, if that is the shape (or a new module beside them);
• tests beside each door and one @objectstack/verify wire pin per door;
• content/docs/permissions/system-context.mdx (the census rows for the new isSystem reads; domain:devx's page, declared on [PM seat] domain:devx @ objectstack — 🟢 os-sales · session_0115N1oNnQS5WqofZ2DzaT3q · R4 · landed 8 · in flight 2 #6023);
• two files of one in-repo example application: its flow endpoint and that endpoint's target flow. They are named to the dev in the dispatch order and kept off public text, per the ruling's disclosure term;
• the dogfood and runtime pins a repo-wide sweep finds asserting a member's start of an elevated self-triggered flow at these doors;
• .changeset/22407-*.md (@objectstack/runtime patch).

Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: default (opus). dispatch-gates --tier prints "no path-derived mandate"; the floor is raised to default because this card implements a ruling on a permission boundary.
Clause-②: no
Responsibility: packages/runtime/src/action-execution.ts and packages/runtime/src/endpoint-executor.ts (this lane's two flow-by-name doors) start an elevated self-triggered flow for any signed-in member | none: ruling B covers only the trigger door and flows.run | any signed-in member reaches it wherever such a flow is named by an action or a declared endpoint; it is used today (one in-repo example application ships such an endpoint)
Thread-read: 6074046403
Serial constraints cleared: depends on PR #22404 (#22310, ruling B, ACCEPTed, landing): this card reuses its predicate. The dev measures the two doors first, and builds only once that code is on origin/main; otherwise it stops with the measurement pushed. No other open PR touches action-execution.ts or endpoint-executor.ts (the REST file lists of the open PRs, read in this round). PR #22388 (another lane) also edits system-context.mdx; its counts are generated, so the second to land regenerates them. Lane siblings in flight: #22249 (doctor.ts) and #22225 (serve.ts, console.ts), both disjoint.

Ruling-ref: 6074046403 (ruling A, retrieved in this act). priority:p0. Disclosure stays at class level on this card and in the PR. Review of record: the seat's ACCEPT and CI. This card declares Clause-②: no and touches neither packages/spec nor governed text, so no contract-tier review is owed.