Approvals

What this page is for

Agents are powerful. Sometimes you want them to ask before doing something consequential. Approval gates are the mechanism: an agent requests permission to perform an action, the request lands in a human inbox, and the action only happens if a human clicks approve. This page is where those requests live.

Use approval gates for:

• Sending emails to external recipients
• Deleting files or data
• Making paid API calls above a threshold
• Publishing content to public channels
• Running shell commands with destructive effects
• Anything where a mistake is expensive to undo

Layout

The Approvals inbox at /approvals is a list of pending requests. Each entry shows:

• Requesting agent — who asked
• Action summary — a short description of what they want to do
• Target — the object the action will affect
• Requested — timestamp
• Expires — how long you have before the request auto-rejects (defaults to 24 hours)
• Buttons — Approve, Reject, Discuss

Click any entry to see the full request: the agent’s reasoning, the exact tool call it wants to make, and any context from the session that triggered it.

Common tasks

Approve a request

Open the request detail. Read the agent’s reasoning. If it looks right, click Approve. The agent receives the approval on its next turn and executes the originally-requested action. The outcome (success or failure) is logged back to the session.

Reject a request

Click Reject. You’ll be prompted for a short reason — write a sentence explaining why. The agent receives the rejection on its next turn and adjusts its plan. Rejection reasons are visible to the agent, so being specific helps: “Don’t send emails to external addresses without checking the domain” is more useful than “no”.

Discuss before deciding

Some requests need a back-and-forth before you can decide. Click Discuss instead of approve/reject. This opens a comment thread attached to the request — you can ask the agent for clarification, and the agent sees your question on its next turn and responds. When you’ve decided, return to the approval inbox and click approve or reject.

Let a request expire

If you do nothing, the request auto-expires after its configured TTL (default 24 hours) and is treated as rejected. The agent receives the rejection and moves on. Use this as the safe default — doing nothing is the same as saying no.

Configuring which actions require approval

Approval gates are configured at two levels:

1. Global rules — on /admin/rules (or the Global Rules page), you define which tool calls across the instance require approval. For example, “any send_email call requires approval when the recipient is not on the allowlist” or “any shell call with the word delete requires approval”.
2. Agent rules — on the agent edit page, you can further restrict that specific agent. “This agent’s file_system writes require approval”.

Global rules apply to every agent. Agent rules layer on top. The effective rule set for an agent is the union of global + agent-specific.

If a tool call doesn’t match any rule, no approval is required and the agent executes directly. The default is no gate — gates exist because you explicitly add them.

Notifications

When a new approval request arrives, Exolvra can notify the right people:

• In-app badge — a red dot on the Approvals sidebar item for every admin
• Email — if the user has enabled email notifications for approvals in their profile
• Webhook — fire an HTTP request to a configured endpoint (useful for piping to Slack or PagerDuty)

Configure instance-wide notification defaults from Config → Notifications.

Who can approve

By default, any admin can approve any request. You can narrow this:

• Role-scoped — only admins, or only a specific role
• Team-scoped — only users in the same team as the requesting agent’s project
• Explicit approvers — a named list of users on each rule

Role-scoped is the common choice: approvals require admin review regardless of which team the agent is working for.

Common pitfalls

Adding too many approval gates. If every tool call needs human review, agents stop being autonomous and start being drag-down overhead. Gate only the actions you actually want human oversight on.

Not being specific in rejection reasons. Agents learn from rejection reasons. A one-word rejection teaches nothing. A specific rejection (“The recipient is not on our outreach list; confirm with marketing before sending”) teaches the agent how to avoid the same mistake next time.

Letting the inbox fill up. Unattended approval requests expire after their TTL and count as rejections. Agents waiting on expired requests fall back to their post-rejection behavior, which may not be what you want. Clear the inbox daily if you’re relying on approval gates.

Common approval patterns

Email gate — any send_email call requires approval. Keeps agents from emailing the wrong people.

Cost gate — any tool call whose estimated cost is above $0.50 requires approval. Prevents runaway spending on individual operations.

Shell gate — shell calls require approval when they contain destructive verbs (rm, delete, drop). Catches dangerous operations before they run.

Publish gate — any tool that writes to a public channel requires approval. Prevents surprise public output.

Where to go next

• Security and cloud mode — the broader capability model
• Audit log — approvals are logged here
• Admin overview — the broader admin setup