> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wearecorgi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals

> How Token acts on your behalf without being a security risk.

Token can act on your behalf, but it does not get a blank cheque. Anything that
touches an outside service (your notes, your calendar, the web, a message to
someone) is checked before it runs. The check happens on the server, not inside
the AI, so it holds even if a message tries to talk Token into ignoring it.

Most of the time this is invisible. Whether an action runs on its own or pauses
is decided by rules, not a guess: actions an allow rule already covers just
happen, and you only see an approval when one does not.

```mermaid theme={null}
flowchart TD
    A[You ask Token to do something] --> B{Does it touch an<br/>outside service?}
    B -->|No| R[Token just replies]
    B -->|Yes| C{Allowed by<br/>a rule?}
    C -->|Yes| D[Runs automatically]
    C -->|No| E[Posts an approval card]
    E --> F[An approver decides]
    F --> D
```

## When Token asks

When Token is about to do something that no rule yet allows, it pauses and posts
an **approval card** to an approver. The card shows exactly what Token wants to
do, the real action and its details, not a summary written by the AI. So Token
cannot dress up what it is actually about to do.

<Warning>
  The card always shows the parts that matter for the decision: who a message
  would go to, what it says, the link being opened, and which account would act.
  Those consent details can never be hidden.
</Warning>

<Tabs>
  <Tab title="Slack">
    The approval arrives as a card with buttons. The bar is amber while pending,
    turns green when approved, and red when declined.

    > **Send email**
    > To: [someone@yourcompany.com](mailto:someone@yourcompany.com), [guest@external.com](mailto:guest@external.com) (external)
    > Account: [you@yourcompany.com](mailto:you@yourcompany.com)
    > \[ Approve once ]  \[ Always allow ]  \[ Decline ]
  </Tab>

  <Tab title="WhatsApp">
    Where rich buttons are not available, the same approval arrives as a short
    message you answer by replying with a number.

    > **Send email** to [guest@external.com](mailto:guest@external.com) (external)
    > Reply **1** to approve once, **2** to decline, **3** to always allow.
  </Tab>
</Tabs>

## The buttons

| Button           | What it does                                                                       |
| ---------------- | ---------------------------------------------------------------------------------- |
| **Approve once** | Allow this one action. Nothing is remembered.                                      |
| **Always allow** | Allow it and remember, so this kind of action is approved automatically next time. |
| **Decline**      | Block this one action.                                                             |

The middle button adapts to the situation. When the action would reach another
channel or an outside domain, it names the scope so the approver knows exactly
what they are signing off, for example **Always for #marketing** or
**Always for example.com**.

<Note>
  A remembered rule is tied to the specific account that was approved. If Token
  later tries the same action with a different account, it asks again.
</Note>

For destructive actions, like deleting something, the **Always allow** option
does not appear at all, so the approver only gets **Approve once** or **Decline**
and the choice stays deliberate every time. For actions that send data outside
the team, Always is offered more cautiously, scoped to just that channel or that
one website, and sometimes not at all.

## It gets quieter over time

<Steps>
  <Step title="The first days are the noisiest">
    More things are unfamiliar, so more actions need a look.
  </Step>

  <Step title="Approvers tap Always allow on the safe ones">
    Each one saves a rule, and that kind of action stops interrupting people.
  </Step>

  <Step title="Routine work flows on its own">
    After normal use settles in, most actions are approved automatically and
    Token rarely needs to ask.
  </Step>
</Steps>

Approvers can review and remove these rules at any time with
[`/token-rules`](/slash-commands).

## Who can approve

Who can approve depends on whose account is involved. When the action uses an
account that someone on the team connected, only that person, the account's
owner, can approve it, not even an admin. When it uses a shared team account, an
admin approves. If someone who is not allowed to approve a given card taps a
button, nothing happens.