Which AI actions need human approval

Imagine an AI system preparing a correct commercial proposal and sending it to the wrong recipient. Or finding the right supplier but using bank details from the latest email without verification. The generated text may be excellent. The failure occurs when an answer becomes an action on the company's behalf.

Agent security therefore starts with authority: what may the system read, prepare, change and execute? Human approval is useful when it relates to a concrete consequence and provides enough information for a decision. Here is how to establish that control without endless “Are you sure?” dialogs.

These actions have different consequences. Suggesting that overdue invoices should be reviewed does not itself change business records. A draft can be corrected. A message already sent to a customer affects the relationship, while changes to banking details or access rights can have greater consequences.

Describe each digital role through four levels: reading permitted data, preparing an output, changing internal records, and taking external or critical actions. Moving to the next level requires a separate permission decision. Access to a document does not imply permission to disclose it.

OWASP identifies excessive functionality, permissions and autonomy as drivers of Excessive Agency risk. A practical implication is to provide tools for the agreed workflow, rather than universal access for possible future tasks. OWASP · LLM06:2025 Excessive Agency ↗

The initial list depends on company policy and the workflow. A useful starting point covers money, commitments, confidentiality and consequences that are difficult to reverse.

• Payments, refunds, bank-detail changes and financial limits.
• Sending contracts, proposals and correspondence that creates expectations.
• Changing prices, discounts, payment terms, quantities or other material conditions.
• Deleting working data, making bulk changes and modifying backups.
• Granting permissions, sharing documents externally and enabling new cloud services.
• Hiring, dismissal, sanctions and other consequential employment decisions.

This is an architectural starting point, not a universal legal classification. Applicable obligations and signing procedures depend on the relevant rules and company documents. AI can prepare the evidence while an authorised person assesses the consequences.

Some tightly bounded operations may eventually be automated. Such permission should specify eligible outcomes, recipients, limits, duration and exceptions. “Do whatever we normally do” leaves too much undefined.

A card asking “Send proposal?” is inadequate when the recipient, attachment and total are hidden. The reviewer needs the significant parameters and access to the underlying material.

For a proposal, show the recipient, subject, final text, attachment version, amount and departures from standard terms. For a record change, show the object and before-and-after values. For access, show the person, document scope, permission level and duration.

OWASP's transaction authorisation guidance links significant data visible to the user with the authorised operation. Applying that principle to agents means approval should cover a specific result version, with authorisation enforced by the execution system. OWASP · Transaction Authorization Cheat Sheet ↗

If the recipient, amount or file changes after approval, the old decision should not silently authorise the new operation. Present an updated request so the person is not held responsible for an action they never reviewed.

Authentication establishes identity and interface access. It does not imply agreement with everything an agent might later do. A manager can open a report without instructing the system to send documents.

Likewise, a positive sentence in a long conversation can be ambiguous. “Yes, continue” may refer to analysis rather than a payment. Significant actions need an unambiguous connection between the request, its parameters and the authorised user's decision.

Choose the approval mechanism according to risk and system capabilities. A clear control in a protected interface may suit one operation; another may require the company's separate authorisation process. The mechanism should prevent impersonation, silent expansion and reuse for a different operation.

In this illustrative scenario, an invoice arrives with an urgent request to pay using new bank details. AI extracts the amount, matches the order and notices that the account differs from the supplier record.

A useful output is a review package: the original email, invoice, related order, changed details and unresolved facts. The incoming email must not itself grant authority to overwrite the supplier record or issue payment.

A responsible employee verifies the change through the company's independent process. Only then can it follow the required approval route. The agent assembles evidence and highlights differences; urgency in an incoming message does not create authority.

The same principle applies to requests for customer databases, access for new recipients or bypassing a contract review. Information sources can contain instructions without becoming instructions from the system owner.

“Never send anything without asking” is useful behavioural guidance. The sending tool also needs a real restriction. Universal tool access leaves room for an interpretation error to defeat the prompt author's intent.

Separate draft creation, approval requests and execution of approved results. Before changing an external system, the executor checks permissions and approval state. An agent should not be able to grant itself authority or rewrite its own approval policy.

External documents can contain instructions intended to redirect a model, a form of prompt injection described by OWASP. Treat email and PDF contents as data, while keeping authority rules separate. OWASP · Prompt Injection Prevention ↗

A local model can still read a malicious attachment. Computing location and permission to act are different controls.

An integration may send a command and lose the response. If the original action succeeded, blindly retrying can produce a duplicate message, record or operation. Distinguish failure from an outcome that is temporarily unknown.

Where the integration supports it, use unique operation identifiers and checks for prior execution. Query the target system before retrying uncertain actions. A single approval checkbox does not provide this protection automatically.

Source conditions can also change after approval: stock levels, contract versions or order status. Recheck material preconditions before execution and stop on a mismatch. Approval should not become indefinite permission to ignore new circumstances.

Clear states help: prepared, awaiting decision, rejected, approved, executing, completed, failed or requiring investigation. Employees need to know what actually happened, rather than infer it from the model's last confident statement.

Asking permission to open every already-authorised document trains people to ignore dialogs. Approving a hundred unrelated operations with one click can make review equally superficial. Preserve attention for consequential decisions.

Routine reading within access rights and draft preparation can usually proceed without a question at every step. Group externally consequential operations only when the reviewer can inspect the complete batch, common conditions and exceptions. Hidden items should not inherit blanket approval.

Measure review time, rejection rates and reasons for correction. If one field repeatedly needs repair, improve the source or rule rather than pressure reviewers to click faster. A useful review card shows differences and supporting evidence without requiring the entire chat to be reread.

Allow refusal, revision requests and cancellation where execution still permits it. Once an external action has happened, cancellation may be impossible; the interface should make that boundary clear.

Investigating an outcome requires the initiator, time, object, significant parameters, prepared-material version, approval decision and target-system response. Links to sources and exception reasons also help.

The audit trail should not become an uncontrolled copy of every company secret. Restrict access, retention and sensitive contents. Proving that a user approved a document version does not always require its full text in every technical log.

Logs support investigation but do not guarantee a correct decision. Reviewers can make mistakes and sources can be incomplete. Controls also need sound data, explicit responsibility and a workable failure investigation process.

AI Office has a software prototype with assignments, approvals and an audit trail using demonstration data. Real integrations and authority rules are validated within each project; the prototype does not establish complete protection for every customer operation.

Map one workflow: what the agent reads, prepares and executes, who approves, and how completion is verified. Include refusal, changed data and a network failure. This pilot reveals much more than one successfully approved message.

Useful business AI accelerates preparation and makes consequences easier to understand. Its authority to act should remain within boundaries the company has deliberately set and tested.