Least privilege has been the backbone of enterprise access control for thirty years. It assumed two things that are no longer reliable. The first was that the principal acting on a credential was a human, or a piece of automation a human had written and could predict. The second was that the operations a principal needed were stable enough to enumerate, review, and certify on a quarterly cadence. Agents break both assumptions, and the model that worked for users does not survive contact with a system that picks its own tools, composes its own actions, and adapts to whatever input it sees in a session.
Most security teams we work with are still treating agent identity as a service account problem. The agent gets a credential. The credential gets a scope. The scope is reviewed at the same cadence everything else is reviewed. That model fits a batch job. It does not fit a system that decides at runtime what to query, what to call, and what to do with the result. By the time the next access review runs, the agent has already used its permissions in combinations the team never wrote down and could not have anticipated.
The Problem with Static Scopes
The traditional path to scoping a service account is to list the operations it needs to perform and grant exactly those. Agents do not have a fixed list of operations. The reason to deploy one is that it composes a workflow at runtime from whatever tools are in front of it. If the team writes a narrow scope, the agent fails in cases it should be able to handle and engineers loosen the scope until it works. If the team writes a broad scope, the agent can produce action chains the team never modeled, including chains the agent would never take on its own but will take when an input pushes it there.
The compromise most organizations have landed on is the broad scope, with the unspoken assumption that the agent will only use a small portion of it in practice. That holds until something convinces the agent to use the rest. Prompt injection is the obvious case. It is not the only one. A poorly framed task can produce the same outcome. A retrieval result that carries misleading context can produce the same outcome. A tool description an attacker has rewritten can produce the same outcome. The agent's behavior depends on data the security team does not control, and the scope has to assume that data is hostile.
The harder failure mode is not the single dangerous action. It is the legitimate looking sequence. An agent with permission to read a table, write to a workspace, and send an email can produce a data exfiltration in three steps, none of which look anomalous on their own. Each call sits comfortably inside the granted scope. The chain is what causes harm, and the chain is invisible to the controls that govern the individual calls.
What Just-in-Time Means for an Agent
The first instinct most teams reach for is just-in-time access. That model works well for humans because the request to elevate is rare, traceable, and approved by another human. It does not translate cleanly to agents because the elevation events are not rare. An agent doing useful work elevates frequently, and the question of who approves the elevation is not obvious. A human reviewer would defeat the point of the deployment. An automated approver is itself a policy decision that needs to be governed.
The pattern that has worked on the agentic deployments we have helped harden is task-scoped delegation. The agent does not hold its full set of permissions persistently. It receives a tightly scoped token at the start of a task, the token expires when the task ends, and the scope of the token is derived from the task description rather than from a static role. That moves the policy decision from a quarterly access review into the moment the task is dispatched, which is where the team actually understands what the agent is being asked to do.
The implementation detail that matters here is who derives the scope. If the agent derives its own scope from the task it received, an attacker who can influence the task can influence the scope. The scope derivation has to sit in a layer the agent does not control, with rules the agent cannot rewrite. That is a small piece of infrastructure, but it is the difference between a system that limits damage during a compromise and a system that hands the attacker exactly the permissions they need to keep going.
Designing Permissions Around Tasks, Not Identities
The mental model that consistently produces defensible designs is to stop thinking of the agent as an identity and start thinking of each task as the unit of authorization. The identity gives the agent enough permission to ask for a task. The task is what carries the actual access. Tasks are short lived, observable, and revocable. Identities are persistent and difficult to constrain without breaking the workload.
That reframing changes several decisions downstream. The audit log is no longer a stream of agent actions against a permanent scope. It is a sequence of tasks, each with its own derived scope, its own input, and its own set of actions. The access review is no longer an exercise in deciding whether the agent's permanent scope is still appropriate. It is a periodic review of the task templates that exist and the scope each template produces. The incident response question shifts from what did this account touch to which tasks ran and which actions did each task authorize. Every one of those questions becomes more answerable.
The other shift is that data sensitivity becomes a property the task has to declare. An agent task that touches regulated data is a different authorization profile than an agent task that touches a marketing report. The data class informs the scope, the logging level, and the human review requirement. Treating all agent activity as a single class because it shares an identity is one of the patterns that has produced the worst incidents we have seen, because it hides high stakes work inside the same audit stream as routine traffic.
The Audit Trail That Survives a Real Investigation
The control environment around an agent only matters at incident time if the audit trail can answer the questions an investigation will ask. The questions are predictable. Which task produced this action. What input triggered the task. What permissions were derived for it. What tools were invoked, in what order, with what arguments. What data was returned. What downstream actions resulted. The systems we see in production rarely have answers to half of these.
The missing piece is usually the linkage. The agent logs its calls. The platform logs the tokens. The data store logs the reads. Nothing ties them to the task that produced them. An investigator can see that something happened. They cannot prove which task caused it, which input was responsible, or whether the activity was inside the policy at the time. Without the linkage, the only honest answer to a regulator is that the organization does not know, and that is not an answer that ends an investigation well.
The fix is not exotic. A task identifier that propagates through every call, attached to every log line the agent produces, threaded into every token the platform issues, recorded against every read and write the downstream systems perform. It takes engineering work to set up and almost no work to maintain once it exists. The organizations that have done it are the ones that can answer the questions cleanly. The ones that have not are the ones that find out at the worst possible moment what their logging cannot reconstruct.
"The first hard incident with an agent is usually not the one a team prepared for. It is a sequence of small, authorized actions that produced an outcome no one would have approved if asked. The control that catches it is not at the action level. It is at the task level, and the audit trail that reconstructs it is not the one most platforms ship with by default."
What This Looks Like in Practice
Organizations getting this right share a small set of patterns. Agents do not hold long lived broad credentials. Tasks are the unit of authorization, with scopes derived in a control plane the agent cannot influence. High sensitivity tasks require human confirmation in band, and the confirmation is recorded against the task rather than against the agent. Every log line, on every component the task touches, carries the task identifier. Access reviews look at the task templates and their derived scopes rather than at static role assignments.
None of that requires a new product. It requires deciding that the agent is not a user, the scope is not static, and the audit trail has to be reconstructable from the task downward. Once that decision is made, the engineering is straightforward. The harder part is convincing teams that the identity centric model they have used for decades is not the right starting point for this work, and that the analogies that feel familiar are exactly the ones leading to the gaps we are now seeing in production.
Least privilege is not the wrong idea. It is the right idea applied to the wrong unit. Apply it to the task, not the identity, and the model still holds. Apply it to the identity and treat the task as incidental, and the agent will eventually do something the policy did not anticipate. The deployments that survive the next round of regulatory attention will be the ones that have already done the reframing. The ones that have not will be answering questions they did not prepare for, in a forum where vague answers carry a price.