AI agent authority: how much power should an agent have?

An AI agent can be capable of doing something without being authorised to do it. That distinction sounds obvious. But it may become one of the most important principles in agent security.

Imagine an agent connected to your business systems. Technically, it can read customer records, change CRM data, send emails, publish content, issue refunds, make purchases and delete files. Those are its capabilities. But which of those actions should it be allowed to perform independently? That's its authority. And the two shouldn't automatically be the same.

What is AI agent authority?

AI agent authority is the level of power an agent has to act independently on behalf of a person or organisation. It answers questions such as: can the agent only retrieve information? Can it recommend an action? Can it prepare the action? Can it change business records? Can it communicate externally? Can it spend money? Can it publish? Can it delete? And, crucially: which of those things can it do without asking first?

Authority is therefore about more than system access. It is about the consequences an organisation is willing to let an agent create autonomously.

Access, capability, permission and authority are different

These terms can easily become mixed together. It helps to separate them.

Term	Question	Example
Access	Where can the agent go?	CRM, email, Google Drive, accounting system
Capability	What is technically possible?	Read email, create email, send email
Permission	Which specific actions does the system allow?	READ allow, DRAFT allow, SEND approval required, DELETE deny
Authority	How independently may it exercise those permissions for the business?	Routine appointment confirmations autonomous; a contractual email requires approval

Authority brings the other controls together.

Why does authority matter?

Because AI agents aren't simply retrieving information. Increasingly, they can create consequences. An agent might change a customer record, send something to a client, place an order, issue a refund, deploy code, publish information, delete data or instruct another agent.

Once an AI system can create consequences outside itself, somebody has made a decision about authority. The problem is that the decision isn't always explicit. Sometimes authority appears simply because a tool was connected, a broad credential was supplied, an API allowed the action, or an employee clicked Allow during setup. "Technically possible" quietly becomes "agent is authorised to do this". Those shouldn't be treated as the same thing.

Authority should be deliberate

Before connecting a powerful tool, ask: do we actually want this agent to have the authority this connection creates? An email integration might technically allow READ, DRAFT, SEND and DELETE, but the agent's job may only require READ and DRAFT. The safest time to make that decision is before the agent starts operating, not after it sends something it shouldn't.

The AI Agent Authority Ladder

We've developed a simple framework at Creative Sauce AI for thinking about agent authority. It has eight levels.

1. READ. Retrieve information: read documents, search approved systems, look up CRM records, check order status, read analytics. Generally the lowest level of operational authority, but READ isn't automatically harmless. Sensitive information still needs protection.
2. RECOMMEND. Analyse information and recommend what should happen: recommend a supplier, suggest a response, flag an invoice, recommend a refund, suggest a code change. A person or another authorised process still decides whether to act.
3. PREPARE. Prepare an action but not complete the consequential step: draft an email, prepare a payment, create a deployment, prepare a social post, complete a refund request, draft a contract amendment. A particularly powerful level, because the agent can do most of the work without necessarily receiving final authority.
4. CHANGE. Alter approved internal systems or records: update CRM fields, change task status, add internal notes, modify approved documents, update inventory. The agent begins directly changing the organisation's state, so monitoring and reversibility matter more.
5. SEND. Communicate externally: send email, message customers, contact suppliers, respond to support enquiries, send notifications. SEND deserves separate consideration because the agent is now representing the organisation to another person. An internal mistake may be correctable quietly. An external message has already left the building.
6. SPEND. Commit financial resources: purchase services, issue refunds, pay invoices, increase advertising spend, order stock, purchase API capacity. Financial authority should usually include explicit limits.
7. PUBLISH. Make information publicly available: publish website content, post to social media, release documentation, update public product information, deploy public-facing changes. Publishing can create reputational, legal, commercial, security or factual consequences, so CREATE and PUBLISH should not automatically be the same permission.
8. DELETE. Permanently remove information or resources: delete customer records, delete files, remove infrastructure, delete database records, close accounts, destroy backups. Deletion sits at the top because it can be difficult or impossible to reverse. Consider soft delete, recovery periods, backups, approval and additional authentication.

