AI agent permissions checklist

AI agent permissions determine what an agent can see, which tools it can use and what it can change on your behalf. For a small business, those permissions can be the difference between a useful assistant that prepares a draft and an over-powered system that can read an entire mailbox, publish content or alter customer records.

The aim is not to remove every capability. It is to give the agent enough access to complete one defined job, while limiting what can happen if it makes a mistake, follows a malicious instruction or somebody compromises the account.

This checklist helps an owner or marketing team turn that principle into a practical permission plan before connecting an AI agent to live systems.

Start with the job, not the connection screen

Permission requests often appear as a technical list: read files, manage contacts, send email, edit records. Do not approve that list until the business job is clear.

Write one sentence describing the intended work:

Prepare a weekly campaign report from approved analytics exports and save a draft in the reporting folder for the marketing manager to review.

That job needs access to particular reports and one destination folder. It does not need every file in the company drive, permission to send email or authority to change campaign settings.

Create a simple job-to-permission map with six fields:

Job: the exact task the agent is allowed to complete.
Inputs: the specific information it needs to read.
Tools: the accounts, applications or integrations it needs to use.
Outputs: where it may create or update work.
Actions: what it may do automatically and what needs approval.
Owner: the person who approves access, monitors use and can stop it.

If you cannot complete the map, the workflow is not ready for a live connection. Use our AI pilot guide to narrow the task and test it with lower-risk information first.

Use the least AI agent permissions that work

The National Cyber Security Centre describes least privilege as giving users and systems access only to the resources they need for their job. Its current guidance on adopting agentic AI applies that principle directly: never give an agent unrestricted access to sensitive data or critical systems, and do not deploy it if you cannot understand, monitor or contain its actions.

Apply least privilege across four separate areas.

1. Data

Limit the folders, mailboxes, tables, records and date ranges the agent can read. A reporting agent may need campaign results, but not payroll documents or every customer conversation.

Where the platform allows it, place approved source material in a dedicated folder or workspace. This is easier to understand and review than relying on a long list of exceptions across a shared drive.

2. Tools

Connect only the applications required for the job. A content-preparation agent may need a brand guide and a draft folder. It does not automatically need the website, CRM, email platform and social accounts.

Treat browser extensions, plug-ins and connected applications as access decisions too. A convenient integration may be able to read the page, document or account open in the user’s session.

3. Actions

Separate reading from creating, editing, sending, publishing and deleting. Many systems group these permissions broadly, so check what each scope really allows rather than trusting a friendly label.

If the supplier cannot limit an integration to the required action, decide whether the broader access is acceptable and how it will be monitored. If not, use a safer route such as an export, a separate workspace or a human hand-off.

4. Time

Access does not need to last forever. Set an end date for trials and temporary projects. Revoke permissions when the pilot finishes, an owner leaves, the job changes or the integration is no longer used.

The NCSC’s guidance for using SaaS securely recommends reviewing permissions, removing unnecessary access and monitoring privileged activity. Those established controls still matter when the identity using the service is automated rather than human.

Put actions on a four-level permission ladder

A useful way to design AI agent permissions is to classify actions by consequence.

Level 1: read

The agent can retrieve approved information but cannot alter it. Examples include reading a published service sheet, viewing a campaign export or searching an approved knowledge base.

Read access is not automatically low risk. A system that can search all customer records or confidential contracts may expose valuable information even if it cannot change anything. Limit the source and test what the agent can retrieve.

Level 2: prepare

The agent can create a new draft, summary or recommendation in a controlled location. Existing source material remains unchanged.

This is a sensible starting level for many marketing jobs. The output should be clearly marked as a draft and routed to a named reviewer.

Level 3: change

The agent can update an existing record, page, task or campaign. Add validation and an approval point before the change where practical. Keep version history or another reliable way to reverse the action.

For example, an agent might prepare proposed changes to a product description, but a person approves the final update. If automated changes are justified, restrict them to named fields and agreed conditions.

Level 4: commit

The agent can take an external, financial, destructive or difficult-to-reverse action. This includes sending a customer message, publishing content, placing an order, changing access, deleting data or approving a payment.

Keep these actions behind explicit human approval unless a careful assessment supports a tightly bounded exception. Do not let the same agent prepare a high-impact action, approve it and hide the evidence needed to review it.

Our human-in-the-loop workflow guide explains how to define approval gates without sending every routine task to the business owner.

Give the agent its own identity where possible

Do not connect an agent through a shared owner account if the service supports a separate user, service identity or scoped integration. A distinct identity makes it easier to:

assign only the permissions required for the workflow;
see which actions came from the agent;
rotate or revoke its credentials without disrupting a person;
separate administration from normal operation;
review the agent alongside other users and applications.

Protect the human administrator account with multi-factor authentication and do not place passwords or long-lived access tokens inside prompts, shared documents or ordinary instructions. Use the platform’s supported secret or connection management where available.

