Agent permissions: how to decide what an AI agent may read, write and spend
Most agent incidents are permission incidents. The model did something it was allowed to do, and nobody had decided whether it should be. Five questions to answer for every agent before it runs, a way to write the answers down that engineers can enforce, and the three mistakes that account for most of the trouble.
When an agent does something alarming, the post-mortem almost never finds a model that broke its rules. It finds a model that followed them, inside a permission set nobody had thought about. The agent had the developer's own token because that was quickest. It could reach the whole network because nobody had restricted it. It could write to production because the integration account could, and the integration account was what was to hand.
Permissions are the part of agent engineering that gets decided by default, and defaults are generous. This piece is the set of questions we make every client answer, per agent, before the agent runs against anything real. The questions are not technical. The enforcement is, and it comes second.
Five questions, in order
What may it read? List the systems and, within each, the scope. A support agent reads the knowledge base and the ticket in front of it. It does not read every ticket, and it does not read the HR system because the same platform happens to host both. Reading is where data leaks start, so the list should be as short as the task allows, and "everything the person who set it up can read" is never the right answer.
What may it write? Separately, and shorter. Most agents that read ten systems should write to one or two. For each write, name the records and the fields. An agent that updates the status field on a ticket has a different permission from one that can close the ticket, and both are different from one that can delete it. If the vendor's permission model cannot express that distinction, put the agent behind your own API that can.
What may it spend? Money, and the things that turn into money: API calls to paid services, compute, outbound messages, purchases, refunds. Set a cap per task and a cap per day, enforce both in code, and decide what happens at the cap. Stop is the right default. An agent that pauses at its limit and asks is a well-designed agent. One that finds a way round is an incident.
Where may it reach? The network question, and the one most often skipped. An agent that can make arbitrary outbound requests can exfiltrate whatever it can read and can be steered, through a poisoned document or a hostile web page, to fetch instructions from anywhere. Allow-list the hosts each agent needs. Everything else is denied. This single control removes most of the consequence from prompt injection, because an agent that has been tricked but cannot phone anyone is an agent that has merely been confused.
How long may it hold? Credential lifetime. An agent that runs for ten minutes should hold a token that expires in fifteen. One that runs nightly should get a fresh token each night. Long-lived credentials in an agent's environment are the thing every attacker, and every runaway agent, looks for first.
Answer those five and you have a permission specification. It fits on one page, a security reviewer can read it in five minutes, and it is the document the incident review will ask for.
Write it down so it can be enforced
A specification that lives in a wiki is a wish. The version that matters is the one the code checks.
Give the agent its own identity in your identity provider, with the read and write scopes from the specification attached to that identity and nothing else. If the agent needs to act on behalf of a user, it does so with that user's delegated permission, scoped to the task, and the log shows both identities.
Put the write and spend limits in a layer the model cannot talk its way past. That means checks in the tool implementation or in a gateway in front of it, deterministic, failing closed. A system prompt that says "never spend more than $500" is documentation; a tool that refuses the call above $500 is a control. Microsoft's Agent Control Specification, released at Build in June, is one attempt to standardise where those checks sit in the loop; the idea does not need the product.
Make the network allow-list a property of the runtime, at the container, sandbox or egress-proxy level, so it holds even if the agent's code is compromised.
And log every read, write, spend and outbound request against the agent's identity, with the task ID, so a person can reconstruct what happened in order. The log is also the tool for tightening: after a month, anything in the specification the agent never used should come out.
Three mistakes that account for most incidents
Borrowed credentials. The agent runs as its builder, or as the shared integration account, because provisioning a new identity was slow. Every action is then indistinguishable from a person's, every permission the person has is the agent's, and revoking the agent means revoking the person. Fix the provisioning speed rather than accepting the shortcut.
Read scope set by convenience. The agent was pointed at a whole drive, a whole mailbox, a whole database, because scoping it was fiddly. It then summarises, quotes or acts on something it should never have seen. Scope reads to the task, and if the platform cannot scope them, copy the task's data into a space the agent can see and nothing else.
Unrestricted egress. The agent can call any URL, because the framework's default is to allow it and nobody changed the default. This is the mistake that turns a prompt-injection curiosity into a data breach, and it is the cheapest of the three to fix.
Approval as a permission
The consent model that consumer agents such as Gemini Spark shipped this year, automatic below a line and confirm above it, is a permission boundary expressed as a rule. Use the same form. For each write and each spend, decide whether it is automatic, needs a person's click, or is forbidden, and write the threshold down. A finance agent might post invoices under $2,000 from approved suppliers automatically, queue anything above for approval, and never change a supplier's bank details. That sentence is a permission policy, and it is enforceable.
The approval log is then the richest signal you have. Frequent approvals suggest the boundary is too tight; frequent rejections suggest it is too loose. Review both monthly.
Start with the registry
If you built the agent registry we described in June, the permissions column is where this specification lives. If you did not, this is the reason to. An agent with a written, enforced permission set is an agent you can leave running. One without is a person's credentials with a faster typing speed, and it will eventually type something you did not expect.
Permission scoping is the first two weeks of every governance engagement we run, and it is where clients discover what their agents could already do.
Frequently asked
What permissions should an AI agent have? The minimum for its task, decided in five parts: which systems and records it may read, which it may write (a much shorter list, down to field level), what it may spend per task and per day, which network hosts it may reach, and how long its credentials last. Each answer should be enforced in code or infrastructure rather than in the prompt.
How do you enforce AI agent permissions? Give the agent its own identity with scoped permissions in your identity provider, put write and spend checks in the tool layer or a gateway where the model cannot bypass them, restrict outbound network access with an allow-list at the runtime level, issue short-lived credentials, and log every action against the agent's identity and task ID.
What are the most common AI agent security mistakes? Running the agent on a person's or a shared integration account's credentials, granting read access to whole systems for convenience rather than scoping to the task, and leaving outbound network access unrestricted so a prompt-injected agent can send data anywhere. All three are cheap to fix before deployment and expensive after.
Related reading
- Microsoft wants an inventory of your agents
- The AI governance checklist for enterprise teams
- Gemini Spark works while your laptop is closed
Decide what the agent may read, write, spend, reach and hold before it runs. The model's behaviour is the vendor's problem; its permissions are yours.