Higher does not mean better

The Authority Ladder is not a maturity scale. A Level 8 agent isn't more advanced than a Level 2 agent. In many situations, the best-designed agent will deliberately remain at a lower authority level. A legal research agent may be extremely sophisticated while only having READ and RECOMMEND. A simple automated payment agent might have SPEND. The ladder describes authority, not intelligence.

Authority should match the job

Start with the agent's purpose, then work backwards. Imagine the purpose is: research prospective customers and prepare briefing documents for the sales team. What authority does it actually need? READ web yes, READ selected CRM data yes, RECOMMEND prospects yes, PREPARE briefing yes, CHANGE CRM perhaps limited, SEND email probably not, SPEND no, PUBLISH no, DELETE no.

Now compare that with simply giving the agent access to the sales manager's accounts. Purpose-first design produces much narrower authority.

Authority can be conditional

Authority doesn't have to be ALLOW or DENY. It can depend on conditions: issue refunds up to £50, send email to existing customers, update CRM only in specified fields, publish to staging but not production, contact approved domains, purchase from approved suppliers, access records only for customers assigned to its workflow. This creates something much more useful than a simple permission switch.

Authority can depend on context

The same action can carry very different consequences depending on context. SEND EMAIL to a colleague internally is relatively low consequence; to a customer externally is greater; containing confidential acquisition information is much greater. So authority may need to consider recipient, data, amount, system, environment, time, location, purpose, task and previous approval. Authority is not always just "can send email: yes".

Authority should have ceilings

For higher-risk capabilities, define maximum autonomous authority: maximum payment £100, maximum refund £50, maximum recipients 20, maximum records changed 100, maximum API spend £10 per task, maximum autonomous runtime 30 minutes, maximum external uploads to approved destinations only. Once the ceiling is reached: STOP, or REQUEST APPROVAL. The agent shouldn't decide for itself that the limit is inconvenient.

Authority should expire

Some authority only needs to exist temporarily. If an agent is given access to a financial system to complete a month-end task, it probably doesn't need that access permanently. Authority can be task-based, time-limited, session-based, temporary or automatically revoked after completion. Persistent permissions should not become the default simply because they're convenient.

Authority can accumulate

This is one of the easiest risks to miss. Imagine an agent has READ customer data, SEND external email and UPLOAD files. None of those looks extreme individually. Together, they create the ability to move customer information outside the organisation. Or READ invoices, CREATE supplier, CHANGE bank details, SPEND, which together create substantial financial authority.

So don't review permissions only individually. Ask: what can this agent do when all of its permissions are combined? That is its effective authority.

Delegation creates another kind of authority

Imagine Agent A cannot make payments and Agent B can. Agent A asks Agent B: "pay this invoice for me." Has Agent A effectively gained payment authority? That depends on how Agent B handles the request. If Agent B automatically accepts requests from Agent A, the answer may effectively be yes.

When one agent delegates to another, the receiving agent should evaluate: who requested this, what are they authorised to request, what am I authorised to do for them, does this require approval? Delegation should not become permission borrowing.

An agent should not increase its own authority

Imagine an agent reaches a boundary and decides it needs greater access to finish the task. It should not normally be able to grant itself permission, create a stronger credential, increase its spending limit, disable an approval requirement, connect another system or create a more powerful agent. The appropriate response is REQUEST AUTHORITY, not CREATE AUTHORITY. The agent cannot be both the worker and the person issuing its security pass.

Authority changes should be visible

If an agent's authority changes, record it. For example: agent Finance Assistant, previous authority READ + RECOMMEND, new authority READ + PREPARE PAYMENT, approved by Finance Director, date 2 October, reason invoice automation pilot. That creates accountability and makes periodic review much easier.

Review authority when a new integration or tool is added, the agent's purpose changes, the workflow changes, its model changes significantly, its owner changes, it begins working with another agent, its autonomy increases, an incident occurs, or a previously internal agent begins taking external actions. The agent may have started life as a simple research assistant and six months later be operating half a business process. Its authority should evolve deliberately, not accidentally.

