windmill/docs/operator-builder-rights.md

# Operator builder rights

Two workspace settings, `operator_settings.builder_flows` and `operator_settings.builder_apps`,
that let every operator of that workspace compose flows and full-code apps out of runnables that
already exist. Neither lets them author backend code or run arbitrary code on a worker, the
boundary the operator role draws. The app right does let them write the app's frontend code,
which runs in the viewer's browser and is why that right rests on sandbox isolation.

They are granted **independently**, because the two are not equally verifiable. A composed flow is
checked in full server-side (`check_flow_is_composition_only` refuses everything carrying code).
A full-code app is a browser-built bundle no server-side check can read, and rests instead on
forced `sandbox` isolation plus the viewer consent prompt. An admin may reasonably want the first
without the second, so **never gate on "either"**: a gate that does authorizes the kind its
workspace never granted, which is the whole point of the split. `BuilderKind` exists to make each
call site say which one it means.

These are write rights, unlike the visibility flags beside them, and unlike the withdrawable
rights in `docs/operator-write-rights.md` they are granted on request and cost a seat. Read them
with `windmill_common::workspaces::operator_builder_rights` (60s cache, shared with the
withdrawable rights), which returns an `OperatorBuilderRights { flows, apps }`, and gate a write
with `check_operator_can_build`, naming the `BuilderKind`. `.any()` is only for surfaces that are
genuinely not per-kind: the seat a membership costs, and listing drafts.

## What the check has to cover

`check_flow_is_composition_only` (`windmill-common/src/flows.rs`) walks a `FlowValue` and refuses
anything that carries code. Three of its rules exist because the obvious walk misses them:

- **`FlowScript` and any populated `modules_node` / `default_node`.** These name code hoisted into
  a `flow_node` row. Only the dependency job produces them, so an authored value carrying one
  names code stored under some other flow. The walk covers `modules`, so a node reference is a way
  past it.
- **An AI agent step's `tools`.** `ToolValue::FlowModule` wraps a whole `FlowModuleValue`, so a
  tool can be a raw script.
- **An AI agent step's `agent` link.** A linked agent resolves its tools from an `ai_agent`
  resource at run time, and operators may write resources, so the tool list is outside this check
  and can be swapped for a raw script after the flow is approved.

It also returns what a value-only walk cannot authorize, for the caller to check against its own
permissions:

- **the worker tags the steps pin**, or a builder routes a job onto a privileged worker group;
- **every runnable a step references**. `script_to_payload` resolves a step's path with the root DB
  handle (`db_authed = None`) and returns the referenced runnable's `on_behalf_of`, which
  `worker_flow` then applies to the step job. So composing a path is enough to run it, and to run
  it as whoever it runs as: `validate_operator_composed_flow` re-checks each path under the
  caller's RLS. This is the general case; the one below is on top of it, not instead of it.
- **the `(path, hash)` of every version-pinned step**. A step carrying a `hash` is dispatched by
  that hash alone, with the path beside it never consulted, so a readable path paired with another
  script's hash still runs that other script.

The value is not the only code a flow carries: the schema's `x-windmill-dyn-select-code` fills its
dynamic dropdowns, run as whoever loads the form, so `validate_operator_flow` refuses it like a
step's code. A builder therefore cannot save a developer's flow that has dropdowns; its editor
still previews them through the deployed flow rather than the inline route operators are refused.
Which developer flows a builder may edit at all is left to permissions: write access to the flow
or its folder.

Call it on every write **and** every preview: `run_preview_flow_job` and
`push_flow_dependencies_job` both take a request-supplied flow value, so leaving either out makes
it the way to run what the write path refuses. A flow draft goes through `validate_operator_flow`
too: a developer who loads a builder's draft in the editor runs its code as themselves.

The same reasoning applies to a builder-authored app, with one extra step. `execute_component`
resolves the runnable it runs on the root handle, so `validate_operator_composed_app` checks every
referenced path under the caller's RLS and refuses hub ones. For a script it checks the version a
run would pick: grants are per version, and a path reused after its versions were archived starts
with none while the archived ones keep theirs. But it has to check **two** surfaces,
because they are not the same list: the policy's `script/<path>` and `flow/<path>` triggerables,
and the by-path entries of the app value's `runnables` map, which is what the editor resolves a
`runnable_id` against and sends. Read only that map, and refuse an entry whose `type`, `path` or
`runType` is not text.

