Permissions and risk
What the assistant may do for each user, and when it has to ask first.
Permissions come from your token
Each action in your registry lists the permissions a user must hold to run it:
{ "name": "refund_order", "permissions": ["orders.refund"] }The user's permissions come from the permissions claim of the
user token your backend signed, and from nothing else.
Nothing the browser sends can add one. A user must hold every permission
an action lists. An action that lists none is open to any signed-in user of the
app.
An action the user cannot run is never offered to the model at all, so it cannot be attempted. Your own backend still checks again when a backend action arrives, because it is the last place that can say no.
Risk tiers
| Tier | What it is for | Confirmation |
|---|---|---|
low | Filtering, searching, showing. | Runs straight away, unless the action sets requireConfirmation. |
medium | Drafts, non-critical updates, reports. | Runs straight away unless the action sets requireConfirmation. The user may confirm by typing or saying yes, unless it also sets requireUiConfirmation. |
high | Refunds, deletions, charges, anything that moves money. | Always confirmed, always by an on-screen tap. A typed or spoken "yes" is refused, in every mode including voice. |
An unrecognised tier is treated as high.
Set tiers deliberately. An action that runs without asking is the one
thing injected text in your data could trigger, within what the user is
already allowed to do. If you would not want an action to run without the user
seeing it first, give it requireConfirmation or make it high.
Changing them without a deploy
On the app's Registry tab in the dashboard, each action has four settings a product person can change without touching code:
- Enabled, the kill switch. A disabled action is never offered and never runs.
- Risk tier.
- Requires confirmation.
- Requires an on-screen tap.
A change takes effect on the next session. These overrides survive your next publish, so a deploy cannot quietly undo a decision made in the dashboard. The tab marks what has been overridden and lets you reset it to the published value.