Record the identity, connection and credential owner in your AI tool register. Never copy secrets themselves into the register. Note where they are controlled, who may rotate them and what must be revoked when the workflow is retired.

Make approval technically meaningful

“A person checks it” is not a control if the action happens before the check or the reviewer cannot see what will change.

For an approval gate to be useful, the reviewer should receive:

the proposed action and its destination;
the source information used;
important assumptions, warnings or missing fields;
a clear approve, reject or edit choice;
enough time and authority to stop the action.

Use separate permissions where possible: the agent prepares the work, while a named person or controlled publishing process commits it. For higher-impact actions, consider whether two people should be involved or whether a second system control is appropriate.

Avoid vague approvals such as “allow this agent to act whenever it is confident”. Confidence is not the same as correctness, authority or business acceptance.

Log what the agent reads and does

You need enough evidence to answer four questions after an error: which identity acted, what it accessed, what action it attempted and whether the action succeeded.

Enable the available activity and connection logs. Check that they cover important events such as:

successful and failed sign-ins;
new or changed integrations;
records read, created, changed or deleted;
messages sent or content published;
approval decisions and the person who made them;
changes to permissions, instructions or workflow settings;
blocked actions and unusual volumes of activity.

The NCSC recommends retaining activity logs that can support investigation and protecting them from alteration. The ICO’s AI information security and integrity guidance also expects access to AI systems and personal information to be restricted, reviewed and monitored where relevant.

Logging everything without looking at it is not enough. Decide which events need an alert, who reviews them and what should stop the workflow. A burst of sending, repeated failed access, an attempt to reach an unapproved folder or a permission change outside the normal process should not wait for the next six-month review.

Test failure, revocation and recovery

Before normal use, test more than the happy path. Ask what happens when the agent receives incomplete information, an instruction hidden inside a document, a request outside its job or an unavailable integration.

Confirm that it fails safely:

it cannot reach information outside the approved boundary;
it cannot perform a higher-level action through another connected tool;
a rejected approval does not quietly retry or choose another route;
the owner can pause the workflow and revoke its access;
draft or changed work can be identified and recovered;
the team has a manual way to complete essential work.

Run the stop procedure during the pilot. A control that nobody can find under pressure is not ready. Record the person authorised to stop the agent, the accounts or tokens to disable, the logs to preserve and the process for checking what happened.

Use this 12-point AI agent permissions checklist

Before connecting an agent to live business systems, confirm:

The agent has one clearly defined job and one accountable owner.
Every requested connection is necessary for that job.
Read access is limited to named sources, folders, records or fields.
Write access is limited to the correct destination and output type.
Sending, publishing, deleting, financial and access changes need explicit approval.
The agent uses a separate, identifiable account or service identity where possible.
Administrator access is separate from routine operation and protected with MFA.
Credentials are stored and rotated through supported secure controls.
Important access, actions, approvals and permission changes are logged.
The owner has tested pause, revocation, recovery and the manual fallback.
The permission plan has a review date and event-based review triggers.
Retirement includes removing users, integrations, tokens and unnecessary retained data.

Add the completed permission map to the workflow’s decision record. Review it whenever the job, data, model, supplier, connection, owner or action changes. Permission granted for a reporting draft does not automatically cover customer outreach or publishing later.

An AI agent system build should make these boundaries part of the design, not a security tidy-up after the workflow is live. Start with the smallest useful access, prove the job works and widen one dimension at a time only when the evidence supports it.

Frequently asked questions

What permissions should an AI agent have?

Only the permissions required for one defined job. List the exact data it needs to read, the tools it needs to use, the place it may create or change work and the actions that require approval. Avoid entire-mailbox, whole-drive or administrator access when a folder, export, limited role or separate workspace will do.

Is read-only access safe for an AI agent?

Read-only access reduces the risk of unwanted changes, but it can still expose confidential or personal information. Limit what the agent can search, test whether it can retrieve restricted material and monitor unusual access. The sensitivity and volume of the data matter as much as the ability to edit it.

Should an AI agent be allowed to send emails or publish content?

Treat sending and publishing as higher-impact actions because they affect people outside the workflow and may be hard to reverse. A safer early design lets the agent prepare a draft and a named person approve the final action. Automate only after bounded testing, clear rules, reliable logs and a proportionate risk decision.

How often should AI agent permissions be reviewed?

Set a regular review based on the workflow’s impact, then review immediately when the task, data, connection, supplier, owner or action changes. Also review after an incident or unexpected result. Trials should have an end date so temporary permissions do not quietly become permanent access.

Planning an agent that needs access to real business systems? Book an AI marketing audit to map the job, connections, permission boundaries and approval points before you build.

Sources checked on 2 October 2026: NCSC guidance on adopting agentic AI, NCSC guidance for using SaaS securely, NCSC Cyber Essentials resources and the ICO AI information security and integrity guidance. This is practical business guidance, not legal or cyber-security advice.