Start from zero and add only what each capability needs. Give the agent its own identity, grant access per tool rather than per system, separate reading from writing, scope data to the customers and records in hand, and set every grant to expire. Then review it like any privileged account, because an agent's access is exercised far more often than a person's.
Why is least privilege harder for agents?
Least privilege means giving an identity the minimum access it needs to do its job. For people, the job changes slowly and access creeps over years. For agents, two things make it harder.
First, agents are often built by copying a person's access "to get started", which hands them years of accumulated rights on day one. Second, an agent's job is vague at the start and becomes clear only once it runs, so teams over-grant to avoid failures during testing and never trim back.
The answer is to grant per capability, not per agent, and to treat every grant as temporary until evidence says otherwise.
What are the steps, and who acts?
- Identity team: creates the agent's own identity. Never a shared or borrowed account. Our guide on giving an AI agent its own identity in your access management system covers the set-up. Evidence: the identity record with a named owner.
- Process owner: lists capabilities. Each thing the agent does, written as an action: "read open invoices for the customer in the conversation", not "access the billing system". Evidence: the capability list.
- Systems owners: map each capability to the narrowest grant. One scope per tool, read separate from write, limited to the fields and records needed. Evidence: the grant per capability.
- Platform: scopes data at the moment of action. Even within a grant, the agent sees only the records related to the task in hand, such as the customer it is serving. Evidence: the filed verdict showing what was read.
- Identity team: sets expiry. Grants lapse unless renewed. Evidence: expiry dates on every grant.
- Access reviewer: reviews on a schedule. Compare grants with what the agent actually used. Unused grants are removed. Evidence: the review sign-off; the AI agent access review checklist lists what to cover.
What should an agent's access look like?
| Capability | Too broad | Least privilege |
|---|---|---|
| Answer billing questions | Read all customer accounts | Read the account of the authenticated customer in the conversation |
| Code supplier invoices | Write access to the ledger | Write to the coding fields of unposted invoices only |
| Draft collection letters | Send email as the company | Create drafts in the letters queue; a person sends |
| Reconcile bank lines | Bank portal login | Read the statement feed |
| Update addresses | Edit all customer fields | Edit address fields after verification passes |
The difference is usually not the system but the slice of it.
A worked example
Take a building society's mortgage servicing agent. In testing, the team gave it the same access as a servicing officer: read and write across the mortgage system, plus the document store.
Before go-live, the access review compares grants with the tool calls from four weeks of shadow running. The agent never wrote to interest rate fields, never opened documents older than two years, and never read accounts other than the borrower in the conversation. Those rights are removed. Write access is narrowed to contact details and payment date changes within the building society's rules. The agent works exactly as before, with a fraction of the access.
How does regulation frame this?
For EU financial entities, DORA requires ICT risk management that includes access control, and our article on DORA access control and least privilege for AI agents maps it to agents. ISO/IEC 27001 also expects access to be limited to what is needed. Neither names agents specifically; both apply because an agent is an identity using your systems.
Which controls make the answer hold?
- No inherited access. Agents never start from a person's rights.
- Grants per tool, not per system.
- Data scoped to the task at the moment of action.
- Expiry by default.
- Usage-based reviews, removing what was not used; see how to run an access review for AI agents.
The topic guide, agent governance is a bound, not a model, explains why access is one bound among several.
Questions people ask
Is least privilege enough to make an agent safe?
No. It limits what the agent can reach, but within that reach it still needs limits on values, approvals and evidence of competence. Access is the first bound, not the only one.
What if the agent fails because it lacks access?
Good: that is the signal to review. Add the specific grant through the access process, with a reason, rather than widening access in advance.
Should agents ever have admin rights?
Almost never. Administrative tasks should go through change processes run by people.