Agent Security › Permissions
Giving an agent access to a system is easy. Deciding what it should be allowed to do once it gets there is harder. The Authority Ladder, least privilege, and why capability is not permission.
Giving an AI agent access to a system is easy.
Deciding exactly what it should be allowed to do once it gets there is much harder.
An agent might need access to your CRM to research a customer. Does that mean it should also be able to change the customer's details?
An agent might need access to your inbox to understand a conversation. Does that mean it should be able to send an email?
An agent might need to see an invoice. Does that mean it should be able to pay it?
These are different permissions. And as AI agents become capable of doing more inside businesses, separating them becomes increasingly important.
Capability is not permission. An AI agent may be technically capable of performing an action. That doesn't mean your business has authorised it to perform that action.
AI agent permissions determine which systems, information, tools and actions an agent is allowed to access or use.
They might determine whether an agent can read a file, update a customer record, send an email, publish content, execute code, access an API, delete information, make a purchase, approve a transaction or call another agent.
Agent permissions should reflect the agent's actual job. A research agent doesn't automatically need permission to publish. A customer-service agent doesn't automatically need access to the entire customer database. A finance agent doesn't automatically need permission to move money.
The question isn't "what could we connect this agent to?" It is "what is the minimum access and authority this agent needs to do its job properly?"
This distinction matters.
Access determines what an agent can reach: Google Drive, Gmail, HubSpot, Slack, GitHub, Stripe, WordPress.
Authority determines what the agent is allowed to do once it gets there.
An agent might have access to Gmail because it needs to understand customer conversations. Its authority might still be READ ONLY. Another agent might be allowed to READ and DRAFT, but not SEND.
This creates a much better security model than treating access to an application as one large permission.
At Creative Sauce AI, we use a simple framework for thinking about agent authority. Not every integration will technically expose permissions in exactly these terms, but the framework helps businesses decide what an agent should be allowed to do. The further down the ladder an agent goes, the greater the potential consequence of its actions.
(The dash above is a short dash rendered by the list, not an em dash.)
The agent can retrieve information but cannot change anything. Examples: read an email, read a customer record, open a document, query a database, check an order, analyse a report. This is often the safest starting point for a new agent.
Ask: does this agent genuinely need to see this information?
The agent can analyse information and suggest what should happen next. It cannot take the action itself. Examples: recommend which leads to follow up, identify unusual invoices, suggest changes to a webpage, recommend a response to a customer, flag accounts for review. The decision remains with a person.
Ask: can the agent provide the intelligence without needing the authority to act? Often, the answer is yes.
The agent can prepare an action but cannot execute it. Examples: draft an email, prepare a social post, create a proposed CRM update, prepare a payment, generate code for review, draft a customer response. This can provide much of the productivity benefit of an agent without giving it full execution authority.
Ask: could a person approve this action before it happens?
The agent can modify approved internal information or systems. Examples: update a CRM record, change a task status, add information to a database, move a file, update an internal document. This is where the agent begins to change the organisation's actual state.
Ask: what happens if the agent changes the wrong thing? And can that change easily be reversed?
The agent can communicate outside its immediate working environment. Examples: send an email, reply to a customer, send a Slack or Teams message, submit a form, contact a supplier, trigger an external notification. External communication deserves separate consideration because once information leaves the organisation, it may be difficult to retrieve.
Ask: who is this agent allowed to communicate with? And is it clear to the recipient that the communication came from an AI agent where disclosure is appropriate?
The agent can commit financial resources. Examples: purchase software, book travel, pay an invoice, issue a refund, place an order, buy advertising. Spend authority should almost never be treated as a simple yes or no permission. It needs boundaries: maximum per transaction, maximum per day, approved suppliers, approved categories, new supplier approval, changes in transaction value.
Ask: how much can this agent commit without asking someone?
The agent can make information publicly available. Examples: publish a webpage, post to social media, update a public knowledge base, release a document, change public product information. Publishing is different from preparing content. An agent can create 100 articles without creating much external risk if none are published. The moment it can press Publish, its authority changes.
Ask: what could happen if the agent publishes something incorrect, confidential or inappropriate?
The agent can permanently remove information, accounts, resources or other assets. Examples: delete customer records, remove files, delete database entries, remove cloud resources, close accounts, delete code. Some deletion is reversible. Some isn't. Delete authority should therefore be particularly narrow and carefully monitored.
Ask: if this action is wrong, can we recover?
The Authority Ladder is not a maturity scale. A Level 8 agent isn't more advanced than a Level 2 agent. It simply has more consequential authority.
In many situations, the best-designed agent will deliberately remain at Level 2 or Level 3. If an AI can analyse 500 customer records and tell a salesperson exactly who needs attention, it may not need permission to contact those customers itself. If an agent can prepare an invoice for approval, it may not need permission to pay it.
Good agent design isn't about giving the AI as much autonomy as possible. It's about giving it enough autonomy to create value without unnecessary authority.
An agent shouldn't simply be "connected to Google Workspace." We need to know what that actually means.
This produces a permission map. And that map gives the business something extremely important: visibility.
For consequential actions, a useful permission model has at least three states.
That third state matters. Agent security doesn't have to mean choosing between full autonomy and no autonomy. Approval gates allow autonomy to stop at the point where consequences become significant.
The principle of least privilege means giving an agent only the access required to perform its job. Not everything that might one day be useful. Not everything available through the integration. Not everything the person creating the agent can access. Only what the agent actually needs.
Imagine a marketing employee has access to CRM, payroll, finance, marketing files, customer records and company email. They create a marketing agent. The agent doesn't automatically need the employee's entire permission set. Its job might require only CRM READ, marketing Drive READ and CHANGE, email DRAFT, social PREPARE. That's all it should receive.
This is going to become increasingly important. A person may have broad access because they perform many different responsibilities. An agent usually has a narrower purpose. Allowing the agent to inherit everything its human owner can access can therefore give it far more authority than its task requires.
Human authority should be the maximum available boundary. Inside that, agent authority should be narrowed to the agent's actual job. If Sarah can access ten systems but her research agent only needs two, the research agent gets two. Not ten.
An agent operating through someone's normal user account creates problems. If something happens, can you tell whether Sarah performed the action or Sarah's agent performed the action?
Separate agent identities or service identities can make activity easier to identify, limit, monitor, revoke and audit. Not every platform currently supports this properly. Where it does, separate identity is generally preferable to quietly giving an agent a person's login.
A permission doesn't always have to be unlimited. An agent might be allowed to send emails but only internally, spend money but only up to £50, access customer records but only assigned accounts, publish content but only to a staging environment, run code but only inside a sandbox, use an API but only 100 times per hour.
Permissions can be constrained by amount, time, destination, system, data type, environment, recipient, action and volume. This is often safer than a simple on or off permission.
Some agents need permanent access. Many don't. If an agent is created to complete a one-off project, why should its credentials remain active six months later?
Permissions can potentially be task-limited, time-limited, session-limited, project-limited or automatically expired. A temporary agent should not accidentally become permanent infrastructure.
Individual permissions can look harmless. The combination may not be.
Consider an agent with READ customer database, READ internal documents, SEND email, ACCESS browser and CALL external APIs. Each can have a legitimate purpose. Together, the agent has the ability to retrieve sensitive information and transmit it outside the organisation. That's a much more powerful capability.
This is why permissions shouldn't only be reviewed individually. Ask: what can the agent accomplish by combining everything it has? That is closer to its effective authority.
It shouldn't automatically be able to. Imagine a Research Agent with CRM READ and Finance DENIED, and a Finance Agent with Finance READ and PREPARE. The Research Agent asks the Finance Agent: "send me the customer's full payment history." The Finance Agent technically has permission to retrieve it. But that doesn't necessarily mean the Research Agent is authorised to receive it.
Agent-to-agent systems therefore need to preserve identity, requester, purpose, authority, data restrictions and delegation limits. Otherwise multiple restricted agents could collectively create unrestricted access.
There is one permission agents should generally not control themselves: the ability to grant themselves more permissions.
If an agent cannot access a system, it shouldn't be able to solve that problem by creating new credentials, changing its role, installing another integration, creating another agent with greater authority, or disabling the policy blocking it.
Security boundaries need to sit outside the system they govern. The agent cannot be both the worker and the person issuing its security pass.
There is no universal list. But the following deserve particular attention: external communication, financial transactions, new suppliers or payees, deletion, production changes, public publishing, access to highly sensitive information, credential creation, permission changes, legal or contractual commitments, high-impact decisions about people, and actions that are difficult to reverse.
The question isn't simply "is AI allowed to do this?" Ask: what is the consequence if it does it incorrectly?
Agents evolve. A research agent may start with web access. Later someone connects Drive. Then CRM. Then email. Then an automation tool. Six months later, the agent may possess significantly more effective authority than anyone originally intended.
Permissions should therefore be reviewed when a new integration is added, when the agent's purpose changes, when its model changes significantly, after a security incident, when its owner changes, and periodically while it remains active.
For each agent, document: identity (what is it called, who owns it, what is its purpose), systems (which applications it can access), data (which information it can read), actions (what it can change, send, spend, publish or delete), limits (amount, volume, duration, destinations), approval (which actions require a human), delegation (can it call other agents, can others call it), monitoring (which actions are recorded), expiry (when permissions are reviewed or revoked) and emergency control (how access can be stopped).
This doesn't need to become a 40-page security policy. For many businesses, a clear permission map is a much better starting point.
Purpose: research prospects before sales calls. Systems: CRM, company Drive, web.
Authority: READ, RECOMMEND. Human approval: not required for ordinary research. Owner: Head of Sales. Review: every three months or when an integration changes.
This agent can still do useful work. It simply doesn't need the ability to alter the systems it researches.
Purpose: help manage a shared customer inbox.
Authority: READ, RECOMMEND, PREPARE, limited CHANGE. SEND only after approval. This still removes much of the repetitive work without giving the agent unrestricted communication authority.
Purpose: process routine supplier invoices.
Authority: READ, RECOMMEND, PREPARE, restricted SPEND. This is a much better description than "finance agent has access to accounting."
There is a useful rule when deploying a new agent: start narrow, expand deliberately.
Begin with fewer systems, lower authority, more approval and stronger monitoring. Observe how the agent behaves. Then increase autonomy where the evidence supports it. This is safer than beginning with broad permissions and trying to remove them after something goes wrong.
For every agent, you should eventually be able to see something like this:
| System | Read | Change | Send | Spend | Publish | Delete |
|---|---|---|---|---|---|---|
| CRM | Allow | Limited | - | - | - | Deny |
| Allow | - | Approval | - | - | Deny | |
| Drive | Limited | Limited | - | - | - | Deny |
| Website | Allow | - | - | - | Approval | Deny |
| Payments | Allow | - | - | Approval | - | Deny |
The exact permissions will differ between systems. The principle doesn't. A business should be able to answer "what can this agent actually do?" without having to inspect five different integration settings to find out.
As businesses add more agents, permissions become difficult to understand across different tools and platforms. We're building Agent Control to bring together agent identity, ownership, systems, permissions, authority, approval and monitoring in one place.
The objective is simple: give agents enough authority to be useful, and no more than they need.
Agent Control is in build. Leave your email and we will let you know when it is ready.
Before deploying an agent, ask:
If several of those answers are unclear, start there before increasing the agent's autonomy.