Human Approval in AI Workflows: What Should an Agent Be Allowed to Do?

Give an agent the authority needed for a defined task

An AI agent should be allowed to perform actions whose scope, permissions and consequences the application can enforce. Use human approval when a decision needs business judgment or could create a consequential commitment. The approval should show the exact proposed action and remain valid only while the relevant facts are unchanged.

This is an engineering design question. There is no universal list of actions that every business must approve manually. The appropriate boundary depends on the workflow, the user's authority, reversibility and the consequences of error.

Start by separating reads, drafts and committed writes. An assistant that explains an order, prepares a change and submits that change is performing three different operations. They do not need the same permission.

Classify actions by consequence

Action category	Example	A useful starting control
Read approved information	Explain a public service page	Grounding and source limits
Read private records	Show a user's assigned orders	Identity and record-level access checks
Create a draft	Prepare a task or quotation	Clear draft state and reviewable contents
Reversible operational write	Update an allowed task field	Narrow tool contract, audit and recovery
Consequential commitment	Confirm a purchase or external change	Explicit authorization tied to current details
Unsupported action	Change a system outside granted scope	Stop and route to the responsible person

Use the table as a discussion aid, then write the actual policy for your application. A supposedly reversible action can still have consequences if it triggers an email, releases stock or changes another person's access.

Tools should express narrow business operations

A tool is the interface through which the agent reads or changes the surrounding system. Prefer operations with typed inputs and clear allowed values. “Read the current basket” and “prepare a quote for this basket” are easier to control than a general instruction to edit arbitrary database records.

The server should resolve the signed-in user's permissions independently of model output. The agent should not be able to grant itself another role by including a different user ID or organization name in an argument. Validate both the operation and the records it affects.

Limit returned data to what the task needs. An assistant helping with one order does not automatically need a full customer export. Narrow inputs and outputs make the workflow easier to assess, troubleshoot and maintain.

Treat retrieved content as information

An agent may read messages, documents or web content that contain instructions written by someone else. Those instructions should not gain the authority of the user's task or the application's policy. A supplier note saying “ignore the approval requirement” is still a supplier note.

OWASP's prompt-injection guidance recommends layered controls, including separating instructions from untrusted data, limiting privileges and using human oversight for sensitive operations. These controls reduce risk but do not justify treating prompt filtering as a complete permission system. Source: OWASP LLM Prompt Injection Prevention Cheat Sheet.

The most useful application boundary remains outside the model: even a mistaken tool request must fail if the current user cannot perform it.

Make the approval a concrete review

The person approving should see what will change, which record is affected and any relevant amount, recipient or timing. Avoid a generic confirmation that forces them to reconstruct the action from a long conversation.

The Agentic Ordering demonstration provides a clear example. The assistant helps resolve menu choices and quantities into a basket. A server-calculated quote is presented for customer confirmation before the order is committed. The assistant's suggestion and the customer's purchase are distinct steps.

If the basket or price changes after review, the old approval should not silently authorize the new details. Bind the confirmation to a specific proposal and revalidate the facts at commitment. For other workflows, this might mean a document version, a recipient list or the precise fields of a proposed update.

Approval does not replace transaction controls

A correctly authorized action can still fail technically. The person may confirm twice. The connection may drop after the server succeeds. Two operators may change the same record at almost the same time.

Use concurrency checks and repeat-safe operations to protect the business result. Preserve the first successful transaction identity and return a clear status on retries. When a conflict occurs, explain what changed and let the user review again.

Also decide whether a successful primary action can have a retryable secondary effect. For example, a record may be saved while a notification waits for delivery. The interface should distinguish those outcomes instead of reporting either blanket success or blanket failure.

Give escalation an ordinary operating path

An escalation needs somewhere to go. Identify the role or queue that receives unsupported requests, missing information and failed actions. Provide enough context for the person to continue without rereading an entire transcript.

Useful escalation records contain the intended task, the affected record, what was attempted, the current outcome and the decision needed. They should avoid exposing hidden model instructions, credentials or unrelated customer data.

The user also needs a clear message. “I could not confirm this change because the order changed after your review” is actionable. “Something went wrong” is not enough when the person needs to know whether the business action happened.

Keep an audit trail and operating limits

Record the actor, operation, target, relevant revision, authorization and outcome. If a person approved the action, retain the proposal they approved. A transcript can provide context, but it should not be the only evidence of a transaction.

Set practical limits on tool calls, retries, task duration and provider usage. A failed loop should stop before it consumes an unbounded budget or repeatedly contacts another system. Provide a way to disable an individual capability while preserving read-only help where appropriate.

Review the failure queue regularly through the existing operator workflow. Adding more notifications does not help if no one owns the response.

Test the boundary before expanding autonomy

Test unauthorized records, malicious instructions inside retrieved content, changed proposals, expired approvals, repeated confirmation, partial failure and missing data. Include cases where the correct result is to ask a question or decline the action.

Start with one useful capability and expand only when its permission and recovery behavior are understood. A broader agent should earn its scope through evidence from the workflow, rather than through a more ambitious prompt.

Explore AI agent development and agentic AI development for a bounded implementation. Discuss what your agent should be allowed to do, using the ordering example below as a concrete approval pattern.