Let agents do the work. Keep a person on the decisions that matter.
Some actions should never be fully autonomous: deleting records, paying a vendor, sending data outside the organization. A policy can return require approval, which pauses the request, shows a named approver exactly what the agent intends to do, and resumes or cancels it based on their answer.
Human in the loop has to be enforced, not requested.
Many agent frameworks support a confirmation step, but it lives in the agent's own code. A misconfigured agent, or one following an injected instruction, can skip it. In Control the hold is applied by the enforcement point after a policy decision, outside the agent. The agent cannot proceed until the gateway receives an approval.
Approvals also bind to what was reviewed. The approver sees the exact tool, arguments, and affected data. If the agent changes the request after approval, it is a new request and is evaluated again.
Who approves, how long they have, and what happens if no one answers.
id: pol_pay_002
description: Agent-initiated payments over threshold need finance sign-off
subject: { type: agent, tags: [ap-automation] }
resource: { tool: "mcp:erp/create_payment" }
action: [execute]
when:
args.amount: { gt: 5000 }
effect: require_approval
approvers:
group: ap-managers
min_approvals: 1
exclude: [requester, requester.manager_of] # separation of duties
timeout: 8h
on_timeout: denyIllustrative example · final API surface documented in /docs
Approvals that hold up under review.
Named approvers
Approvers are users or groups from your identity provider, or the registered owner of the data being touched.
Separation of duties
Exclude the requester and their reporting line, and require more than one approval where your controls call for it.
Safe defaults
Every approval has a timeout and a default outcome. Defaulting to deny keeps an unattended queue from becoming an implicit allow.
Decision context
Approvers see the tool, arguments, classification of affected data, requesting identities, and the policy that triggered the hold.
Bound to the request
Approval covers exactly the reviewed call, executed once. A modified request is evaluated again.
Fully recorded
Request, approver, decision, time, and any comment are linked to the original audit record.
Common approval policies.
| Action | Typical approver | Typical timeout default |
|---|---|---|
| Destructive SQL on production | DBA on-call group | Deny |
| Payments or vendor master changes | Accounts payable managers | Deny |
| Bulk export of classified data | Owner of the dataset | Deny |
| Sending data to a newly enabled external endpoint | Security | Deny |
| Granting an agent new scope | Agent owner plus security | Deny |
From hold to execution, with no way to replay it.
- 1
Fingerprint
When a policy returns require_approval, an approval record is created for a fingerprint of the exact request, excluding the clock. Retrying the same request while it is pending returns the same approval instead of creating a new one.
- 2
Decide
An eligible approver approves or rejects with an optional note. The user on whose behalf an agent is acting cannot approve their own request.
- 3
Consume
After approval, the identical request is let through exactly once and the approval is marked consumed. A second attempt needs a new approval.
- 4
Resolve the rest
A rejection turns retries into denials. An expired approval follows the policy's on_timeout setting, which defaults to deny.
Approval fatigue is a security problem.
An approver who sees forty requests an hour stops reading them. The value of a human gate depends on it being rare enough to get real attention, which means the rule design matters as much as the mechanism. Thresholds on arguments, such as a payment amount or a row count, keep routine actions automatic and send only the unusual ones for review. Statement classes do the same for databases: bounded reads pass, while DROP and unbounded DELETE wait.
Approval state comes only from the approvals store, never from the client, so an agent cannot claim it was approved. Before enabling a rule, run realistic requests through the simulator to see how often it would trigger, and decide in advance who covers the queue outside business hours. A rule that times out to deny overnight may be exactly right for production schema changes and exactly wrong for a time-sensitive operational task, which may need a different approver group rather than a weaker default.
Questions buyers ask
Where do approvers act on requests?
In the Control console inside your environment, or through its API so you can surface approvals in the tools your teams already use. Approval traffic stays within your deployment.
What does the agent do while it waits?
The call returns an approval-required response with the approval ID, approver groups, and expiry. The agent can continue other permitted work or end the run. Once approved, resubmitting the identical request succeeds exactly once; any change to it is a new request.
Will approvals slow everything down?
Only if they are overused. Reserve them for actions with real consequences and let policy decide routine requests automatically. The simulator shows how often a proposed approval rule would trigger.
Can an approver change the request?
No. Approvers approve or reject what was submitted. If changes are needed, they reject with a reason and the agent or user submits a new request, which is evaluated again.
Can approvals apply to people, not just agents?
Yes. Subjects in a policy can be users, service accounts, or agents, so a bulk export by a person can require the same sign-off as one initiated by an agent.
Can a timeout default to allow?
The policy language supports on_timeout: allow, but we recommend it only for low-impact actions where delay is worse than the risk. For anything destructive or external, deny is the safer default.
Can an approval be reused for similar requests?
No. Each approval is bound to the fingerprint of one request and consumed on first use. Similar requests, or the same request later, need their own approval.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.