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

# Autonomy and Approvals

> Decide what an agent may do on its own, what pauses for a human, and where the audit trail lands.

Every capability call an agent makes passes through one admission decision before
it dispatches. That decision is the autonomy gate. This page covers what you
configure and what the platform does with it.

## The three outcomes

A call is **allowed**, **paused** for a human, or **denied**. There is no fourth
answer and no way to dispatch around the door.

## Risk tiers

Tiers are declared in code per tool, not configured. They are the input the
level rules act on.

| Tier           | Built-in tools in this tier                                                                                                           |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Read**       | Web Search (all), Knowledge Retrieval (all), Files `ls` / `read` / `stat` / `exists`, Memory `recall`                                 |
| **Act**        | Files `write` / `append` / `rm` / `rmdir` / `mkdir` / `cp` / `mv`, Memory `store` / `forget`, HTTP Client, Code Runner, Browser (all) |
| **Privileged** | Sandbox, Computer, Plugin Builder, Skill Builder, Workflow Builder                                                                    |

Plugin tools and connector tools are **Act**, kind-wide.

HTTP Client is Act even for a `GET` — the verb lives in the arguments, so the
whole tool rides the higher tier.

## Autonomy levels

Set an agent's level under **Agents → (agent) → Autonomy**.

| Level                    | Read  | Act and Privileged                             |
| ------------------------ | ----- | ---------------------------------------------- |
| **Full**                 | Allow | Allow                                          |
| **Supervised** (default) | Allow | Check the allowlists; pause if nothing matches |
| **Read only**            | Allow | **Deny** — the allowlists are not consulted    |

Read-only is a terminal deny, not a pause. Nothing on an allowlist can rescue an
Act call at that level.

## The allowlists

Two lists. `pay` on one connector never matches `pay` on another.

* **Auto-approve** — the agent may run these without asking. It fills in when a
  person answers an approval with "allow always", which not every client offers
  — see [Where a human can actually answer](#where-a-human-can-actually-answer).
  A per-agent seed list pre-populates it for users who have not answered
  anything yet. Under **Agents → (agent) → Autonomy** you can revoke entries;
  you cannot type new ones in, because approvals are argument-scoped.
* **Always ask** — force a pause, even at Full, even when the tool would
  otherwise never pause. Always-ask pauses offer only "once" and "deny"; they
  never offer to broaden.

There is also a **per-thread window**, populated when someone answers "allow for
this thread". It is kept separate from auto-approve so the audit record shows
which source actually fired.

Editing a seed list does not retro-edit anyone who has already answered.

## Where a human can actually answer

| Surface                             | Behavior                                                                                                           |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Portal Playground and AG-UI clients | The run pauses and the client renders an approval; the answer resumes it                                           |
| A2A clients                         | The task goes to `InputRequired`; the client resumes with a follow-up message carrying the decision                |
| Workflow runs                       | Gates ride the run-detail payload in the Portal; approve or deny there                                             |
| Management API                      | `GET /v1/gates/pending`, `POST /v1/gates/{id}/decision`                                                            |
| **MCP gateways**                    | **Auto-deny.** No channel exists to ask, so a would-be pause becomes `non_interactive_surface`                     |
| **Slack, Telegram, SMS**            | **Auto-deny.** No approval can be asked over these surfaces, so a would-be pause becomes `non_interactive_surface` |

The Portal's chat approval card offers three answers: **allow once**, **allow for
this thread**, and **deny**. "Allow always" — the answer that writes a standing
auto-approve entry — is not one of them; it reaches the gate through the
Management API and through AG-UI and A2A clients that offer it.

<Warning>
  An "always ask" pin on an MCP gateway is a deterministic deny, not a prompt.
  Everything reaching a gateway is unattended.
</Warning>

## Account-wide controls

Under **Settings → Autonomy** (Admin and Owner only):

* **Enforcement toggle** — the tenant-level switch.
* **Disabled tools** — an account-wide denylist keyed on `(capability, tool)`.
  A denied tool is refused before any level or allowlist is consulted, and the
  denial is recorded with reason `authority_denied`. A deny written while a
  request is parked overrides an approval that predates it.

A per-user version of the denylist lives on each user's detail page under
**Settings → Users → (user) → Policies**.

There is **no global kill switch** that stops all agent activity at once.

## The hardline floor

A short list of tool names is refused in code, before anything else, and cannot
be re-enabled from the database or the Portal: `account_delete_self`,
`bulk_credential_export`, `tenant_scope_bypass`, `mass_principal_revoke`.

## Gate expiry

An approval or auth gate that nobody answers expires after **10 minutes** and is
recorded as a denial with reason `expired`. A form gate expires after **15
minutes**.

Arguments shown on an approval card are redacted through a conservative
substring denylist covering keys containing `password`, `secret`, `token`,
`apikey`, `auth`, `credential`, `bearer`, `cookie`, `session`, `jwt`, and
similar. The tamper-binding hash is computed over the unredacted arguments and is
deliberately not returned to the client.

## The audit trail

Every gate decision — allowed, paused, or denied — emits one journal event.
Management-plane denials (someone without authority trying to read or write a
resource) land in the same event stream with a different payload shape.

Read it in the Portal at **Agents → (agent) → Audit**, or under **Activity**
filtered to *Gate decision*. Each row records what was called, which tier it was,
which rule decided, who resolved it if a human did, and whether the answer came
from a different channel than the one that asked.

Audit is load-bearing, not decorative: if a decision cannot be written, a
**Privileged** allow is converted to a deny with reason `audit_unavailable`. Act
tolerates a short window; Read still dispatches.

The audit view exports to CSV, capped at **10,000 rows** with a truncation
marker.

## Workflows

Workflow steps are allowed inside the policy stage without consulting level or
allowlists — a workflow is an explicit, authored plan, and human review belongs
in the graph as an **Approval node**. Hardline and the account denylist still
apply. A Privileged auto-allow inside a workflow emits an audit row of its own.

See [Human approval in workflows](/docs/run/workflows/human-in-the-loop).

## Next

* [Users and roles](/docs/run/platform/team-management)
* [Built-in capabilities](/docs/run/capabilities/overview)
* [MCP gateways](/docs/run/platform/mcp-gateway)