AI agent permissions in a company: a decision sheet — what it reads, what it changes, who approves and how to switch it off

Author: Published:

An AI agent permissions sheet: one row per system — read, write, approval, a separate account, keys and the off switch. Three examples and a CSV file.

With AI agents — programs that use AI and carry out tasks in company systems on their own — the most practical question is not about the model but about the CRM, the system for managing customer relationships: “so what will it be able to do in there?” In a company with a security department, the answer is set by a procedure. In a company of twenty or a hundred people with one IT person or an outsourced IT provider, someone simply has to write it down — and ideally on one sheet that both the owner and the vendor understand.

This article is that sheet. One row is one system the agent has access to: the CRM, a mailbox, the ERP (the system for orders, stock and finance), the calendar, a document drive. The columns organise the questions that have to be settled before go-live: which account the agent works on, where its access key is kept, who switches it off and what happens to a task interrupted midway. Below you will find three filled rows, example failures the account, key and off-switch columns prevent, questions for a vendor whose product “needs full access”, and what to carry from the sheet into the technical annex of the contract.

Download the sheet (CSV) — it opens in Excel, Google Sheets and LibreOffice, with three filled examples and empty rows for your own systems. If the data appears in one column, import the file as UTF-8 with a comma (,) as the delimiter.

The sheet at a glance: one row per system, twelve columns

Column The question it answers
System Which system does the agent get access to?
What the agent reads Which data does it use — and which does it not?
What the agent changes What may it write, and in what form (draft, note, work-in-progress record)?
What it never does on its own Which actions have significant consequences and always wait for a person?
Who approves Which role approves, and who deputises?
Agent account Which account does the agent act on in this system?
Access key Where is its password or key kept, and who can reach it?
Key replacement When does the key change, and who does it?
Off switch Who stops the agent, how, and how long did it take in the test?
Task in progress What happens to work interrupted midway?
Record of actions Where can you see what the agent did?
Review When did someone last check this row and test the off switch?

The columns on reading, writing and actions that need a person, together with the record of actions, are the basics we have already described on the AI agent implementation page: read scope as narrow as the task allows, write scope narrower still, a person’s approval for actions that cannot be undone, and a record of actions that lets you reconstruct a decision. How to design the human approval step itself (human in the loop) so that it does not turn into rubber-stamping is set out in a separate article. Here there is just one rule, with no exceptions: in the first version of the agents we build, actions with significant consequences — sending to a customer, a payment, a price change, a booking, a commitment, but also a status change that sets something else in motion in the company — are approved by a person, even if they could technically be undone. So the “never does on its own” column must be filled in for every system.

The rest of the article is about the columns that are easiest to forget: the account, the key and the off switch.

Why “full access so everything works” is a costly setting

The simplest way to get an agent working straight away is to give it an administrator account, or the login of someone who can reach everything. Then nothing blocks the tests and everything looks fine — until the first mistake. OWASP, the international organisation that works on application security, describes this risk as excessive agency and names three sources: the agent has more functions than it needs, more permissions than it needs, and more autonomy than it should (OWASP, LLM06:2025).

OWASP illustrates the mechanism with an example. An assistant is meant to summarise incoming mail, but the tool it reads the mailbox through can also send. Someone sends a message with hidden instructions for the model — such a prompt injection is text the agent reads as an instruction even though it came from outside. The agent searches the mailbox and forwards confidential messages to the sender. OWASP names three safeguards: a tool that can only read mail, access with a read-only permission, and manual approval of every outgoing message. Each of them is one cell of the sheet.

So full access is not a setting; it is the absence of a decision. It widens the possible reach of every mistake, and the cost of that decision is deferred until the day the agent makes a mistake on data it should never have been able to reach.

Identity: an agent never works on the owner’s login

The first of these columns is the account. The rule is simple: the agent gets a separate account in each system, with a role covering only its task. Never the password of the owner, the CEO or anyone else. A shared login carries three risks:

  • Change history. When the agent works on your login, every change it makes in the CRM and the ERP looks like yours. After a mistake, nobody can tell what a person did and what the automation did.
  • Cutting access. A separate agent account can be blocked without blocking a person. On a shared login, cutting the agent off means cutting you off, and changing your password — after a holiday, say — can stop the agent without warning.
  • Reach of the damage. An agent on the owner’s account has the owner’s permissions, including those its task does not need. Every mistake then has the reach of the whole account.

