Automation flow write routes (POST/PUT/DELETE /api/v1/automation) lack the manage_metadata gate — a plain tenant edits/deletes flows for every organization on a walled shared-database deployment

[baozhoutao]

Summary

On the walled single-database hosted-SaaS shape (OS_TENANCY_POSTURE=isolated, HotCRM as composed artifact, OS_AI_STUDIO_AGENTS=ask), the automation-domain write routes are not gated by manage_metadata. A plain tenant org owner — holding organization_admin only, demonstrably without manage_metadata / studio.access — can create, modify and delete automation flows. Flow metadata is environment-scoped, not organization-scoped, so one tenant's write lands on the layer every organization runs on: a flow one tenant deletes vanishes for all tenants and the platform admin; a flow one tenant creates appears for all of them.

This satisfies both of the deployment's highest-severity criteria at once: metadata is mutable by a tenant, and the mutation crosses the tenant wall.

Measured over HTTP (fresh composed boot, framework 8798cd2, hotcrm 3940736)

Same northwind session (org owner, no manage_metadata) — the control that proves the account is unprivileged:

• PUT /api/v1/meta/:type/:name, POST /api/v1/ai/tools/:tool/execute, POST /api/v1/packages/* → all 403.

Yet on the automation domain:

POST /api/v1/automation {name:'probe_flow_x',label:'Probe Flow X',type:'autolaunched',nodes:[],edges:[]}
 → 200 {success:true, data:{name:'probe_flow_x',…}} # created
PUT /api/v1/automation/probe_flow_x {…}
 → 200 {success:true} # modified
DELETE /api/v1/automation/lead_auto_assignment
 → 200 {success:true, data:{name:'lead_auto_assignment', deleted:true}} # deleted a HotCRM-shipped flow

Cross-tenant blast radius, verified by reading back as three different principals:

flow	northwind (actor)	contoso (unrelated tenant)	founder (platform admin)
lead_auto_assignment (deleted)	404	404	404
probe_flow_x (injected)	200	200	200

So one tenant deleted a flow out from under every other tenant, and injected a flow into the shared layer that every tenant now sees.

Root cause

The /api/v1/automation POST/PUT/DELETE handlers register without the manage_metadata authorization the parallel /api/v1/meta/* writes carry (route ledger: packages/runtime/src/route-ledger.ts:317,329,330; the /meta/* gate is manage_metadata per packages/rest/src/rest-server.ts). A flow is authored metadata registered at environment scope, so an ungated write is both a privilege escalation and a cross-tenant one on any multi-organization deployment.

Requested fix

Gate the automation-domain write routes with manage_metadata, identical to /api/v1/meta/*. On a walled posture, environment-scoped metadata writes must be refused for principals without manage_metadata — the same rule that already makes /meta/*, /packages/* and the AI authoring tools 403 for a tenant on this shape.

Found during a hosted-SaaS lockdown test pass. Same batch as #10131 and #10132 (walled-shape org-attribution / catalog-visibility defects).

[os-zhuang]

Triage: fix lands at the route-registration/gating layer (packages/runtime/src/route-ledger.ts + the rest-server gate wiring, per the card's own root cause) ⇒ domain:cli + security, type Bug (already set), pm:queue, target:v17 — release-blocker classes ① and ② both hit: a published-surface defect a customer on the walled shape hits today, and cross-tenant metadata mutability is the declared contract of that shape being violated (the parallel /meta/* writes already carry the gate).

Priority note: measured cross-tenant metadata write+delete by an unprivileged tenant is the top of the current v17 board; the Priority: Urgent field is consistent with that. Dispatch note: gating previously-open write routes narrows the accepted caller set ⇒ expect Clause-②: yes at claim; refusal tests assert the ADR-0112 envelope, mirroring the /meta/* gate's shape. Same lockdown batch: cloud#1452 (UI half), cloud#1453 (Ask posture) — coordination stays with the cloud seat; this card is the backend fix and blocks nothing on them.

---

Generated by Claude Code

[os-elon]

Claim: PM loop round 30 (lane sweep — maintainer instruction 「cli 车道的全部任务都排查一下」)
Session: session_019bmVFqoQPq63zhKrxdYG1r
Branch: claude/issue-10145-automation-write-manage-metadata-gate
Worktree: objectstack-issue-10145
Domain: domain:cli
File surface: packages/runtime/src/domains/automation.ts + its test neighbours in packages/runtime/src/domains/** · .changeset/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — ⚠️ below the claude-fable-5 floor, under the quota-exhaustion exemption. Reason: fable measurably unavailable to this lane — maintainer 2026-08-20 ~11:3xZ verbatim 「本车道目前没有 fable」, plus this seat's own model: fable probe agent terminating on You've reached your Fable 5 limit. ⛔ Not lowered further.
Clause-②: yes — adding a capability gate narrows the accept set on published REST routes (callers who write today will 403). That is accept/reject behaviour, so it is the content limb regardless of paths.
Serial constraints cleared: 🔓 free on the handler surface. ⚠️ ONE hard serial, see below.

⛔ packages/runtime/src/route-ledger.ts is SERIALISED — do not edit it

In-flight PR #10177 (#10077, this lane) already modifies that file. Ruling ①: same package is exempt, same file is a hard serial, with no region exemption. The card cites route-ledger.ts:317,329,330 as evidence, and evidence is a read, not an edit. ⇒ Read it freely; ⛔ do not write to it. If your measurement says the fix genuinely requires a ledger row change (e.g. a note recording the new gate), stop and report — I will sequence it behind #10177 rather than take a conflict. Everything else on the handler surface is free.

The defect (measured by the filer over HTTP — re-derive, don't assume)

A plain tenant org owner holding organization_admin without manage_metadata / studio.access can POST / PUT / DELETE /api/v1/automation. Flow metadata is environment-scoped, not organization-scoped, so the write crosses the tenant wall: the filer deleted a HotCRM-shipped flow (lead_auto_assignment) and it read 404 for every principal — the actor, an unrelated tenant, and the platform admin; an injected flow read 200 for all three. The control that proves the account is unprivileged: the same session gets 403 on PUT /api/v1/meta/:type/:name, POST /api/v1/ai/tools/:tool/execute and POST /api/v1/packages/*.

Requested fix: gate the automation-domain write routes with manage_metadata, identical to /api/v1/meta/*.

PM mechanism assumptions — re-derive at head, falsifying them is welcome

⛔ Claims, not facts. The card is stamped at framework 8798cd2; main has moved.

• I believe the handlers live in packages/runtime/src/domains/automation.ts. Locate by symbol, and if the registration is somewhere else, follow the code and report where.
• I believe the write set is exactly POST /automation, PUT /automation/:name, DELETE /automation/:name. ⚠️ Derive the real write set yourself from the ledger and the registrar — POST /automation/:name/toggle mutates enablement, and POST /automation/:name/trigger / .../resume execute rather than author. Those are different questions: toggling is arguably an authoring write; triggering is deliberately a lower gate and resume is already fail-closed via the suspended node's 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). ⛔ Do not sweep execution routes into a metadata gate — if you think one of them belongs, report it as a separate finding rather than folding it in.
• Verify the premise still reproduces before editing. premise_still_valid: false + no PR is a legitimate delivery.

⛔ This PR will NOT be enqueued

needs:contract-review is applied in the same stroke. Dispatch tier is below CONTRACT_REVIEW_TIER and the declaration limb is hit, so the enqueue gate forbids queueing until a seat that is (i) at contract-review tier and (ii) not this one clears it. Open the PR as a draft; ⛔ never flip ready, ⛔ never arm auto-merge, ⛔ never clear the label. Green CI does not change this.

⚠️ Say so in the PR body: this is a security fix that will sit outside the queue until reviewed. That visibility is the point — a silent wait on an Urgent cross-tenant hole is worse than a loud one.

Pin sweep — mandatory, two parts

This flips accept/reject behaviour on a published surface, so the pins move with it and assert the new semantics: a principal without manage_metadata is refused (assert code and status, the repo's minimum for a refusal case), and a principal with it still succeeds. ⛔ Keep verbatim any existing refusal assertion for a genuinely illegal shape — dropping that second half degrades the sweep into "delete everything". Sweep the whole repo in one pass, and name every pin you found.

The changeset must state the new capability requirement plainly — automation.* is published SDK surface and existing credentialed callers will start getting 403.

Local gates (derived from the tree at dispatch time — a lead, not a spec)

pnpm check:cross-package-test-inputs
pnpm check:route-envelope
pnpm check:slot-lookup
node scripts/check-cross-package-test-inputs.mjs
node scripts/docs-audit/check-affected-docs.mjs

Plus pnpm lint — dispatch-gates.mjs structurally cannot name the lint family. If you add or edit a test file the convention set also moves: check:type-check-debt (needs the workspace closure BUILT; a refusal means NOT MEASURED, never "not applicable"), check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:type-check-coverage. Re-run node scripts/pm/dispatch-gates.mjs against your actual diff and report any family this list missed — today's two devs each found ~8 it could not name.

⛔ Never weaken a gate — no threshold moved, no baseline raised, no test skipped or quarantined.

⚠️ A suspiciously fast failure is a build question before it is a code question. ⛔ Never report a red from a worktree you have not built. Three other devs run concurrently — measured verify-lock waits today were 6m56s–7m39s with one 9m00s timeout that never acquired. If a repo-wide lint cannot finish in budget, narrow it and say so; better still, prove the narrowing excludes nothing (e.g. by file count in --format json) rather than resting on a bare exit 0.

Push your COMMITS early — an empty pushed branch reads as a dead agent.

Final report: machine-checkable fields only — gates / line_budget / deviations / files_changed / premise_still_valid / pr. ⛔ No narrative restatement of the PR body.

---

Generated by Claude Code