# Approving actions

How Soku asks before a write-capable action runs, what each approval choice covers, and why an approval is remembered per command rather than per run.

# Approving actions

Soku reads freely, but anything that writes — changing a campaign, sending a message through a connected app, calling a third-party tool that costs credits — stops and asks you first. That stop is an **action review card** in Chat.

## What the card offers

| Choice | What it covers |
| --- | --- |
| **Approve** | This one call, as shown on the card. Nothing is remembered. |
| **Allow this session** | This command for the rest of *this* conversation, for up to 24 hours. |
| **Always allow** | This command in this brand, from now on, until you revoke it. |
| **Reject** | Nothing runs. The agent continues without it. |

## What an approval remembers

An approval is remembered against the **command**, not against the run. For ordinary actions the specific arguments you saw on the card — which channel, which campaign, which account — are not part of it.

The command is the action itself plus, for ads, the platform — for example "send a Slack message", or "change a Google Ads budget". So:

- **"Always allow" is brand-wide.** Approve "send a Slack message" once and later sends run without a prompt — including a different channel, and including sends from a scheduled automation run. It does not need re-approving weekly, per run, or per destination.
- **A sibling command is still gated.** Approving one operation on a connected app never approves a different one: "send a Slack message" and "delete a Slack message" are separate commands with separate grants. Approving a budget change on Google Ads does not approve the same change on Meta.
- **Raw queries and raw API calls are the exception.** When the card shows a database statement, or a direct API call to a connected app, that statement or endpoint *is* the command. A different query or a different endpoint is reviewed again, even under a standing grant — approving one is deliberately not approving the next.
- **"Allow this session" does not reach your automations.** Every automation run happens in its own conversation, so a session grant made in your chat is not in scope there. If you want an automation to run unattended, use **Always allow**. A session grant also lapses after 24 hours, so a conversation you come back to the next day asks once more.

## What is never remembered

Two kinds of review ask every single time, by design:

- **Guardrail configuration** — changing the brand's write rules or the emergency stop. A standing grant here would let Soku rewrite its own limits, so only a fresh human decision can change them.
- **Priced third-party calls** — when a card shows you what something will cost, you approve an amount, and an amount cannot be carried forward. You can mute a vendor's prompts for the rest of the conversation, which stops the asking without pre-approving any spend.

## Seeing and revoking what you granted

Open **Settings → Auto Approvals** in the brand. It lists every "Always allow" grant with its action, platform, and when it was granted, and lets you revoke any of them. Revoking makes that command prompt again next time; work already running is unaffected.

Approvals are separate from [Autopilot](/docs/autopilot-controls). Autopilot's L0/L1/L2 levels decide how its own proposals are handled; the card above is the gate on actions the agent takes in Chat and in automations.
