Least privilege is one of the oldest ideas in security. NIST SP 800-53 states it as control AC-6: allow only the access that users, and processes acting on their behalf, need for their assigned tasks. Most organizations apply it carefully to people. Then they deploy an AI agent, give it an API key with broad permissions so the demo works, and move on.
Our position: an agent is a new kind of user, and it should be governed like one. Each agent gets an owner, the narrowest access that lets it do its job, credentials that expire, and a log of what it did. Irreversible or high-consequence actions need a human approval, at a threshold you set.
Why agents are different
A conventional service account runs fixed code. You can read the code and know what it will do with its access. An agent decides what to do at run time, based on its instructions, the data it reads and the tools it has. That makes its behavior harder to predict and easier to influence.
The most important difference is that an agent can be manipulated through the content it processes. An instruction hidden in an email, a support ticket or a web page can redirect it. This is indirect prompt injection, and no current technique fully prevents it. So the question is not only "will the agent behave?" It is "what is the worst it could do with the access it has, if it were told to?"
The OWASP GenAI Security Project names this risk excessive agency in its Top 10 for LLM Applications, and treats agent-specific risks in a separate Top 10 for Agentic Applications, released in December 2025.
Five common mistakes
- Borrowing a person's access. The agent runs as the developer or the person who set it up, inheriting everything they can do.
- Standing, broad keys. A long-lived API key with write access to a whole system, because scoping it was slower.
- Secrets in prompts or code. Credentials placed in a system prompt, a configuration file or a repository, where they can be read or leaked.
- One identity for many agents. Several agents share a credential, so nobody can tell from the logs which one did what.
- No owner. The agent was built in a project that has ended. Nobody reviews its access, and nobody would notice it misbehaving.
None of these is exotic. Each is the shortcut that makes a pilot work, carried into production.
Limit authority by access, not by instruction
The tempting control is the system prompt: "Never delete records. Never email anyone outside the company." Write those instructions, but do not rely on them. A model can be talked out of its instructions. It cannot be talked out of a permission it does not have.
If an action would be unacceptable when the agent is manipulated, the agent should not have the access to take it alone.
That single rule sorts most design decisions. Read access to customer records may be fine. Write access to billing, without approval, usually is not. The agent's instructions describe what it should do. Its permissions decide what it can do.
Five rules for agent access
- Its own identity. Every agent runs under its own identity, never a person's and never shared, so every action is attributable.
- The narrowest scope. Grant the specific operations on the specific data the task needs. Read before write. One system before several.
- Credentials that expire. Prefer short-lived, scoped tokens issued at run time over standing keys. Keep secrets in a vault, never in prompts or code.
- Tools held to the task. Connect only the tools the job requires, and scope each one. A tool connection is a grant of access, and should be reviewed like one.
- An owner and a log. A named person owns each agent's access, reviews it on a schedule, and can see what the agent did.
Retrieval needs the same discipline. An agent that searches documents should only reach what the person it is acting for could open. Otherwise it becomes a way around your existing access controls.
An access matrix you can review
The practical artifact is a matrix: each agent, each system, what it can do there, and who owns it. It turns a vague question ("are our agents safe?") into one an identity team can answer line by line. An illustrative example:
| Agent | Customer records | Billing | Owner | |
|---|---|---|---|---|
| Customer assistant | Read | None | None | Head of digital |
| Collections agent | Read | Write, with approval | Send, with approval | Finance operations |
| IT helpdesk agent | None | None | Send | IT service desk |
Review the matrix whenever an agent gains a tool, a model changes or the agent's purpose shifts, and at least on the same cycle as your access reviews for people.
Where people stay in the loop
Approval for every action defeats the point of an agent. Approval for none puts the organization's money, data and reputation in the hands of whatever the agent last read. Set the threshold by consequence:
| Action | Typical control |
|---|---|
| Reading within scope | Automatic, logged |
| Drafting a message or a change | Automatic, with a person sending or applying it |
| Reversible change below a set value | Automatic, logged and sampled for review |
| Payments, deletions, external messages, access changes | Human approval before the action |
The exact threshold is a business decision, made by the agent's owner and recorded, not left to the team that built it.
A checklist for every agent
- Does it run under its own identity, not a person's or a shared one?
- Is every permission one the task actually needs?
- Do its credentials expire, and are they kept out of prompts and code?
- Is each connected tool scoped and reviewed?
- Can its retrieval reach anything the person it serves could not?
- Which actions need a human approval, and who set that threshold?
- Who owns it, and when was its access last reviewed?
- Is there a log showing what it did, and does anyone look at it?
Agent access is one of the eight boundaries we look at in what AI adds to your attack surface.
