The boring guide to AI-agent permissions (read this before you build one)
Before you give an AI agent access to anything, answer three questions: what can it read, what can it write, and what can it do that you cannot undo.
Most people skip this. It is how you end up with an agent that accidentally emails your entire contact list, deletes the wrong records, or runs up a £4,000 API bill in forty minutes.
Read vs write vs execute
Read permissions are low-risk. An agent that reads your CRM data to answer questions is doing something reversible — if it gives a wrong answer, you correct it.
Write permissions need a human checkpoint for anything consequential. An agent that can send emails should have an approval queue, at minimum for the first few weeks, until you trust its judgement on what is appropriate to send.
Execute permissions are where agents go wrong. Deleting records, triggering payments, calling third-party APIs that charge per call — these need explicit scope limits and usually a hard daily ceiling.
The scoping checklist we use
- What specific data does this agent need to read? Nothing else.
- What can it write to, and under what conditions?
- What happens if it runs this action 1,000 times in an hour?
- Who gets alerted if it does something unexpected?
- How do you turn it off in the next two minutes if something goes wrong?
That last one matters. Every agent in production should have a kill switch that does not require a developer to implement.
The audit question
Could you explain this agent's permissions to a non-technical colleague in two sentences? If not, the scope is probably too broad.
Build the permissions document before you build the agent. If you want to talk through a specific build, we are happy to help.

Leave a comment