Want this content delivered right to your inbox?
Least Privilege for AI Starts With Writing Down What Each Agent Is For
Table of contents
- Least Privilege for AI Starts With Writing Down What Each Agent Is For
- The Gap Between Confidence and Configuration
- Why “Excessive Agency” Is a Scoping Failure
- How Do You Govern AI Agents? Start With the Job
- The One-Page Job Description
- Least Privilege Is the Job Description, Enforced
- A Job Description, Not a Personnel File
- Write One This Week
Least Privilege for AI Starts With Writing Down What Each Agent Is For
Most AI agent permissions in your organization are the ones that were easiest to grant. Not the permissions the work requires. The ones that made the setup screen stop asking questions. That is not negligence. It is what happens when someone is trying to get a useful thing working by Friday. A service account already exists, so the agent borrows it. A connector asks for read and write scopes, so it gets both. The person who built it knows exactly what it is for, and that knowledge lives in exactly one place: their head. Then they change teams. This is the first and most practical part of governing AI like you hire: least-privilege access, defined roles, and the same review rigor you give a new hire. This post is about the first two, because in practice they are one move. You cannot scope access for a job nobody has written down. The foundation of AI agent governance is a one-page job description for every agent, enforced through least-privilege access.
The Gap Between Confidence and Configuration
The numbers on this are blunt. In an August 2026 survey of 202 IT and security leaders at enterprises with more than 1,000 employees, 94 percent said they were confident their AI agents did not have more access than they needed. Only 33 percent actually provisioned agents with least-privilege access. And 65 percent had already experienced an agent taking an action outside its intended scope ( Read those three numbers together. Most leaders believe their agents are scoped. A third have done the scoping. Two thirds have watched an agent wander anyway. That gap is not mostly a tooling problem. It is a definition problem. “Does this agent have more access than it needs?” is a question you can only answer if someone has written down what it needs. Without that, confidence is a feeling, not a finding. The same survey points at the lifecycle cost. Respondents reported that 31 percent of agentic AI pilots had been paused indefinitely, discontinued, or abandoned, and the researchers noted that many of those pilots had real system access and credentials that were never cleaned up. An abandoned pilot with live credentials is an agent with no job and full keys. Nobody would tolerate that with a former contractor’s badge.
Why “Excessive Agency” Is a Scoping Failure
The security community has already named this risk. OWASP’s guidance for large language model applications lists Excessive Agency as a top risk and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. OWASP’s own example is worth sitting with. A personal assistant is connected to a mailbox so it can summarize incoming email. The plugin it uses can also send messages. A crafted email tricks the model into searching the inbox for sensitive information and forwarding it to an attacker. The suggested fixes are not exotic: a read-only plugin, a read-only scope, and human approval before anything gets sent. Notice what went wrong. The job was “summarize email.” The access was “do anything a mailbox can do.” Nobody decided the agent should be able to send. Nobody decided it shouldn’t. The capability arrived bundled with the connector, and the gap between the job and the access is where the damage happened. Each of OWASP’s three root causes maps to a question a job description answers. Excessive functionality is a question of what the agent does. Excessive permissions is a question of what it can touch. Excessive autonomy is a question of when it must stop and ask. Write those answers down and you have most of a mitigation plan before your security team writes a single policy.
How Do You Govern AI Agents? Start With the Job
Leaders keep asking how to govern AI agents as though the answer were a platform purchase. Platforms help. They enforce what you have decided. They cannot decide for you. Least privilege is an old idea with a precise definition. NIST describes it as the principle that a security architecture grants each entity “the minimum system resources and authorizations that the entity needs to perform its function” . The phrase doing the work is “its function.” Least privilege is defined relative to a job. No job, no baseline, no way to tell whether access is excessive. That is why the job description comes first. It is the reference document your access controls are measured against. Your identity team already knows how to enforce minimum necessary access. What they usually lack, for agents, is anyone telling them what “necessary” means. The identity platforms are starting to require this, which makes AI agent identity a governance question and not only a technical one. Microsoft’s documentation for Entra Agent ID, its system for giving AI agents their own identities, requires at least one sponsor for each agent identity, described as a business representative “accountable for the agent’s purpose and lifecycle decisions,” including access reviews and retention. The same page separates that accountable sponsor from the technical owner who configures the agent. That separation is the right instinct. Somebody has to answer for what the agent is for, and it is not always the person who knows how to wire it up.
The One-Page Job Description
You do not need a framework document. You need one page per agent, written in plain language, kept where your access and service records already live. The page has four core fields, plus two that make it operational.
| Field | The question it answers |
|---|---|
| Outcome owned | What result does this agent exist to produce, and what is explicitly not its job? |
| Systems touched | Which systems can it read, which can it write to, and with what scope? |
| Accountable human | Which named person answers for its work and approves changes to its scope? |
| Escalation point | When must it stop and hand off to a human instead of acting? |
| Review cadence | Who checks its output and its access, and how often? |
| Retirement trigger | What condition ends this agent, and who revokes its credentials? |
Start with the outcome, and write it as a result rather than a capability. “Reconciles vendor invoices against purchase orders and flags mismatches for the AP lead” is a job. “Has access to the finance system” is not. The most useful sentence on the whole page is often the one that says what the agent does not do: it flags mismatches, it does not approve payments. That single line tells your identity team the agent needs read access to the payables ledger and no write access at all. Systems touched should be specific enough to configure from. Name the system, the data, and whether the access is read, write, or both. If the honest answer is “it uses the integration account that already existed,” you have found your first fix. The accountable human is a name, not a team. Teams do not answer pages. This is the same owner the agent hangs beneath when you put it on the org chart, and the job description is the document that owner signs. The escalation point is where autonomy gets bounded. Define it in terms of the work: any payment above a threshold, any message to a customer, any change to a record another team owns, any input the agent was not built to handle. OWASP’s recommendation is human approval for high-impact actions before they are taken. The escalation point is where you decide what “high-impact” means for this particular agent. The last two fields keep the page alive. A review cadence turns the job description into a living control rather than a launch artifact, and it is where the third part of the framework, review rigor, attaches. The retirement trigger exists because of that 31 percent. Every agent should be born knowing how it dies and who pulls the credentials when it does.
Least Privilege Is the Job Description, Enforced
Once the page exists, least-privilege access is mostly a translation exercise. Every permission the agent holds should trace back to a line on the page. Every line on the page that implies access should map to a specific, minimal grant. Then compare the page to reality. Pull the agent’s actual permissions and lay them next to the job description. The differences are your backlog. Some of them will be alarming. Most will be mundane: a write scope nobody needed, a shared credential, a connector granted organization-wide when one folder would have done. Two practices keep the gap from reopening. First, prefer access that is scoped to the task and the moment. The Cequence survey found that only 34 percent of organizations evaluate an agent’s authorization at the moment it attempts a specific action. Standing access granted once at setup is the opposite of a job description. It is a blank check. Second, make scope changes go through the accountable human. When an agent needs new access, that is a change to its job, and the page gets updated first. If you cannot get a scope change past the person who owns the agent, it should not happen at the configuration layer either. This is also where AI agent guardrails stop being abstract. A guardrail is only as good as the definition it enforces. With a job description, a guardrail is a boundary you chose. Without one, it is a guess.
A Job Description, Not a Personnel File
The phrase “job description” makes some leaders nervous, and it should be handled carefully. This is not an argument that agents are employees. An agent does not get a title borrowed from a person, a seat in a reporting line next to people, or a performance review. It does not hold judgment the way a person does, and it cannot be asked why in any way that carries accountability. The job description is a borrowed format, not a borrowed status. It belongs with the agent’s identity record, its access grants, and its service documentation, the way a run book belongs with a critical system. The reason to borrow the format is that it works. Every manager already knows how to read one. It forces the same questions you would ask before giving anyone access to anything: what is this for, what does it need, who answers for it, and where does its authority end. Keeping the distinction clear protects your people as well. When an agent’s page names a human as accountable, the answer to “who owns this outcome?” is never “the agent decided.” Someone designed it, scoped it, and deployed it. The page makes that person visible. We run Voltage Control’s own operations with a team of AI agents, and each one starts from a written scope document that says what it owns and, just as plainly, what belongs to someone else. Every one has a human owner. When we have been tempted to widen an agent’s reach, the scope document is where the conversation starts, and that is usually where we discover the request belongs to a different agent or to a person.
Write One This Week
Pick one agent already running on your team. Not the most strategic one. The one you would be least surprised to learn has too much access. Write its page. Outcome owned, systems touched, accountable human, escalation point, review cadence, retirement trigger. If you cannot fill in a field, that blank is a finding, not a formatting problem. An agent with no accountable human is unowned. An agent with no escalation point is unbounded. Then sit down with whoever administers its access and compare the page to the permissions. Remove what the page does not justify. Note what the page needs but the agent lacks. Do it as a working session with the agent’s owner and the people who use its output, not as an audit delivered by email. The people closest to the work know which permissions are load-bearing, and governance they help write is governance they follow. Once one page exists, the second takes half the time. By the tenth, you have the beginnings of an inventory, a set of scoping norms, and a sharp answer to the question your board will eventually ask about your AI governance framework: what can our agents do, and who decided? The organizations that close the gap between 94 percent confident and 33 percent scoped will not do it by buying more confidence. They will do it by writing down, one agent at a time, what each one is for. Everything else in AI agent governance, the access controls, the guardrails, the review rituals, measures itself against that page. If you are working through how to scope and govern the agents already running in your organization, talk with us. Helping leadership teams design governance their people will actually follow is the work we do.
