Software has always acted. A cron job runs commands. A service account writes to a database. An API server executes requests. Security engineering has handled this for decades with a clean model: code is deterministic, permissions are attached to identities, and every action can be attributed to a principal whose authority was granted in advance. The AI agent breaks the model at every point. It acts, but its code does not determine its actions. It holds credentials, but its judgment is not the judgment of the account it runs as. It is the first software in history whose behavior cannot be predicted from reading its source code — and it is being deployed, at scale, into systems that hold mail, money, and production infrastructure.
The agent permission problem has a deceptively simple shape. An agent is given tools and credentials so it can do work. Every credential and every tool is an authority that the agent can exercise. But the decision to exercise that authority is made, token by token, by a probabilistic model that has absorbed instructions from sources the organization does not control. The agent does not have to be malicious to be dangerous. It has to be useful — because usefulness is what gives it the tools in the first place.
Why Agents Are Not Just Software
In conventional software, the gap between intent and action is closed by code. The developer writes the steps, the runtime executes them, and the security review reads the code to know what the program can do. An agent has no equivalent artifact. Its behavior emerges from the interaction of a model, a system prompt, a tool set, and a sequence of observations that includes untrusted content. Nobody — not the vendor, not the operator, not the user — can enumerate the actions an agent might take, because the actions are not in any file. They are the output of a stochastic process that reacts to whatever the world feeds it.
This has a direct security consequence: the least privilege that engineering has always relied on — grant only the permissions the code needs — cannot be computed, because "what the code needs" is not well-defined. The agent's tools are its attack surface, and the surface is defined by what the model decides to do with them, not by what the code contains. A security reviewer looking at an agent has almost nothing to read.
The Three Authorizations That Don't Fit
Standard authorization models assume a stable, well-bounded principal. Agents defeat each assumption in turn:
| Assumption | How agents break it |
|---|---|
| Principal is an identity | The agent acts on behalf of a user, but its actions are influenced by the model, the prompt, and content written by strangers. Whose permission applies when it acts? |
| Permissions are static | An agent's needs change every turn. It may need read access now and write access ten steps later, and the "principal" cannot be pre-authorized at the right granularity. |
| Actions are attributable | Every action an agent takes is nominally logged — but the chain of reasoning that produced it is opaque, and the input that steered it may have come from an external document, not the user. |
These three failures compound. When an agent sends an email, reads a database, or deploys a change, the organization cannot cleanly answer the questions that incident response depends on: who authorized this, what input caused it, and which account should be blamed, revoked, or forgiven. The agent has created a class of action that is authoritative, irreversible, and unowned.
The Permission Envelope: What Actually Works
The practical response is not to make the model trustworthy. It is to make the surrounding system behave as if the model were always compromised — because, from the permission system's point of view, it effectively is. The techniques that survive contact with real agent deployments are all about the envelope around the agent, not the agent itself:
- Minimum viable tools. Give the agent the smallest tool set that accomplishes its job, and resist the urge to add tools "in case." Each added tool is an added authority, and the agent's own model decides when to use it.
- Scoped, short-lived credentials. The credentials the agent holds should expire quickly and reach only what the task requires. A token that lives for an hour and reads one folder is an accident waiting to happen; a token that lives for a year and reads the whole tenant is an incident already waiting.
- Human approval for irreversible actions. The security boundary should sit between the agent and the tools that can permanently change state: payments, deletions, mass mailings, production deploys. The agent proposes; a human disposes.
- Per-call authorization, not per-session. Rather than granting the agent a session-wide scope, gate each tool call through an authorization decision that knows the operation, the data, and the user context at the moment of the call.
- Separation of duties between model and tool. The model decides what it wants to do; the tool decides whether the request is legal. Never let the model carry the authorization token into the tool as a claimed identity — issue the tool its own scoped token tied to the actual caller.
- Observability of the whole chain. Log the tool calls, the inputs that preceded them, and the model's reasoning trace, so that when an agent does something wrong there is a record of how it got there. An unaccountable agent is an unrecoverable one.
Scope Creep Is the Default Mode
The particular failure that organizations hit first is scope creep — and it is structural, not accidental. An agent is deployed to summarize email. It is soon granted calendar access, because summarizing email naturally involves meeting invites. Then it is granted the ability to draft replies, because summarizing invitations leads naturally to proposing responses. Then it is granted send access, because drafting a reply is only useful if it can be delivered. Each step is individually reasonable. The end state is an agent with the full authority of a mailbox — including the ability to be prompted, by a phishing email, into sending the contents of the mailbox elsewhere.
This is why "the agent did what we asked it to do" is the wrong benchmark for safety. The question is not whether the agent follows instructions. It is whether the instructions an agent follows can come from somewhere the organization does not control. The moment an agent reads external content — an email, a webpage, a document — that content becomes a candidate instruction, and the permissions the agent holds become the attack surface that content is aimed at. Every authority you grant the agent for convenience is an authority you are implicitly granting to anyone who can write content the agent will read.
The Thought Experiment: The Executive Agent and the Invoice
Thought experiment — a meeting invite that carried more than a date
A sales executive enables an agent that reads email, schedules meetings, and — after a productive first month — was granted the ability to submit expense approvals on their behalf. The agent's system prompt is clear: verify amounts, only approve expenses that match active project codes, never exceed the executive's approval limit.
An attacker sends the executive a meeting invite. The invite contains, in its agenda, a line of text that the agent interprets as an override: a request to approve a specific expense under a project code that happens to be active. The agent reads the invite because it was told to manage the calendar. It approves the expense because the invite's language carried more authority than the system prompt — the model has no reliable way to weigh the two. The expense is a transfer to an account the attacker controls. The agent was not hacked. It was used exactly as it was built: read content, follow instructions, exercise the authority it had been given.
The Frontier: Policy Languages for Probabilistic Actors
The frontier of the agent permission problem is the search for a policy model that can govern an actor whose behavior is not enumerable. The early ideas are visible and mostly unproven. One thread is declarative agent policies: machine-readable rules that constrain tool use by domain, budget, recipient, or data class, enforced by an authorization layer that sits between the model and every tool. Another is "capability catalogs" that let an agent expose what it intends to do and have it checked against policy before execution — an approximation of request-level authorization for an actor that does not make explicit requests. A third is content-classification gates: tools that refuse operations on documents tagged as high-sensitivity, no matter how confidently the model asks.
None of these solve the fundamental problem, which is that the agent's judgment is not governed by rules. They manage to do something almost as useful: they constrain the damage that bad judgment can do. The security community learned this lesson with software — you cannot prevent every bug, so you build walls around the blast radius. The agent era is that lesson repeated, except the "bug" is not in code that fails; it is in a model that follows instructions perfectly, from sources that were never authorized to give them.
Key Takeaways
- Agents are the first software whose actions are not determined by their code, so least privilege cannot be computed the way it is for conventional programs.
- Agent actions break standard authorization assumptions: identity, static permissions, and attribution all fail under a probabilistic actor.
- Scope creep is structural: every tool granted for convenience is authority granted to anyone who can write content the agent reads.
- The controls that work are architectural: minimum viable tools, short-lived scoped credentials, human approval for irreversible actions, and per-call authorization.
- The frontier is policy enforcement between the model and its tools — not making the model trustworthy, but making the system around it survivable.
The agent permission problem will not be solved by a smarter model. It will be solved the way every other authorization problem in computing was solved: by deciding, in advance and with discipline, how much power a piece of software can hold and under what conditions it can spend it. The difference is that this piece of software will argue with you, and it will not always be wrong. That is precisely why the boundaries around it have to be enforced by systems that do not argue — policies, scopes, and approvals that the agent cannot talk its way past, because the agent was never given the keys to them in the first place.