Least privilege is the principle that every user, system or AI agent gets only the access its task needs, for only as long as it needs it, and nothing more. For agents it applies twice: to the data and systems an agent can reach, and to the actions it may take with them.
Why does least privilege matter once agents act?
A person with too much access is a risk mostly when they choose to misuse it. An agent with too much access is a risk whenever it is wrong, misled or manipulated. Prompt injection, a bad source or a misread instruction can each turn spare permissions into actions nobody wanted.
Agents also tend to be granted access in bulk. A team wires an agent into a CRM and a ticketing system with a broad service account because it is quicker, and the agent inherits the ability to export every customer record. Nobody intended that; nobody removed it either.
How does least privilege work for an agent?
Think of it in three layers.
- Identity. The agent has its own identity, not a shared account or a borrowed human login, so its access can be granted, reviewed and revoked on its own.
- Reach. Each capability is connected only to the systems and fields it needs. An agent that answers delivery questions needs order status, not payment card data.
- Depth. Within what it can reach, the agent may only act as far as its proven depth: read, draft for a person, execute routine work, or move money. Reaching a system does not mean it may change it.
The practical steps, from scoping service accounts to reviewing access on a schedule, are in how to give an AI agent least privilege access.
What does an example look like?
A wealth manager deploys an agent to prepare client review packs. It needs read access to holdings, recent transactions and the last meeting note. It does not need to place trades, change addresses or see other advisers' clients. So its identity is scoped to the clients of the adviser who requested the pack, its depth is 2 (it drafts, the adviser sends), and its access is reviewed each quarter alongside the advisers' own.
How is least privilege different from need-to-know?
Need-to-know is about information: a person should see only the data their role requires. Least privilege is wider. It covers data and actions, and it includes the strength of each action, not just whether access exists. For agents the action side is the larger risk, which is why depth matters as much as data scope. Role-based access control is the usual way to implement both; least privilege is the goal it serves.
What do regulators expect?
Most security standards and financial regulators expect access to be limited to what is needed and reviewed regularly. DORA makes this part of ICT risk management for EU financial entities, covered in DORA access control and least privilege for AI agents, and holds the management body accountable for that framework, as set out in DORA management body accountability for AI agents. Expect a supervisor to ask whether your agents appear in the same access reviews as your staff.
Least privilege is one strand of agent governance, which adds certification and records to access control.
Where Pryme fits
In Pryme, least privilege is applied per capability through the minimum chain. Role scope limits what the agent may touch, the certificate sets the depth it has earned, sources limit what it may rely on, and the customer's own limits narrow it further. The lowest bound wins, and the verdict names it.
Questions people ask
Does least privilege slow agents down?
Slightly, at set-up, because someone has to decide what each capability needs. In operation it does not, and it shrinks the clean-up after any incident.
How often should an agent's access be reviewed?
At least as often as staff access, and whenever the agent's role, sources or depth change. Access left over from a pilot is a common finding.