When a company builds its first AI agent, the quickest way to get it working is to give it broad access. It uses the manager's mailbox, the shared drive, an administrator login for the order system. The pilot works, everyone is pleased, and the access stays exactly as it was. Months later nobody remembers what the agent can reach.
This article is for the owner or manager of a small or mid-sized company who wants to correct that, whether before launch or after. It is deliberately practical and needs no security team. For the technical design of agent identities and delegated authority in larger setups, see AI agent identity and authorization. For handing access over when the team changes, see the handover runbook.
Why "just give it access" goes wrong
The principle of least privilege is old: a person or system should have only the access needed for its task. It matters more for agents because an agent can be misled. A customer email, a web page or a document can contain text that tries to steer the agent into doing something else, and OWASP lists "excessive agency", meaning too much functionality, permission or autonomy, among the main risks of language-model applications (OWASP: Excessive Agency). If the agent can only read one folder, a successful trick leaks little. If it holds an administrator login, the same trick can delete records or send messages in the company's name.
Mistakes are the other reason. An agent that misreads an instruction does the wrong thing at full speed. Narrow access limits how far a mistake can travel.
1. Start with a one-page access list
Before changing anything, write down what the agent touches today. A simple table is enough, with one row per system:
- System: mailbox, CRM, shared drive, order system, website admin, payment tool.
- What the agent does there: for example "reads open orders to answer status questions".
- What it can actually do: often much more than the line above.
- Who owns the system: the person who can change or remove the access.
The gap between the third and second column is your to-do list. Do not skip systems that feel harmless; a shared drive often holds contracts and price lists nobody meant the agent to see.
2. Decide read and write separately
For each row, ask two questions. Does the agent need to read? Does it need to write?
Most agents that answer questions, summarise or prepare drafts need reading only, and not all of it. Narrow the reading to what the task requires: one mailbox folder rather than the whole mailbox, one product-document folder rather than the whole drive, orders from the last 90 days rather than the whole customer history.
Where writing is needed, make it small and, where possible, reversible:
- A draft is safer than a sent message. Let the agent prepare, and a person press send, until the results justify more.
- A change to one field, such as an order note, is safer than editing whole records.
- Creating is safer than deleting; deleting is rarely a good right for an agent.
- Anything that moves money, changes prices or contacts customers in bulk should stay behind human approval, as described in human approval and audit trail.
A useful rule: start with the smallest right that lets the pilot work, and widen it only when you see a case that really needs more.
3. Give the agent its own account
Avoid two shortcuts. The first is running the agent under an employee's login. Then you cannot tell who did what, and when that person leaves or changes their password, the agent breaks or, worse, keeps working under an account nobody is watching. The second is an administrator account "to make it simple".
Create a separate account or service user for the agent in each system, named so that anyone can recognise it, for example "ai-agent-orders". Give that account the narrow rights from step 2. This brings three benefits: the logs show clearly what the agent did, you can switch it off without affecting any person, and the rights can be reviewed on their own.
If a system only supports shared logins, treat that as a risk to record, and ask the system owner or vendor about a better option.
4. Look after the secret keys
Many integrations work through keys or tokens, which are long strings that act as a password for software. Basic rules, in line with common guidance on secrets management (OWASP: Secrets Management Cheat Sheet):
- Never paste a key into the agent's instructions, a shared document, a chat or an email. Anything the agent can read, it can in principle repeat.
- Keep keys in one place designed for it, such as the password manager or secrets store of your platform, and let the integration read them from there.
- One key per purpose, with the narrowest rights the system allows, so a leak of one does not open everything.
- Set an expiry or a replacement date, and make replacing a key a routine job, not an emergency.
- Know where each key is used. If you cannot say which integrations break when you replace it, add that to the access list.
If a key may have leaked, replace it first and investigate afterwards.
5. Review regularly
Access grows quietly. A new feature needs a new right, a test is never cleaned up, a temporary exception becomes permanent. Set a calendar entry, every quarter for most small companies, and go through the access list with the process owner:
- Is each row still needed?
- Does the agent still use every right it has? Logs often show rights that were never used.
- Are the owners and the keys still current?
- Has anything changed in the agent, the vendor or the systems since the last review?
Also review after every significant change to the agent, as part of the routine in changing an AI agent after launch, and as part of the regular check in maintaining an agent after launch. The UK National Cyber Security Centre lists managing who has access, and removing it when no longer needed, as a core part of identity and access management (NCSC: Identity and access management).
Write the outcome in one line per change: what was removed, what was added, who agreed.
6. Be able to remove access quickly
Decide in advance who can switch the agent off and how. At minimum, for each system, know how to disable the agent's account in a few minutes, and who is the deputy if the owner is away. Test it once, on a quiet day, so that the first real attempt is not an incident. The wider approach to stopping an agent is covered in incident response and kill switches.
Remove access also when the agent is replaced or retired, when a vendor contract ends, and when a person who owned a key leaves the company.
A short checklist
- Write a one-page list of every system the agent touches, with the owner of each.
- Compare what the agent does with what it is allowed to do, and close the gap.
- Decide read and write separately; start read-only or with drafts.
- Give the agent its own named account in each system, never an employee's or administrator's login.
- Keep keys out of instructions and documents, store them in one place, one per purpose.
- Review the list every quarter and after each change.
- Test that you can disable the agent's access within minutes.
You will probably find the agent can do more than anyone intended. The aim is not to make it useless, but to make sure that what it can do is what you decided.