Reading a triggerable key is not a `split_once(':')`: `execute_component` looks up
`format!("{component}:{path}")` with an unrestricted component string, so `a:b:script/x` resolves
at run time for `component = "a:b"`. Every colon is a possible split, so the check validates every
suffix that parses as a runnable rather than guessing which one a request will use.

What makes those checks bind is that **`ExecutionMode::Viewer` is refused for a builder app**. In
Viewer mode `execute_component` falls back to a default triggerable for any `script/`/`flow/`
path, so the policy stops being the list of what the app may invoke, and the job runs as the
*viewer*: an admin who merely opened the app would run anything in the workspace as themselves.
`Publisher`, `Guest` and `Anonymous` have no such fallback; all three run as the publisher. If you ever relax the Viewer refusal, the
deploy-time path checks above stop being an authorization boundary.

## The two raw-app deploy paths are not equivalent

`create_app_raw` / `update_app_raw` are multipart: the browser already built the bundle, and
nothing server-side compiles anything. Builders use these.

`create_app_raw_source` / `update_app_raw_source` push a bundler CLI over caller-supplied `files`
as a job **on a worker**, which is arbitrary code execution and is why they already require
`jobs:run` on top of `apps:write`. They stay closed to operators, builder rights or not. Do not
"tidy" the exception away: it costs builders nothing, because the browser and the CLI both bundle
locally and deploy through the multipart endpoints.

A builder-authored app is forced to `policy.sandbox = true`. That is what makes it safe to let an
operator publish a bundle nobody reviewed: without it the bundle runs same-origin with each
viewer's Windmill session. The same check refuses a `rawscript/<sha>` key in either triggerables
map, since that key is the deployed app's authorization to run caller-supplied `raw_code` hashing
to it. It reads the value as stored, NUL escapes stripped: a stripped NUL can turn a key it
ignored into `inlineScript`.

`update_app` takes a builder too, but settings only: the deploy panel saves a deployed full-code
app's access and frontend scopes through it with no value. It reaches the same check, so a builder
can no more switch the sandbox off there than on deploy.

A builder's **draft** goes through the same `check_operator_composed_app` as its deploy, with
`BuilderAppWrite::Draft`: an admin may open it in the editor or deploy it as it stands, so any
rule added for deploys must hold for drafts too. Where the two differ, `write` decides: a deploy
fills in an omitted sandbox or mode, since it stores the policy it checked, while a draft skips
`triggerables_v2` and must not name another user's run identity. Every frontend writer of a
builder draft must conform the policy first with `conformBuilderAppPolicy`, since a policy loaded
from someone else's app breaks these rules: the editor and the AI chat do. The AI Sessions raw-app
editor, open to operators only behind a per-browser opt-in, does not, so its autosaves are refused.

The raw-app editor previews an app isolated only when its policy has `sandbox`, and otherwise runs
the bundle same-origin with the session of whoever opens it. A builder's draft is therefore
held to the same rule as its deploy: `update_draft` refuses one whose `policy.sandbox` is not
`true`, so whatever an admin opens of an operator's, deployed or drafted, previews isolated.
Turning the sandbox off in their own editor stays that admin's explicit choice. It also refuses
a draft naming a runnable the builder cannot read, or a hub one, like the deploy: the editor
preview runs them as whoever opens it, and admits any path for an admin. That covers the
policy's legacy `triggerables` too, `rawscript/` keys included: every deploy of a draft
carries it through untouched, so an admin deploying the draft would publish it. Its
`triggerables_v2` is not checked: every deploy of a draft rebuilds it from the runnables, the
preview never reads it, and a copy gone stale since the last deploy would otherwise block
autosave. `Viewer` mode is refused in a draft as on deploy: the deploy panel shows it as
members-only, so an admin deploying the draft would publish it unawares. The builder's editor
switches it to `Publisher` on load, since that panel offers no way out of it. A draft naming a
run identity other than its builder is refused for the same reason: a builder's own deploy resets
it, but an admin's one-click draft deploy preserves it without showing it. The builder's editor
drops another user's identity on load, which an app that user deployed carries. A builder in
`wm_deployers` is the exception: like any member, their deploy may keep another identity, which
was judged acceptable for operators in that group (WIN-2536) and is the same for composed flows.