In its list of the most serious risks for AI agents (Top 10 for Agentic Applications), OWASP lists abuse of the agent’s identity and privileges as a separate item — which is why this column gets its own section.

Sometimes an action has to be done on behalf of a specific person — a draft in their mailbox, for example. Then instead of a password you use delegated access: the person grants the agent a narrow, described permission (for example, drafts only) that can be withdrawn without changing their password. In such a case OWASP recommends acting in the user’s context but with minimum privileges — which is not the same as handing over a password or a full session. What such access covers, how it shows in the change history and how to withdraw it — that must be checked in the specific system before you write it into the sheet.

If your company already uses Microsoft 365, and therefore Microsoft Entra, it is worth knowing that Microsoft offers separate identities for agents (Microsoft Entra Agent ID), and extending Entra security features to them requires Microsoft Agent 365 (Microsoft Learn, as of 12 October 2026).

A typical scenario (an illustration, not a specific client’s story). An automation that creates tasks and moves sales opportunities between stages in the CRM runs on the owner’s login because “that was quickest”. The owner changes the password, the automation stops, and nobody connects the two facts for several days. When someone finally looks into who moved a dozen or so sales opportunities to a different stage, the change history shows one person — the owner.

Access keys and replacing them — in plain words

The agent connects to a system through an API, the interface through which programs exchange data without clicking through screens. For the system to let it in, the agent presents an access key — an API key, a token (a digital proof of access) or a service account’s password. The technical term is a secret, but it is best thought of as a door key: whoever holds it gets in, regardless of who they are.

That comparison gives five rules you can write into the sheet:

  1. One key per system and per agent. Then revoking one key does not stop everything.
  2. The key’s scope is checked separately and limited to the task. A key need not have the same permissions as the account it belongs to — it may be narrower, but it may also be wider (for example, a token an administrator generated for the whole company). A key with administrator rights opens every door at once.
  3. The key lives in a safe, meaning a password manager or the key vault of the automation tool. Not in an e-mail, a spreadsheet, a chat or the text of the model’s instructions.
  4. You know who can reach it. At least two named people can replace the key and cut access — one is too few for a holiday. Only those who need the key’s value can see it, through their own accounts in the safe rather than through a forwarded copy.
  5. The key gets replaced: whenever someone who knew it leaves, whenever a leak is suspected, and on a fixed schedule you agree at implementation. Where the system allows it, the key gets an expiry date.

The last rule has a practical test: replace the key in a test environment (a separate installation without real data) and check that the agent keeps working after a change in one place. If replacing it means a day of hunting for where else it was pasted, regular upkeep becomes hard — and that is better known before go-live than after an incident.

A typical scenario (an illustration, not a specific client’s story). The person who set up an integration a year ago generated a key with administrator rights “to avoid problems” and pasted it in several places. Then they left the company. Nobody knows where the key is used, so nobody replaces it — because replacing it might break something. The administrator key outlives the employment of the person who knew it.

The off switch and revoking access

The off switch is the column that is easiest to fill in and hardest to test. A well-designed one has two levels:

  • Stopping — pausing the automation the agent runs in. Quick, but it depends on the automation tool working and listening.
  • Cutting off — blocking the agent’s account and revoking its keys and active sessions (ongoing log-ins) on the target system’s side: the CRM, the mail system, the ERP. It works even when the automation has hung. It does depend, though, on how the system treats tokens already issued and sessions already open, which is why the procedure is set for each integration separately. If the system cannot withdraw existing access straight away, you write down that limitation and the tested procedure instead of a promise of instant cut-off.

Cutting off works independently of the model for the same reason OWASP recommends that the target system checks on every operation what the agent may do, rather than relying on the model’s decision: access is decided by the system, not by the agent.

Three things go into the sheet. Who — at least two people on your side, not only the vendor. How — a concrete action, not “contact the vendor”. How long it took — the time measured in the test until the system actually rejects the agent’s further operations, not the time declared in the proposal.

A separate question is the task in progress. An agent switched off mid-task may have saved a note only partly or created three of five order lines. That is why, where the system allows it, we write in full or not at all, and in a multi-step task the agent records which steps it completed. After an interruption, a person checks the result and decides on resuming so that entries are not duplicated. The off switch is tested before go-live and after every larger change, and the date goes into the last column.

The AI Act, the EU regulation on artificial intelligence, requires for high-risk systems that the person overseeing the system can interrupt it — through a “stop” button or a similar procedure — and bring it to a halt in a safe state (Article 14(4)(e)). The provision applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems — what already applies today is collected on our AI Act page. An off switch is worth having whether or not the provision covers you.

A typical scenario (an illustration, not a specific client’s story). An agent that sorts support tickets starts setting the wrong status on them in bulk. The only person with access to the automation account is on holiday, and the vendor answers the next working day. Nobody in the company knows that blocking the agent’s account in the ticketing system would be enough — because nobody wrote down that such an account exists.

Three filled rows: CRM, shared mailbox and ERP

The same three examples are in the CSV file. They illustrate typical tasks and are not a ready-made configuration — you will adapt role names and scopes to your systems, and enter times and dates only after your own test.

Column CRM Shared mailbox ERP
What the agent reads Company and contact records and contact history in the pipeline the task concerns; no export of the whole database Only the shared mailbox (e.g. orders@); no personal mailboxes Stock levels, order statuses, business-partner records without bank details
What the agent changes Adds a note and a task for a salesperson Creates reply drafts and applies labels Creates a sales order as a draft awaiting approval
What it never does on its own Does not delete or merge records; does not change the contact owner or a stage that triggers a quote or contract Does not send, delete, forward outside the company or create forwarding rules Does not approve documents, issue invoices, or change prices, discounts, credit limits or a business partner’s bank account number
Who approves Sales manager; deputy: a named salesperson Customer-service person on duty; deputy: customer-service manager Someone from order processing; deputy: head of the department
Agent account Separate user with a role limited to notes and tasks Separate integration (an application identity tied to the shared mailbox, not anyone’s password) with access to that mailbox only, drafts without sending Separate operator with a role for draft orders
Access key Password manager or the key vault in the automation tool; two named people have access through their own accounts in the vault As for the CRM As for the CRM
Key replacement When someone leaves, on suspicion of a leak, and on the agreed schedule As for the CRM As for the CRM
Off switch Stop the automation; the CRM administrator blocks the agent’s user and revokes its keys and active sessions Stop the automation; the mail administrator removes access and revokes the key and active sessions Stop the automation; the ERP administrator blocks the agent’s operator and revokes its keys and active sessions
Task in progress Review notes and tasks since the last check Review drafts and label changes since the last check; nothing went out without a person Drafts go to review before approval
Record of actions Automation log and CRM change history under the agent’s user Automation log and the mailbox access log Automation log and the ERP change log under the agent’s operator
Review To be completed after the off-switch test; do not go live without it As for the CRM As for the CRM

Two notes. For mail, the counterpart of a separate account is usually a separate integration, an application identity tied to the shared mailbox — still not the owner’s password. Not every mail system lets you grant drafting without the right to send, and a drafting permission often allows deleting messages too. If your system offers nothing narrower, sending, deleting and creating forwarding rules must be blocked by code or a separate intermediary program that works independently of the model — an instruction to the model is not a control — and before go-live you test that attempts to send, delete, forward and create a forwarding rule are rejected. If that cannot be ensured, the agent prepares drafts outside the mailbox or stays read-only. Not every ERP has a role limited to drafts; then the agent writes to an intermediate table — a place for records awaiting import — and a person approves the import into the ERP. In both cases the row shows the weaker spot instead of hiding it.

When a product “needs full access”: questions for the vendor

If an off-the-shelf agent product asks for broad permissions at connection time, the decision about permissions was made for you by someone who does not know your data. Before you click “allow”, ask the vendor these questions:

  • Exactly which actions does the agent perform in our system, and which permission does each one need?
  • Can the agent work on a separate account with a limited role rather than an administrator account?
  • Can it be connected read-only, and only to a separated set of pilot data?
  • Which actions can the agent take without a person’s approval, and can that be switched off?
  • Where is the access key to our system stored, who on your side can reach it, and how do we replace it?
  • How do we withdraw the agent’s access on our side, without your involvement, and what happens to tasks in progress when we do?
  • Which of the agent’s actions are recorded, where and for how long — and do we have access to those records?

