When a business asks how much freedom an AI agent should have, the talk usually turns to its instructions: what it is told to do, what it is told to avoid, how carefully the wording is tested. That matters. But it is not where autonomy is decided.

An AI agent can only do what its access lets it do. If it can post a journal entry, it can post a wrong one. If it can email a customer, it can email the wrong customer. The instruction says what the agent should do. The permission says what it can do. When the two disagree, the permission wins.

This piece is for the CIO or Head of IT who is about to connect AI agents to the finance, sales and service systems the business runs on.

Why the prompt is the wrong place for limits

An instruction is read by a model, and a model can misread it. It can meet a case its instructions did not foresee. It can be handed a document with text inside that tries to change what it does. None of this needs bad intent. It only needs a long enough run of real work.

A permission is different. The system the agent connects to enforces it, not the agent. If an agent's account cannot approve a payment, no wording in any prompt or document can make it approve one.

So write the instructions carefully. Then design the access as if the instructions will one day fail.

Four levels of access

For each agent, in each system, for each job, decide which of four levels applies.

  1. Read. The agent can look things up, such as a customer record, an order history or a policy. It changes nothing.
  2. Draft. The agent can prepare a change, such as a quote, a reply or an invoice line. A person must open it and release it.
  3. Act with approval. The agent carries the change through once a named person has said yes, and the system records who said it.
  4. Act alone. The agent completes the job by itself, inside limits the system enforces, and every action is logged.

Most jobs should start at read or draft. A job moves up one level only when the record shows the agent doing it well, and a person signs off the move. That is earned autonomy in practice: freedom granted job by job against evidence, not switched on for an agent as a whole. It also works in reverse. When the evidence turns, the job moves back down.

Five signs the access is wrong

  1. The agents share one account. If every agent signs in as the same "integration user", nobody can tell which agent did what. You cannot stop one without stopping all of them.
  2. The account is an administrator. Broad access was granted to get a pilot working quickly and was never narrowed.
  3. The limits exist only in the instructions. Ask what stops the agent doing the thing it was told not to do. If the answer is "it was told not to", there is no limit.
  4. The log shows the connection, not the agent. Your audit trail should name the agent, the job and the person who approved it.
  5. Nobody has reviewed access since go-live. Jobs change. Access granted for one quarter's work stays open into the next.

What good access design looks like

This is the architecture in plain terms, not a build manual.

  • One identity per agent. Each agent has its own account in each system it uses. Its actions are its own, and it can be paused alone.
  • The least access that does the job. Security teams call this "least privilege". An agent that answers order queries needs to read orders, not change prices.
  • Approvals held in the system. The step where a person says yes sits where the work happens, so a change of wording cannot skip it.
  • A record of every action. The record shows which agent, which job, what changed, under which rules, and who approved it. It is also the evidence a job needs before it moves up a level.
  • Access that is reviewed. A named owner checks each agent's access on a set cycle, and again whenever its jobs change.
  • A stop for each agent. A person can switch off one agent's access straight away without touching anything else.

Where this gets harder than it sounds

When a system's roles are too coarse. If a role cannot be narrowed to the job, close the gap outside the system: the agent prepares the change, and a person or a controlled step submits it.

Reading is not harmless. An agent that can read payroll can repeat payroll in a summary sent to the wrong person. Decide what each agent may read as carefully as what it may change.

Approvals can become a rubber stamp. Put approval where the risk is. Let the record carry the low-risk work, and check samples of it.

One account per agent takes effort. Separate identities take longer to set up, and some systems charge per account. Weigh that against not knowing which agent made a change.

Five questions to ask before agents touch your systems

  1. Does each agent have its own identity in each system it uses?
  2. For each job, is the agent at read, draft, act with approval or act alone, and who decided?
  3. Apart from its instructions, what stops an agent doing something it is told not to do?
  4. For any change, can we see which agent made it and who approved it?
  5. How quickly can we switch off one agent, and who is allowed to?

Clear answers tell you whether autonomy has been designed or simply assumed.

Design autonomy where it can be enforced

The instructions tell an AI agent what good work looks like. The access decides how far it can go. Put the limits in your systems, grant freedom one job at a time against evidence, and keep a person deciding what matters.

At Futuvara, we build, implement and run AI platforms where AI agents do defined work under rules your business sets. If you are about to connect AI agents to your business systems and want to talk through who should be allowed to do what, start a conversation.

Start an Agentic conversation →

Sources: