Skip to main content
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. 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. 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. 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

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.
An “always ask” pin on an MCP gateway is a deterministic deny, not a prompt. Everything reaching a gateway is unattended.

​
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.

​
Next