If there is no answer to the first question, or the product works only on an administrator account, check two routes: running it in an isolated test environment on sample data, with no connection to real systems, or connecting it read-only and only to a separated set of pilot data (for example, one mailbox or one sales pipeline), if the product supports that. Read-only on its own is not enough: the product can still read every record within its permitted scope, so that scope must be restricted too. If neither is possible, do not connect it to a system holding real data. If the agent is to use your system’s functions through the MCP standard (Model Context Protocol, a common way of connecting tools to AI assistants), the same questions apply to every tool it exposes — we describe this on the page about connecting an AI assistant to your system.

What from the sheet goes into the contract’s technical annex

The sheet is a working document, but its rows have natural counterparts in what is worth having in writing with the vendor. We do not give contract wording here — that is work for a lawyer. We give questions whose answers are worth agreeing with the vendor or a lawyer, and the column of the sheet they come from:

Sheet column What to agree in writing
What it reads and changes Is the scope table for each system part of the annex, does widening it need written consent, and what happens to an action outside the agreed scope?
What it never does on its own, who approves Is the list of actions that need approval closed, and who on the client’s side approves changes to that list?
Agent account Does the agent work only on accounts created and controlled by the client?
Access key, key replacement Who stores the keys, who can reach them, and by when are they replaced at the end of the engagement or after an incident?
Off switch, task in progress Can the client cut access on its own, how does the vendor document the procedure, how often do you test it together, and who checks unfinished tasks after an interruption and agrees to resuming?
Record of actions Which actions are recorded, how long are the records kept, and who can access them?

Some of these topics relate to obligations under the GDPR, the General Data Protection Regulation — the data processing agreement (Article 28) and appropriate security measures (Article 32) in the regulation. Whether and how to write a given point into the contract is for your lawyer to decide; we implement the controls that the client and its lawyer assign to us. How to settle roles around personal data is described in the article on GDPR in an LLM implementation and on the security and GDPR page, and the other questions to ask before signing are in the article on what an AI implementation costs.

What next

Pick one system the agent would have access to and fill in one row for it. If the account, the key or the off switch stays empty, those are exactly the things to settle before the first line of code. In our implementation methodology we ask the client for an IT contact for access; we suggest that this person fills in these columns with us, while the process owner writes down who approves.

Sources and status as of 12 October 2026

Frequently asked questions

Can an AI agent work on my account?

No. Do not give the agent your password or your full session. On a shared login, the change history cannot tell what the agent did from what you did. Cutting the agent off means locking yourself out, and changing your password can stop its work without warning. The agent also gets all of your permissions, including ones its task does not need, so every mistake it makes has the reach of your account. The agent gets a separate account in each system, with a role that fits its task. If an action has to be done in your name, narrow delegated access is used — and what it covers, how it shows in the change history and how to withdraw it must be checked in the system concerned.

What permissions should an AI agent get at the start?

The narrowest that still let the task be done: read only the data the task concerns, and write only drafts, notes or work-in-progress records. Anything with significant consequences — sending, payment, a price change, a booking, a commitment to a customer, but also a change that sets something else in motion in your systems — happens only after a person approves it. That is how we build the first version of every agent, even when the change could technically be undone.

What is an AI agent’s service account?

It is a separate user in a system — in the CRM or the ERP, for example — created only for the agent, with a role covering only what its task requires. It has its own name, so the change history shows what the agent did, and an administrator can block that account without touching anyone else’s. If the system licenses per user, that is one more licence, which is worth putting into the implementation estimate.

How quickly can an AI agent be switched off?

As quickly as the test showed, not as quickly as the proposal promises. The off switch has two levels: stopping the automation the agent runs in, and cutting access on the target system’s side — blocking the agent’s account and revoking its keys and active sessions (ongoing log-ins). The second level also works when the automation does not respond — provided the system rejects keys and sessions already issued straight away, which the test shows. The test measures the moment the system actually rejects the agent’s further operations, not the moment someone clicks. In your company, at least two people should be able to do both.

What should I do when a vendor says its agent needs full access?

Ask what exactly for, and request a list of the actions the agent performs in your system, with the permission each one needs. If the vendor cannot give that list, or the product only works on an administrator account, check whether it can run in an isolated test environment on sample data, or be connected read-only and only to a separated set of pilot data (for example, one mailbox or one sales pipeline). Read-only on its own is not enough, because the product can still read every record within its permitted scope — so that scope must be restricted too. If neither is possible, do not connect it to a system holding real data. Full access is the absence of a decision about permissions, not a setting of them.