Autonomy and authority are different

Autonomy is how independently the agent can operate. Authority is how consequential the actions it is permitted to take are. You can have high autonomy with low authority (an agent autonomously researches thousands of public documents), low autonomy with high authority (an agent prepares a £100,000 payment but requires human approval before execution), or high autonomy with high authority (an agent independently makes financial or operational decisions and executes them). The last category deserves much stronger controls.

Think about autonomy multiplied by authority

Combination	What it usually means
Low autonomy + low authority	Usually easier to control
High autonomy + low authority	Potentially manageable with monitoring and sensible boundaries
Low autonomy + high authority	Strong approval and authentication become important
High autonomy + high authority	Requires particularly careful security architecture, monitoring, limits and containment

Intelligence should not automatically increase authority

As models become more capable, there may be a temptation to give them more control: the agent is better now, it makes fewer mistakes, so let it send, spend, publish and change production. But improved intelligence doesn't automatically justify increased authority. We don't give a human employee access to every business system simply because they're intelligent. Authority should still depend on role, purpose, risk, controls and accountability. The same should apply to agents.

How should businesses assign agent authority?

A practical process:

1. Define the job. What exactly is the agent supposed to accomplish?
2. Identify required systems. What must it access?
3. Identify required actions. What must it actually do?
4. Use the Authority Ladder. READ, RECOMMEND, PREPARE, CHANGE, SEND, SPEND, PUBLISH, DELETE?
5. Add limits. Amount, volume, recipient, destination, time, data, environment.
6. Add approval boundaries. Where does autonomy stop?
7. Consider combined authority. What becomes possible when all permissions are combined?
8. Consider delegation. Can another agent extend its effective authority?
9. Monitor. Can you see how the authority is being used?
10. Review. Does it still need everything it has?

AI Agent Authority Profile

For every important agent, create a simple authority profile. For example:

Field	Value
Agent	Finance Assistant
Purpose	Validate supplier invoices and prepare approved payments
Owner	Finance Director
READ	Invoices, purchase orders, approved supplier records
RECOMMEND	Payment approval
PREPARE	Payment instruction
CHANGE	Invoice status only
SEND	No
SPEND	Approval required
PUBLISH / DELETE	No
Maximum autonomous financial authority	£0
Approval authority	Finance Manager
Can delegate? / Can change own permissions?	No / No
Review	Quarterly

Now anyone reviewing the agent can understand its authority quickly.

AI Agent Authority checklist

For each agent, ask:

• Is its purpose clearly defined? What is the minimum authority required for that purpose?
• Can it READ sensitive information? CHANGE business records? SEND externally? SPEND money? PUBLISH? DELETE?
• Can PREPARE and EXECUTE be separated?
• Are financial limits defined? Volume limits? Are destinations restricted?
• Are high-consequence actions approved? Does authority expire where appropriate?
• Have combined permissions been reviewed? Can another agent extend its authority? Can it delegate high-authority actions?
• Can it change its own permissions? Are authority changes logged? Is its authority reviewed periodically?

The aim isn't to keep every agent at Level 1. It's to give each agent exactly enough authority to do its job well, and no more than it needs.

Join the Agent Control early-access list

Agent Control is in build. Leave your email and we will let you know when it is ready.

Request early access

The bigger principle

AI agents are becoming more capable. That's the point. We want them to research, analyse, prepare, coordinate, communicate and eventually carry out increasingly complex work. But capability and authority need to grow separately. A model becoming more intelligent doesn't automatically mean it should receive more access. An agent becoming better at completing tasks doesn't automatically mean it should receive permission to create greater consequences.

So before asking "what can this agent do?", ask "what are we willing to let it do without us?" That's the real authority question. Give agents enough freedom to be useful. Put people where consequences begin. Monitor what happens at the edge of their authority. And increase that authority deliberately, not simply because the technology makes it possible.