Require approval for tool calls
Hold risky tool calls until the person the agent acts for approves them by email
If you don't see this feature in your console, ask your SecureAuth contact to
enable the require_approval feature flag for your organization.
Some actions are fine for an agent to take, but not without someone saying yes first: sending an email, merging a pull request, or refunding a payment. A Require approval for rule holds those tool calls until the person the agent acts for approves them by email. Nothing runs until they do.
How an approval works
- The agent calls a tool that a Require approval for rule matches.
- The gateway pauses the call and emails the person the agent acts for, naming the tool and what the agent wants to do.
- The agent is told the call is waiting for approval, not failed, and to try again with the same arguments. The gateway holds each retry for up to 20 seconds and answers as soon as the person decides.
- If the person approves, the call runs. If they decline, or don't answer in time, the call doesn't run and the agent tells them it wasn't approved.
The gateway never approves a call on its own. A request the person doesn't answer expires, two minutes after it's raised by default.
Write an approval rule
- On Controls › Agent Access, add a rule.
- Choose Require approval for as the effect, then pick the agents, users, groups, MCP servers, tools or labels it covers.
- Choose how long one approval is reused, and which later calls it covers.
- Save the rule, and place it where it decides the calls you want: the first rule that matches a call decides it.
A label is the easiest way to cover risky tools everywhere.
For example, require approval for tools labeled destructive or external, and every catalog tool that deletes data or sends something outside your organization asks first.
See Tool labels.
Reuse an approval
Asking for every single call would drown people in emails, so one approval can cover later calls for a while.
Reuse approval sets how long:
| Choice | One approval covers later calls for |
|---|---|
| never | No later calls; every call asks |
| for 15 minutes | 15 minutes |
| for 1 hour | 1 hour (the default) |
| for 8 hours | 8 hours |
| for 1 day | 1 day |
| custom | The number of minutes you enter |
Approval covers sets which later calls count:
- identical calls (the default) – the same tool with the same arguments.
- the same tool – any call to that tool, whatever its arguments.
- all tools in this rule – any call the rule holds.
The email names that reach, so the person knows what they're agreeing to. Keep risky actions on identical calls with a short window, so approving one refund doesn't approve the next.
When a call can't be approved
| Outcome | What happened |
|---|---|
| Declined | The person said no. |
| Expired | Nobody answered before the request expired. |
| Unavailable | The request couldn't be sent, for example because the person has nothing set up to receive it. |
In every case the call doesn't run, and a declined or expired request can be raised again on a later call.
See approvals in Agent Trail
Agent Trail records each step as its own event: Approval Requested, Approval Granted, Approval Declined, and Approval Expired. Each names the tool, the person, and the rule that held the call, with its reuse window and what one approval covers. A call that couldn't run also appears as a tool error, so you can filter for refused calls.
Next steps
Risky tool calls now wait for the person the agent acts for to say yes. Next, decide which tools need it.
- Tool labels – cover every destructive or external tool with one rule
- How rules apply – where approval fits in the order of checks