# How Much Authority Should You Give an AI System?

> When should an AI system prepare a recommendation, and when should it be allowed to execute a real transaction? A practical boundary for authority, approval, and verification.

> 💡 **TL;DR: Key Takeaways**
> - **Recommending the right action does not give a model authority to execute it.** Business rules and access controls must still apply when a proposal becomes a real transaction.
> - **A draft, a preview, and a committed action carry different risks.** Limit the model's authority according to the effect on money, customers, access, or external communication.
> - **Human approval is meaningful only when it can change the decision.** Retries must not duplicate transactions, and success must be verified in the authoritative system rather than inferred from the model's response.

A customer support system recognizes that a customer wants a refund for an order charged twice. It finds the order, calculates the refund, and replies, “Your refund has been issued.”

The sentence may be correct. By itself, however, it does not prove that anything happened.

The model may have understood the request correctly. The order may qualify for a refund, and the amount may be right. The system must still verify that this customer is authorized to make the request, that the refund complies with company policy, and that the payment provider actually processed it.

Recommending the right action and having the authority to carry it out are two different decisions.

## Recommending an action does not grant authority

Language models no longer produce text alone. They can read an order record, draft an email, add a meeting to a calendar, or submit a request to an access management system. The APIs and software functions connected to a model are commonly called tools.

Access to a tool does not make the model an authorized decision-maker.

A sales assistant can draft an email and find the right contact in the CRM. But who the message is sent on behalf of, whether the recipient is correct, and which customer information may leave the company are not decisions the model should make freely.

The distinction is even clearer in employee access. A model can review a new employee's role and suggest the systems they may need. Granting administrator access to the finance system is not the automatic next step. The company's access policy, manager approval, and existing role boundaries must still apply.

That is why OWASP does not define the risk of excessive agency only in terms of model behavior. It recommends [limiting tool functionality, permissions, and autonomy separately](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/){.dofollow target="_blank" rel="noopener"}.

## A draft, a preview, and a committed transaction carry different risk

A procurement system can compare supplier quotes and prepare a draft purchase order. The draft may include the budget code, quantity, and delivery terms. At that point, the company has made no commitment to the supplier.

The next step may be a preview. The system shows which budget will be charged and which record will change if the transaction proceeds. The authorized employee can see exactly what they are about to approve.

Once the purchase order is committed in the ERP and sent to the supplier, the action has consequences outside the system. The same model may help at all three stages. It does not need the same freedom at each one.

This distinction is not an argument for putting every action behind a heavy approval chain. Drafting an internal note is not as risky as issuing a refund. Sending a customer email is not the same as filing an official application on behalf of the company. Authority should narrow as the real-world consequences grow.

## Enforce authorization where the action occurs

Companies do not necessarily need a separate “AI authorization system.” If the existing application already determines which customer records a user may see, how large a refund they may issue, or which budget they may spend from, those controls can remain in place.

What matters is that the control runs when the model's proposal becomes a real transaction. Writing “perform only authorized actions” in a prompt is not a substitute for enforcement.

## Human approval works only when it can change the decision

An approval button in front of a risky transaction can look reassuring. It is not much of a control if the reviewer sees only the model's short summary, must clear hundreds of requests quickly, or lacks the authority to stop the action.

In the refund example, the support representative should at least see the customer, order, amount, reason for the refund, and the policy condition that was met. They should be able to change the amount, reject the transaction, or escalate it. And they need to do that before the money moves, not afterward.

OpenAI's [safety guidance for computer-using models](https://developers.openai.com/api/docs/guides/tools-computer-use){.dofollow target="_blank" rel="noopener"} similarly recommends asking for confirmation at the point when a consequential action becomes clear. A user who states a broad goal has not necessarily approved every recipient, file, or transaction encountered later.

Requiring approval for every action is not a good default either. Low-impact, observable work can proceed automatically under explicit rules. Spread human attention across every minor step and the approvals that truly matter can become routine clicks too.

## The same request should not create the action twice

The connection may drop just after a refund request reaches the payment provider. If the support system assumes the attempt failed and sends the same request again, the customer could receive two refunds.

AI did not create this problem. Payment, ordering, and reservation systems have dealt with the same uncertainty for years. The answer is not to tell the model to be careful. The system should attach a transaction identifier to the business intent, recognize a repeated request as the same operation, and verify the result against the payment record.

AWS's engineering guidance on [making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/){.dofollow target="_blank" rel="noopener"} recommends carrying that intent through an explicit identifier so a retry does not create an additional result. Having a model prepare the refund request does not change this transaction rule.

Not every action can be reversed. Incorrect access can be revoked. A mistaken reservation can sometimes be cancelled. An email already sent to a customer or an official filing already submitted may be corrected later, but neither can be made unsent. Whenever a system claims an action can be rolled back, it should be clear about what can actually be undone.

## A successful tool call is not a completed outcome

The model may choose the right tool, fill in every field correctly, and receive a success response. The system should still verify the outcome at its authoritative source.

For a refund, that may mean checking the payment provider's transaction ID and the current order record. For an email, it may be the delivery log; for access, the role recorded in the identity system; for a purchase order, its committed status in the ERP.

In the [article on when enterprise AI needs RAG](/when-does-enterprise-ai-need-rag){target="_blank" rel="noopener"}, I separated the question of where reliable information should come from. The same principle applies to actions: verify the change where the authoritative record lives, not in the system's own description of what it did.

The central question is not whether you trust the model. It is where the model may propose an action, where company policy must intervene, whose authority makes the transaction possible, and where the result will be verified.

A model can have broad room to reason while operating with narrow transactional authority. That is not a contradiction. It is what allows the system to act reliably inside a business.

[The previous article examines the difference between workflows and agents when a system must choose the next step rather than merely produce an answer](/when-do-you-actually-need-an-ai-agent).

You can find the other decisions about models, information, authority, and evaluation in the [guide to designing an AI system for your business](/designing-ai-systems-for-business).

---

Language: English
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/how-much-authority-should-ai-have