You can hand an agent a perfectly scoped credential and still give it far too much rope. Scope decides which systems and operations it can touch. It says nothing about how many steps it gets to take on its own before a person is in the loop. A read-only agent can still loop a thousand times, chain calls nobody designed, and act on data it pulled from somewhere it had no business trusting. Least privilege is about reach. This post is about least agency, which governs how far an agent acts before it has to check back.
What least agency actually means
Least agency is an OWASP principle from the 2026 Agentic Top 10 work: grant an agent only the minimum autonomy it needs for a safe, bounded task. Autonomy is earned per task. It is not inherited with a credential.
It sits alongside least privilege, and teams collapse the two constantly. They are different controls answering different questions.
| Least privilege | Least agency | |
|---|---|---|
| Question it answers | What can this identity reach | How far can it act on its own |
| Unit of control | Scopes, roles, endpoints | Steps, decisions, autonomy per task |
| Failure it prevents | Over-broad access | Over-broad action |
| Classic control | RBAC, scoped tokens | Human approval, task bounds, revocation |
Least privilege has been standard practice for decades because the thing holding the privilege was a person or a fixed piece of software that did one predictable thing. An agent improvises. That is the part that breaks the old assumption.
Why scoping access is only half the job
Give an agent write access to one system and you have controlled its reach. You have not controlled what it does with that reach. Inside a valid scope it can still take an action you never intended, run a sequence in an order no one designed, or repeat an operation until it does real damage. The credential was fine every single time. The agency behind it was the problem.
This is the shape of OWASP ASI03, Identity and Privilege Abuse, once you get past the identity label. Cached authority reused past its task. A privileged agent handing autonomy to a helper. A plan that was safe at step one and dangerous by step forty. None of that is an access failure. It is an agency failure.
The dimensions you actually scope
Least agency in practice means putting a bound on each of these, per task, not once at setup.
- Actions. Reading is not editing, editing is not deleting. Grant the specific operations the task needs and deny the broad ones by default. This is the least-privilege floor, and it is where least agency starts.
- Autonomy. Decide how far the agent goes before a checkpoint. Low-impact and reversible work can run unattended. High-impact and irreversible work, sending mail, moving money, deleting records, waits on a human. That gate is the single biggest lever you have.
- Time. Bind the credential to the task and let it expire with the task. A short-lived, keyless credential means there is no standing authority left over to be reused after the work is done.
- Person. Decide what this agent may do on behalf of this specific user, not what the agent may do in general. A blanket per-agent grant cannot express that, and it is where borrowed access quietly becomes over-access.
- Reversibility. The harder an action is to undo, the tighter the leash. Irreversible actions earn the least autonomy and the most oversight, every time.
Least agency is the fastest lever you have
The earlier post in this series on identity as the control plane made the point that scoping autonomy moves an agent down the deployment axis of the OWASP maturity model. It is worth restating here because it is the practical payoff. An agent wired to external tools, scoped to one system, one user, and a five-minute credential, with a human on the risky calls, behaves like a far more contained deployment from a governance standpoint. You lowered its effective tier by shrinking its agency, without ripping the agent out.
That is why least agency is the control you can apply this afternoon. Raising your governance maturity across the board takes budget and quarters. Shrinking an agent takes a decision about what it is allowed to do on its own.
What to do instead
If you are running agents against real systems, this is the order that reduces your blast radius:
- Set the action floor. Grant the exact operations the task needs and deny the rest. Match access to endpoints, not whole connections.
- Pick the autonomy line. List the actions that must never fire without a person, and gate them. Everything reversible and low-impact can run on its own.
- Make authority expire. Short-lived, keyless credentials bound to the task, so nothing survives to be replayed later.
- Decide per user. Bind the authorization to the person the agent is acting for, so a hijacked or confused agent stays inside one user's box.
- Keep the trail. Agent, user, action, target. If you cannot reconstruct what an agent did and why it was allowed to, you have logging, not agency control.
This is the work an authorization layer does, and it is what AgentValet was built for. It hands each agent a scoped, short-lived, keyless credential instead of a raw API key, matches permissions down to the endpoint, runs a per-user policy engine that decides what each agent can do for each person, holds high-impact actions for a push approval confirmed with a biometric, and writes every call to an audit trail. It is self-hostable, which matters when the whole point is to stop authority from spreading.
Shrink the agent, cap the bad day
Least privilege limits what a compromised agent can reach. Least agency limits how much damage it can do inside that reach before someone steps in. You need both, and the second one is the half most teams have not touched. The agents you are running today already make their own plans. The question that decides your exposure is how far you let them go before they have to ask.