AI agents connected to business tools: where to place human approvals
A human approval is useful when an agentic action changes data, triggers an external effect, widens a permission or leaves the expected scenario. This method helps define control points without turning every step into a bottleneck.
An AI agent connected to business tools should neither decide everything on its own nor ask for approval on every read. Where a human approval belongs depends on the concrete effect of the action: changing data, sending an external communication, using an elevated privilege or crossing a scope boundary. The team must define these points before connecting the agent to the systems concerned, and then be able to explain what was proposed, approved, refused or executed.
In short
- Place a human approval before actions that are hard to undo, external, privileged or unusual for the workflow.
- Have people approve an action described in readable terms: the object concerned, the expected effect, the identity used and the exact scope.
- Approvals do not replace permissions. Each tool must stay limited by applicable rights and rules, even after approval.
This method is a design grid. It does not replace a security, compliance, data protection or business process analysis tailored to the organisation.
Why should a human approval not be a simple "continue" button?
A confirmation without context does not let a person spot a wrong target, an excessive scope or a change of plan. It adds friction without becoming evidence of control.
The risk is clearer when a model can call a tool. OWASP's LLM06:2025 Excessive Agency entry describes the risk of damaging actions caused by unexpected, ambiguous or manipulated outputs. It ties this risk to excessive functionality, permissions or autonomy.
The useful question is therefore not only "do we need a human approval?". It is: "which person must be able to decide on this action, based on what information, and what happens if they refuse?"
To structure this review for a specific operation, use our AI agent autonomy matrix (in French). It helps examine the identity applied, the scope, the reversibility and the available trace before choosing an approval level.
Which actions should go through a control point?
Classify each tool call by its effect, not by the agent's name. A single integration can contain a low-impact read and a write that deserves review.
| Signal to examine | Decision question | Example control to design |
|---|---|---|
| Modification | Does the action create, change or delete business data? | Show the proposed change before execution. |
| External effect | Does the action send a message, trigger a payment or open a case? | Have the recipient, content and expected effect confirmed. |
| Privilege | Does the tool use a broader right than the person who made the request? | Block the path or require explicit authorisation under a documented rule. |
| Scope | Does the action cover more objects, people or systems than the nominal scenario? | Present the scope and request an appropriate approval. |
| Uncertainty | Does the agent propose an action while the data is contradictory or incomplete? | Ask for clarification or stop the workflow. |
This table does not create a universal list of "sensitive" actions. The business owner, the security team and the tool owners must define what counts as an acceptable effect in their context.
How do you word an approval request people can act on?
The approver should review a deterministic proposal, not the model's full reasoning. Prepare an approval object separate from the conversation, with stable fields:
- The requested action: for example create, send, update or cancel.
- The target: the object, system and recipients concerned.
- The expected effect: what will change if the action is executed.
- The scope: number and type of objects concerned, filters applied and exclusions.
- The authorisation context: the user, role or delegation the tool uses.
- The alternatives: do nothing, go back a step or ask for more information.
An approver must be able to refuse without the agent trying to work around that refusal. The refusal becomes an explicit workflow state: action not executed, reason optionally collected, and a return to the user if needed.
Where should the approval sit in the workflow?
The control point must sit just before the real effect. An approval given at the start of a conversation does not necessarily cover a specific action the agent discovers later.
A robust sequence separates five steps:
- the agent interprets the request and prepares a proposal;
- the system checks the available deterministic rules, such as authorisation and scope limits;
- it presents the proposal to the authorised person when a control threshold is reached;
- the tool executes only the approved action, with the intended security context;
- the system keeps a proportionate trace of the proposal, the decision and the result.
Approval must not let the agent silently replace parameters afterwards. If the target, scope, effect or privilege changes, a new decision is required. This matters especially when the agent chains several tool calls or delegates to another component. To define task, data, delegation and stop limits for the whole chain, see our guide on the operational limits of a multi-agent architecture.
How do you keep approvals from becoming a bottleneck?
Treating every action the same way makes control unusable. Conversely, very broad autonomy turns the exception into the rule. The goal is to define categories of decisions, not to automate without limits.
| Decision level | Example situation | Response to define |
|---|---|---|
| Information | The agent prepares a summary from authorised sources. | No action approval, but access control and traceability. |
| Reversible | The agent prepares a draft or a reversible change. | Review according to the business process and rollback capability. |
| Impactful | The agent sends, publishes, changes a reference record or triggers a flow. | Explicit approval before the tool call. |
| Privileged or out of scope | The agent requests a broader right or targets an unexpected object. | Refuse by default or escalate to an authorised person. |
This categorisation must be tested on real cases. Take normal, ambiguous and malicious requests as well as data errors. Check that the agent does not execute an impactful action when approval is missing, does not repeat a refused action and does not confuse a draft with an execution.
Which controls are still needed after an approval?
A human approval does not change access rights or technical rules. It must not be used to let a tool act with a generic identity on data the original user could not access.
OWASP recommends limiting the available extensions, their functionality and their permissions, and requiring approval for high-impact actions. In a system connected to business tools, this means combining four elements:
- a list of tools and operations limited to the use case;
- an identity context and permissions checked by the downstream system;
- a human approval when the effect or scope justifies it;
- traces that let you examine the action without needlessly copying sensitive data.
The access control covered in our guide on the architecture choices to document for a RAG concerns reading data. For an agent that acts, the same discipline must also cover the tool called, the scope of the operation and any human decision.
What evidence should you keep after execution?
The trace must answer an operational question: who proposed which action, on which object, who approved it and what result did the system observe? Avoid turning it into an unlimited copy of conversations or business data.
For each action subject to approval, define with the relevant owners:
- the workflow and proposal identifier;
- the identity or role behind the request and the approval;
- the version of the tool or workflow executed;
- the parameters useful for audit, masking or minimising sensitive data;
- the timestamp of the decision and the result of the call;
- the procedure to follow if execution fails after approval.
This trace also helps evaluate the system. Frequent approvals can reveal a poorly defined scope. Recurring refusals can indicate that the proposal or the rules need revisiting. On its own, the trace does not prove that the system is safe or compliant. Our guide on AI agent traceability details the events to link between proposal, control, approval and result.
What should you decide before connecting an agent to a business tool?
Before making a tool available to an agent, produce a short sheet for each operation:
- the business objective and the authorised user;
- the data read and modified;
- the permissions required and the system that enforces them;
- the scope limits and out-of-scope behaviour;
- the accepted level of autonomy and the approval point;
- the exact content shown to the approver;
- the tests for refusal, error and parameter changes;
- the traces, who can access them and who follows up.
If this sheet cannot be completed, the right next step is usually to restrict the tool to a narrower operation or to keep the action outside the agent's scope. The goal is not to prove that an agent can do everything. It is to make explicit the actions the organisation accepts to have it prepare or execute. This limit belongs in the go/no-go criteria between an LLM prototype and production, with an owner and a review condition.
FAQ
Should an AI agent ask for human approval before every tool call?
No. A read or a preparation with no external effect is not handled like an impactful change. The decision should depend on the effect, scope, permissions and risk of the use case. Access rules remain necessary in every case.
Does a human approval make an agent compliant or secure?
No. It is one control among others. Least privilege, authorisation enforced by downstream systems, scope limits, tests and traceability remain necessary. The applicable requirements depend on the organisation and the context of use.
Who should approve an action proposed by an agent?
The person must have the appropriate business authority and understand the effect of the decision. For sensitive operations, this may involve several roles, for example the business owner, the security team or the owner of the tool concerned.
What if the agent changes the parameters after an approval?
The system must treat the proposal as a different one and require a new decision. An approval must be tied to a specific target, scope and effect, and checked before the tool is called.
Methodology and sources
- OWASP, LLM06:2025 Excessive Agency, consulted on 12 September 2026. The entry describes the risk of damaging actions linked to excessive agency and presents, among other measures, reducing extensions, functionality and permissions, and user approval for high-impact actions.
- OWASP, State of Agentic AI Security and Governance 2.01, published on 1 June 2026, consulted on 12 September 2026. This resource presents the security and governance issues of autonomous AI systems.
The method proposed is a design grid for agentic systems connected to business tools. It contains no client data, no mission statistics and no promise of security, compliance or results. Approval thresholds, retention periods and approver roles must be validated for each organisation.
Do you need to define what an agent may prepare, execute or submit for approval before connecting it to your business tools? Describe your context to IgnitionAI. A first conversation can help frame the scope, the controls and the operational evidence to document.