Reading a triggerable key at every colon copies it once per colon, so the check refuses a key
over 512 bytes before splitting: a quadratic walk otherwise lets a sub-megabyte key allocate
gigabytes. A 255-character path plus a component name stays well under it.

## Billing

An operator of a builder workspace consumes a full author seat. This is the one place that reads
"either right", and deliberately so: either one makes an operator an author of deployable
artifacts, and there is no half-author, so granting both costs no more than granting one. Do not
introduce per-right pricing — it turns one boolean into a capability matrix that billing, the cap
check and the displayed count would each have to agree on.

`consumes_operator_seat` is the seat-role helper; the EE counting queries share
`OPERATOR_SEAT_SQL` so the displayed, enforced and reported numbers agree. The one exception is
`get_user_usage` in `stats_ee.rs`: it is a compile-checked `query!`, which cannot interpolate the
constant, so it spells the predicate out. Change both together. On cloud, `billable_seats` applies
the same rule; see its doc for the out-of-repo invoice it must match.

Granting the first right runs `check_seat_cap_for_operator_builder`, which prices the change by
counting seats twice rather than by counting the workspace's operators: an operator who already
authors elsewhere must not be charged again. Adding the second right later, or re-saving settings
that already have one on, is a zero delta and never blocks.

## Accepted risks

- A builder raw app may declare `frontend_sdk_scopes`, and `mint_raw_app_sdk_token` mints as the
  *viewer*. A consenting admin therefore hands the bundle a 12h admin-identity token within the
  curated scope list. The viewer consent prompt is the gate, shown by the editor preview as well
  as the deployed app, before any token is minted. The lever, if this is ever revisited,
  is dropping `variables:read` / `resources:read` / `jobs:run` from `FRONTEND_SDK_ALLOWED_SCOPES`
  for builder apps.
- The raw-app editor preview runs an app's runnables as whoever has the editor open, where the
  deployed app runs them as its publisher. An admin opening a builder's app in the editor lets its
  frontend code run, with the admin's rights, any runnable the builder can read. Running as the
  draft's author instead would need a preview that ignores unsaved edits to the runnable list.
- A builder may make an app public (`ExecutionMode::Anonymous`): anyone with the URL runs the
  runnables its policy names, as the builder. Refusing it is the workspace's call, through the
  `RestrictAnonymousAppDeployment` protection rule. A `Guest` app is the same with a login in
  front: anyone the instance's identity provider admits, member or not, once guest access is
  enabled. `RestrictGuestAppDeployment` refuses it.
- A builder raw app may set `allow_user_resources` on a runnable's inputs, and the bundle picks the
  `$res:` path it sends. `build_args` resolves that path as the *viewer*, with no prompt, into a
  job that runs as the builder. Getting a value out takes a guessable path and a readable script
  that returns, logs or sends its input. Developers can do the same; the lever is refusing a
  non-empty `allow_user_resources` (and `s3_inputs[].allow_user_resources`) for builders.
- A builder's delete or settings-only update reads the app's kind before the write, not under a
  lock held through it. An admin converting that app to low-code in between lets the builder's
  request land on the low-code app; the builder already has write access to its path.
- A builder's draft carries no run identity other than the builder's own, and deploying one that
  carries none makes the deployer its run identity, as any deploy does. An admin deploying such a
  draft, from the editor or Compare & Deploy, therefore publishes the builder's code running as
  that admin; the deploy is the admin's explicit act, as it is for a developer's draft.
- All-or-nothing per workspace: there is no per-user builder role.
- `operator_settings` is git-synced, so a pull can flip every operator's class in a workspace and
  the billed seat count with it.
- A builder writes JavaScript expressions: step inputs, branch predicates, `stop_after_if` and
  `suspend`. They run in QuickJS with no filesystem or network access, and forbidding them would
  leave nothing to compose with.