← Blog

Enterprise AI

AI agents need approval limits, not better prompts

July 10, 2026

An AI agent can have a flawless prompt and still be dangerous. The prompt tells it what to try. It does not tell your systems what the agent is allowed to do, whose authority it is borrowing, or when the answer must be "stop and ask a person."

That distinction is becoming concrete. In February, NIST published a concept paper on AI agent identity and authorization. The questions are practical: How does an agent prove its authority? How should a user's authority be delegated? What happens when context changes? How do you bind an agent's action back to a human approval?

None of those questions can be answered with prompt wording. They belong in software controls.

Procurement already has the operating model

Enterprise procurement has spent decades working out how to let people move money without giving every employee the keys to the company. A purchase request has a named requester, a cost center, a category, an approval path, and a record of who changed what. Authority rises and falls with dollar value, risk, and role.

Agents need the same treatment.

I worked inside SAP Ariba and enterprise procurement before building AI intake software. An agent should inherit the controls around the workflow. Mimicking an Ariba screen misses that lesson, and borrowing the unrestricted permissions of an easy-to-configure service account makes the problem worse.

SAP moved this issue closer to production in May. Its new Joule Agents for spend management include purchasing and policy support in SAP Ariba Buying, plus an intake agent that captures and routes requests across SAP and non-SAP systems. Routing sounds harmless until the route changes who can approve a request, which contract is presented, or whether an exception is seen at all.

Give every agent an authority ladder

I would not approve an enterprise agent until its owner can place every tool call on an authority ladder. Five levels cover most first deployments:

1. Read. The agent can retrieve approved records and explain what it found. It cannot alter the source.
2. Draft. It can produce a proposed classification, email, contract summary, or routing decision. A person owns the next action.
3. Queue. It can prepare an exact action and place it in an approval queue. The approver sees the target, parameters, evidence, and expected effect.
4. Act within a limit. It can execute a reversible action inside a narrow policy boundary, such as routing a low-risk intake request to a preapproved queue.
5. Escalate. Financial, destructive, administrative, or externally visible actions require separate human authorization tied to the exact action.

The important boundary sits between queueing and acting. Many demos glide across it because the same API call can do both. Production software should make the boundary explicit.

The OWASP AI Agent Security Cheat Sheet reaches the same conclusion from the security side. It recommends that a separate policy or execution component validate scope, privilege, and approval state before a sensitive action runs. That keeps authorization outside the model's conversation, where prompt injection or a bad inference could otherwise rewrite it.

The audit trail has to explain the action

Traditional application logs tell you that an endpoint returned 200. That is not enough when a model selected the endpoint and assembled its parameters.

For each material agent action, I want the record to include:

• the human user and the non-human agent identity;
• the model and agent version;
• the tool, target, and normalized parameters;
• the source records used as evidence;
• the policy rule that allowed, denied, or escalated the action;
• the exact approval, including its expiry; and
• the result, error, or rollback state.

NIST's May analysis of public comments on agent security found broad agreement that agent risks are already slowing adoption. Deloitte's 2026 enterprise AI survey puts a number on the gap: only one in five surveyed companies had a mature governance model for autonomous agents.

That gap will not close through a longer system prompt. It closes when identity, policy, approval, and evidence become normal parts of the architecture.

A sensible first production pilot

Start with a workflow where the agent can be useful at the first two levels. Procurement intake works well because the agent can read an email or form, extract fields, check for missing information, suggest a supplier match, and draft a route. A person can review all of it before any system record changes.

Build the authority ladder before connecting the write tools. Write tests for the actions the agent must refuse. Put low-confidence cases in an exception queue. Then measure whether reviewers accept the draft, how often the policy layer denies a tool call, and whether the audit record is sufficient to reconstruct the decision.

Give the pilot an acceptance rule before the first model run. A procurement team might require every mandatory field to carry source evidence, every supplier match to remain reviewable, and every write action to show the policy decision that permitted it. The exact thresholds will vary. Writing them first prevents a persuasive demo from quietly becoming the definition of success.

Autonomy can be earned one bounded action at a time. That is slower than a demo and much faster than explaining an untraceable purchase, payment, or production change after it happens.