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

# Assistant governance

> Approval policies for write actions, per-key call budgets, and the activity trail.

An assistant that can act on your workspace needs controls. This page covers the three: what each
action is allowed to do, how much a key may spend, and what happened.

## Approval policies

Each write action carries one of three states, set under **Settings, then Channels**, in the
assistant permissions card:

| State      | Behaviour                                           |
| ---------- | --------------------------------------------------- |
| **Allow**  | Runs immediately                                    |
| **Ask me** | Parked, and an approval card goes to your approvers |
| **Never**  | Refused outright                                    |

The four write actions are acknowledge escalation, send reply, pause agent and resume agent.

Defaults are asymmetric on purpose. Sending a message to a real customer is treated more carefully
than acknowledging an escalation.

Only owners and admins can change these.

### How approval works

An action set to **Ask me** neither runs nor fails. It parks for an hour and posts a card to your
approvers on [Telegram](/assistants/telegram).

The card is the dry run. It shows what will happen, in words, before anyone approves it: which
customer, on which channel, with what text. An approver reads the actual consequence rather than a
tool name.

If nobody approves within the hour, the request expires. Nothing is queued indefinitely.

## Call budgets

Each API key can carry a budget:

| Control                 | Effect                                                                   |
| ----------------------- | ------------------------------------------------------------------------ |
| **Monthly call budget** | The ceiling for the month                                                |
| **Soft budget**         | A warning line that raises an alert when crossed                         |
| **Requests per minute** | A rate ceiling for this key                                              |
| **Hard stop**           | Whether crossing the monthly ceiling blocks further calls, or only warns |

Hard stop is off by default. A budget that silently cuts off an integration mid-month is usually
worse than one that warns.

<Note>
  Budgets are denominated in assistant calls, not in currency. Your bill is a commercial matter, and
  a per-call meter is something you can reason about without us publishing our costs on your usage
  page.
</Note>

Owners and admins are alerted the first time a key crosses its soft line and again the first time it
crosses the hard one. Once per key, per month, per threshold, so a busy key does not spam the people
who can fix it.

## Usage reporting

**Quality, then Assistant, then Usage** shows per key: consumed, warning line, ceiling, remaining, a
30-day burn chart, and badges at 80% and 100%.

**Quality, then Assistant, then Activity** is the performance view: calls over 24 hours, 7 days and
30 days, how many distinct operators are active, error rates split between request errors and tool
errors, the busiest minute against your rate limit, and a per-surface breakdown.

These are deliberately separate screens. Consumption is a question for whoever owns the budget;
performance is a question for whoever owns the integration.

## The activity trail

One trail covers reads and writes across all three surfaces: MCP tool calls, assistant turns,
feedback and operator actions. Filter by who acted and what they did. Each row shows the actor, the
action, the target, the outcome and the time.

Actor labels resolve at read time, so a person shows as their name and a key shows as its label.

<Note>
  Where a report would name a single colleague from a small sample, it is suppressed. Assistant
  reporting is there to show you how the integration is performing, not to surveil individuals.
</Note>

## API key hygiene

Keys used for assistants follow the same rules as every other key, with two additions worth knowing:

* **Keys can expire.** Set an expiry rather than relying on remembering to revoke.
* **Rotation is atomic.** Rotating issues the replacement and ends the old key in one step,
  inheriting its scopes, with an optional grace period of up to 30 days so you can cut over without
  an outage.

Last used, last used from which address, and last used by which client are all recorded, so an
unfamiliar key is answerable rather than a mystery.

See [Authentication](/api-reference/authentication).