AI Agent Permissions: What Should an AI Agent Be Allowed to Access and Do?
AI agents become useful when they can do more than generate an answer.
They can potentially:
access systems;
retrieve information;
update records;
send communications;
create documents;
schedule activity;
initiate transactions;
trigger workflows;
interact with other applications;
coordinate with other agents.
That ability to act is what makes agents potentially transformative.
It is also what makes permissions one of the most important decisions organisations need to make about agentic AI.
Because the question is no longer simply:
What can the AI generate?
It becomes:
What is the organisation prepared to allow the AI to access, decide and do?
An AI agent may technically be capable of performing an action.
That does not mean it should automatically have permission to perform it.
As organisations move from AI assistants towards agents, they therefore need a deliberate model for assigning digital authority.
What are AI agent permissions?
AI agent permissions define the information, systems, tools, decisions and actions an AI agent is authorised to access or perform.
Permissions might determine whether an agent can:
read customer records;
search internal documents;
access employee information;
update CRM fields;
send emails;
approve requests;
issue refunds;
create orders;
delete information;
trigger workflows;
use another AI agent.
Permissions therefore define the operational boundaries within which the agent can act.
For more on how agents differ from conventional AI assistants, read AI Assistants vs AI Agents: What Business Leaders Need to Know Before Giving AI Autonomy.
Capability and permission are not the same thing
This distinction is fundamental.
Capability asks:
What can the technology do?
Permission asks:
What are we allowing it to do?
Imagine an AI agent is technically capable of:
reading every customer record;
sending external emails;
updating contracts;
issuing refunds.
The organisation might deliberately permit it to:
read only relevant customer records;
draft emails but not send them;
recommend contract changes but not execute them;
issue refunds only below £25.
The technology has not become less capable.
The organisation has simply defined its authority.
This gives us one of the core principles we've been developing across the Agents cluster:
AI capability determines what a system can do. AI authority determines what the organisation allows it to do.
Why permissions matter more as AI becomes autonomous
With an AI assistant, a human often acts as the permission layer.
AI drafts an email.
The human decides whether to send it.
AI recommends an action.
The human decides whether to execute it.
AI produces analysis.
The human decides what happens next.
As autonomy increases, some of those human checkpoints disappear.
The agent itself may be permitted to act.
That means the organisation needs to transfer some of the control previously provided by humans into:
permissions;
limits;
monitoring;
escalation.
For more on deciding when greater autonomy is justified, read How Much Autonomy Should You Give an AI Agent? A Practical Framework for Business Leaders.
The principle of least AI authority
Cybersecurity has long used the principle of least privilege:
users and systems should receive only the access they need.
AI agents need a similar principle.
I would express it as:
Give an AI agent the minimum authority required to create the intended business outcome.
Not:
the maximum authority the technology can support.
Not:
every permission that makes implementation easier.
The minimum authority required.
This becomes the Principle of Least AI Authority.
It should apply across:
data;
systems;
tools;
decisions;
actions;
financial limits;
communications;
delegation.
The Stratify AI Permission Stack
I would structure AI agent permissions across seven layers:
IDENTITY → DATA → TOOLS → DECISIONS → ACTIONS → TRANSACTIONS → DELEGATION
Each layer represents a different form of authority.
1. IDENTITY — Who or what is the agent?
Before granting permissions, the organisation needs to know what it is granting them to.
Every material agent should have an identifiable:
name;
purpose;
owner;
environment;
technical identity.
It should not operate as an invisible extension of somebody else's account.
Leadership should be able to ask:
Which agent performed this action?
Who owns it?
Which permissions did it have?
This creates the foundation for auditability.
Agents should not inherit human permissions automatically
This is an important design principle.
Suppose an employee can access:
customer records;
financial data;
contracts;
internal documents;
email.
An AI agent supporting that employee may not need access to all of those things.
Simply allowing the agent to inherit the employee's entire permission set can create unnecessary exposure.
Instead ask:
Which specific information does this agent need to perform this specific objective?
The answer may be much narrower.
2. DATA — What information can the agent access?
Data access determines what the agent can know.
Potential categories include:
public information;
internal knowledge;
customer data;
employee information;
financial information;
contracts;
commercially sensitive information;
special-category data;
credentials.
For each category ask:
Does the agent need it?
Can access be restricted?
Can sensitive fields be masked?
Can access be temporary?
Can the agent retain information?
Can information leave organisational boundaries?
Greater data access can increase capability.
It can also increase consequence.
For more on assessing data alongside other AI risks, read AI Risk Classification: How to Classify AI Use Cases by Risk.
3. TOOLS — Which systems can the agent use?
An agent's authority is shaped not only by the data it can see but by the systems it can interact with.
For example:
CRM;
ERP;
email;
HR systems;
finance systems;
customer-service platforms;
document repositories;
payment systems;
workflow tools.
Access to a system does not need to mean full access.
An agent might have:
READ ONLY
in one system;
CREATE
in another;
UPDATE SPECIFIC FIELDS
in another;
and
NO DELETE AUTHORITY
anywhere.
Permissions should therefore be granular where practical.
The Permission Gradient
A useful way to think about tool authority is:
VIEW → CREATE → UPDATE → COMMUNICATE → EXECUTE → DELETE
Each step generally creates greater operational consequence.
VIEW
Read information.
CREATE
Generate a new record or object.
UPDATE
Change existing information.
COMMUNICATE
Send information outside the immediate workflow.
EXECUTE
Perform a business action.
DELETE
Remove information or records.
This is not a universal risk ranking.
Context matters.
But it gives leadership a practical way to ask:
How far along this gradient does the agent actually need to go?
4. DECISIONS — What can the agent decide?
This is different from system access.
An agent may have enough technical access to make a decision while organisational policy requires a human to make it.
For example:
The agent can analyse a refund request.
But can it decide whether the customer receives the refund?
It can analyse job applicants.
But can it decide who progresses?
It can assess a contract.
But can it decide whether the organisation accepts the terms?
Decision authority should be explicit.
For more on separating ownership from authority, read AI Decision Rights: Who Should Be Allowed to Approve, Override or Stop AI?
5. ACTIONS — What can the agent actually do?
Now define operational actions.
For example:
draft;
send;
schedule;
approve;
reject;
update;
escalate;
purchase;
refund;
cancel;
delete.
The organisation should document:
which actions are permitted;
under what conditions;
within which systems;
subject to which limits.
This is where permissions become tangible.
Permission should be conditional
An agent does not necessarily need a binary:
CAN / CANNOT
permission.
Authority can be conditional.
For example:
Customer refund
Below £25
Agent can execute.
£25–£250
Agent prepares; employee approves.
Above £250
Manager approval.
Or:
External communication
Approved routine template
Agent can send.
Material deviation
Human approval.
Complaint/legal threat
Mandatory escalation.
This creates bounded authority rather than unrestricted access.
6. TRANSACTIONS — What economic authority does the agent have?
This deserves explicit attention.
Agents may increasingly be able to:
purchase;
refund;
renew;
cancel;
commit expenditure;
adjust pricing;
create financial records.
Leadership needs financial boundaries.
Examples:
maximum transaction value;
daily transaction limit;
approved suppliers;
per-customer thresholds;
prohibited transaction categories;
dual approval above defined levels.
We can think of this as the agent's financial authority budget.
This is directly analogous to the authority organisations already assign to employees.
AI should not automatically receive unlimited financial authority simply because a system integration makes it possible.
7. DELEGATION — Can the agent trigger other agents?
This is an emerging issue.
An agent may not complete the entire task itself.
It may:
call another agent;
trigger another automated process;
invoke an external service;
delegate a sub-task.
Now leadership needs to understand not only:
What can Agent A do?
but:
What can Agent A cause something else to do?
This creates a delegation chain.
For example:
Human
↓
Agent A
↓
Agent B
↓
Payment system
The effective authority of Agent A may therefore be greater than its direct permissions suggest.
This gives us another important principle:
Agent authority includes both direct actions and actions it can cause through delegation.
The Stratify Agent Permission Matrix
For every material agent, I would document:
Permission area | Allowed | Conditions |
Data access | Yes/No | Which data? |
System access | Yes/No | Which systems? |
Create records | Yes/No | Which records? |
Update records | Yes/No | Which fields? |
External communication | Yes/No | Which channels? |
Decision authority | Yes/No | Which decisions? |
Financial transaction | Yes/No | What limit? |
Delete authority | Yes/No | What can be deleted? |
Agent delegation | Yes/No | Which agents/tools? |
Human escalation | Required | Under what conditions? |
This is far more useful than simply saying:
Agent approved.
Approval should define what the approval actually permits.
Permissions should connect to risk classification
The same permission can create different risk depending on the context.
An agent updating:
an internal meeting note
is different from updating:
an employee disciplinary record.
An agent sending:
an internal reminder
is different from sending:
a regulated customer communication.
Permissions therefore need to sit alongside:
impact;
data;
decision significance;
reversibility;
scale.
For more on applying proportionate controls, read AI Governance Checklist: 15 Questions Every Leadership Team Should Ask.
Permissions should connect to human oversight
An agent may be allowed to prepare an action without being allowed to execute it independently.
This is where permissions and human oversight intersect.
For example:
AI prepares → human approves
or:
AI executes within threshold → human reviews exceptions
or:
AI operates → human monitors performance
For more on designing meaningful human intervention, read Human Oversight in AI: When Does AI Need a Human in the Loop?
Who should approve agent permissions?
Not every permission should require executive approval.
The appropriate authority depends on the permission.
For example:
DATA ACCESS
Data owner / Privacy / Security may need involvement.
SYSTEM ACCESS
Technology / system owner.
BUSINESS DECISION
Business owner.
FINANCIAL AUTHORITY
Business/Finance authority.
HIGH-RISK AUTONOMY
Potential governance/executive approval.
The important point is:
Technical administrators should implement permissions. They should not necessarily determine the business authority those permissions represent.
That distinction should be explicit.
Permissions should have an expiry mechanism
Access granted to humans is often reviewed periodically.
Agent permissions should be too.
An agent may have needed access for:
a pilot;
a temporary process;
a specific workflow.
Months later, that access may no longer be necessary.
Every material permission should therefore have:
an owner;
purpose;
approval;
review date;
where appropriate, an expiry date.
This prevents permission accumulation.
The AI Permission Lifecycle
Permissions should move through a lifecycle:
REQUEST → ASSESS → APPROVE → GRANT → MONITOR → REVIEW → REDUCE / RENEW / REVOKE
This creates another reusable Stratify control model.
REQUEST
What authority is required and why?
ASSESS
What risk does it create?
APPROVE
Who has authority to grant it?
GRANT
Implement the permission.
MONITOR
Observe how it is used.
REVIEW
Is it still required and appropriate?
REDUCE / RENEW / REVOKE
Change authority based on evidence.
Permissions should be observable
Leadership should be able to understand:
which agents exist;
what systems they access;
what data they can see;
what actions they can take;
what financial authority they have;
what other agents they can trigger;
when permissions last changed.
This is particularly important for higher-autonomy agents.
Otherwise the organisation can gradually accumulate a network of software actors with significant operational authority but limited executive visibility.
Permission changes should trigger governance review
Suppose an agent initially:
reads customer records.
Later it can:
update customer records.
Later:
send communications.
Later:
issue refunds.
The agent may have the same name.
But it is no longer the same governance proposition.
Its authority has materially changed.
Permission increases should therefore potentially trigger:
risk reassessment;
human oversight review;
accountability review;
testing;
approval.
The same principle applies when the agent gains:
new data;
new tools;
new delegation capability;
greater transaction limits.
The Agent Authority Review
A recurring review should ask:
PURPOSE
Does the agent still need to exist?
DATA
Does it need all current access?
TOOLS
Does it need every connected system?
DECISIONS
Are decision rights still appropriate?
ACTIONS
Does it need all current actions?
TRANSACTIONS
Are financial limits appropriate?
DELEGATION
Can it trigger other systems or agents?
MONITORING
Are we observing how authority is used?
EVIDENCE
Does performance justify retaining the permission?
DECISION
Maintain / Increase / Reduce / Revoke?
This could become a standard governance control for material agents.
The relationship between permissions and accountability
Every material agent should have someone accountable for the authority it receives.
The organisation should be able to trace:
BUSINESS OWNER
↓
APPROVED PURPOSE
↓
AGENT IDENTITY
↓
PERMISSIONS
↓
ACTIONS
↓
MONITORING
↓
ESCALATION
If an agent performs an action, leadership should be able to determine:
why it was allowed;
who authorised the permission;
what boundary applied;
what evidence exists.
For more on structuring that wider accountability chain, read The AI Accountability Gap: 7 Signs Nobody Really Owns AI.
The Fractional CAIO Agent Permission Review
As organisations deploy more agents, permission governance could become a recurring executive-management activity.
A Fractional CAIO might help leadership maintain visibility of:
material agents;
owners;
risk classification;
authority level;
permissions;
exceptions;
incidents;
permission changes;
review dates.
The role does not manually administer technical access.
It ensures the organisational authority represented by that access is understood and governed.
Ten questions before granting an AI agent permission
Before granting a material permission, ask:
What business outcome requires this permission?
Does the agent genuinely need it?
What data does the permission expose?
What system does it affect?
What decision authority does it create?
What action could the agent take?
What is the consequence if it is wrong?
Can the action be reversed?
Who approved the authority?
How and when will the permission be reviewed?
If leadership cannot answer these questions, the agent may be receiving authority faster than the organisation can govern it.
AI agent permissions are business decisions
Permissions can look technical.
Checkboxes.
API scopes.
Access roles.
System credentials.
But underneath each permission is an organisational decision.
Can AI see this?
Can AI change this?
Can AI decide this?
Can AI send this?
Can AI spend this?
Can AI trigger this?
Those are not merely technology questions.
They are questions of organisational authority.
As AI agents become more capable, one of the most important governance disciplines will therefore be ensuring that:
AI receives enough authority to create value — but never more authority than the organisation has deliberately decided to give it.
Frequently Asked Questions About AI
Agent Permissions
What are AI agent permissions?
AI agent permissions define which data, systems, tools, decisions and actions an AI agent is authorised to access or perform.
What is the principle of least AI authority?
The principle of least AI authority means giving an AI agent only the minimum access and decision/action authority required to achieve its intended business objective.
Should AI agents use employee permissions?
Not automatically. An employee may have broader access than an agent needs. Agent permissions should be assigned according to the agent's specific purpose.
What systems can AI agents access?
Technically, agents may connect to many enterprise systems. Organisationally, access should be limited to systems required for the approved use case and governed according to risk.
Should AI agents be allowed to make financial transactions?
Potentially, where the use case, evidence and risk justify it. Financial authority should have explicit limits, monitoring and escalation requirements.
Can AI agents send emails without human approval?
They can technically do so, but whether they should depends on the purpose, consequence, reliability and controls. Organisations may permit routine communications while requiring human approval for more consequential cases.
How often should AI agent permissions be reviewed?
Permissions should be reviewed periodically and whenever the agent's purpose, data, systems, autonomy, scale or risk changes materially.
Who should approve AI agent permissions?
Approval should reflect the authority being
How Ready Is Your Organisation for AI Agents?
AI agents introduce new governance questions around access, permissions, authority, human oversight and accountability.
Stratify helps leadership teams assess whether the organisational foundations required for more autonomous AI are in place.
Test Your AI Readiness
Because the important question isn't simply:
What can the agent do?
It is:
What have we deliberately authorised it to do?
Comments