Human Approval for the First Payment

Most AI agent tool calls should not require human approval.

A research agent searching documents, a monitoring agent checking account balances, or a reporting agent retrieving operational metrics is performing read-only, relatively low-risk work at scale. Requiring someone to approve every call would add delay without providing meaningful control.

An execute_payment call is different.

So are operations such as:

• delete_customer
• modify_access_control
• bulk_export_data

These actions can move money, remove records, change privileges, or expose large volumes of information. The tool may need to remain available, but the agent should not necessarily be able to use it without review.

For higher-risk operations, the first call should pause until a person authorises it.

The Current Model Is Usually Binary

Most teams deploying AI agents are currently given two choices:

1. Make the tool available, allowing the agent to call it whenever policy permits.
2. Remove the tool, preventing the agent from calling it at all.

That binary model works for many tools. It becomes difficult when an operation must remain available but should require a human decision before it proceeds.

Removing execute_payment entirely may prevent the agent from completing the process it was designed to support. Leaving it permanently available may undermine the financial control intended to govern that process.

The missing option is straightforward:

The tool is available, but a person must review and approve the specific request before the agent can proceed.

This is not simply an access-control problem. It is an authorisation problem.

Segregation of Duties in SOX-Controlled Processes

Segregation of duties is a well-established control principle in financial processes, including environments subject to Sarbanes-Oxley requirements.

In a conventional accounts payable workflow, one person may prepare or submit a transaction while another person approves it. The precise implementation will depend on the organisation, its risk assessment, and the controls defined by its advisers and auditors, but the underlying principle is clear: initiation and approval should not rest with the same actor.

AI agent workflows often collapse those stages.

The agent decides that a payment is required and executes it through the same tool call. Unless the surrounding system introduces a separate approval step, there may be no independent authorisation between the decision and the movement of funds.

An approval workflow restores that separation:

1. The agent requests the operation.
2. A human reviews and authorises it.
3. The agent proceeds within the scope of that approval.

There are two actors, two distinct steps, and an auditable decision point.

What the Approval Workflow Looks Like

Within the gateway, a sensitive tool can be configured with:

RequireApproval: true

When an agent calls that tool, the gateway does not immediately forward the request to the underlying service. Instead, it returns a structured denial containing:

DenyReason.PendingApproval

The response also includes a ticket ID.

This distinction matters. The agent can tell that the request has been held for review rather than rejected outright.

A reviewer can then inspect the pending request through a dashboard or API. The review should provide enough context to support a meaningful decision, including:

• The agent making the request
• The tool being called
• The arguments supplied
• The time of the request

The reviewer can approve or deny the request.

When approval is granted, it is time-limited. The default approval window is 60 minutes. During that period, the agent may call the approved tool. Once the window closes, a subsequent call requires a new approval.

The control can also be applied at the policy level. Holding one agent's request does not need to disable the tool for every other agent. An agent whose policy does not require approval can continue to use the same tool normally.

Approval Should Be Time-Boxed

The duration of an approval is one of the most important parts of the design.

A permanent approval is effectively a delayed allow-list entry. It changes the control from:

This operation requires human review.

to:

Someone reviewed this operation once, possibly several months ago.

That is unlikely to provide meaningful oversight for future transactions with different amounts, recipients, records, or consequences.

A time-boxed approval provides a clearer boundary. The agent receives temporary authority to perform the operation. That authority expires. When the agent needs to perform the operation again outside the approved window, it must request fresh authorisation.

This is closer to how controlled human workflows already operate. A finance manager may approve today's payment batch, but that does not automatically authorise tomorrow's batch. Approval applies to a defined context and period, rather than becoming a permanent entitlement.

Depending on the risk, organisations may also need tighter controls than a general time window. For example, approval might ultimately need to be limited to a particular transaction, amount, customer, destination account, or set of arguments. The appropriate scope should follow the organisation's own risk model and control requirements.

Which Tools Should Require Approval?

The list should usually be short.

Applying approval requirements to every tool would create friction, slow down legitimate work, and encourage reviewers to approve requests without proper scrutiny. Human involvement is most useful when it is reserved for operations with material consequences.

Typical examples include:

• execute_payment or submit_transfer, where the operation moves money
• delete_customer or delete_account, where the action is destructive or difficult to reverse
• modify_access_control or update_permissions, where the request changes privileges
• bulk_export_data, where a single call could expose a significant volume of sensitive information
• Tools that trigger external actions with financial, contractual, regulatory, or legal consequences

Most read-only operations should continue without manual intervention. Document searches, status checks, balance lookups, and reporting queries can generally flow under the organisation's normal access and policy controls.

The approval workflow is intended for the smaller group of operations where “the agent decided to do it” is not, by itself, an adequate control narrative.

Access Is Not the Same as Authorisation

Allow-listing answers one question:

Is this agent permitted to use this tool?

It does not necessarily answer another:

Has an authorised person reviewed and approved this specific action?

For low-risk operations, access control may be sufficient. For actions involving money, privileged access, destructive changes, or sensitive data, organisations may need a distinct authorisation step.

That decision should also be recorded in a way that can be reviewed later. A useful audit trail should show what was requested, who reviewed it, what decision they made, and when the resulting authority expired.

If one of your AI agents executed a payment today, could you identify who approved that specific action?

Learn more about the MCP Audit and Compliance Gateway