What is excessive agency in an AI agent?

Excessive agency is when an agent holds more functionality, more permission, or more autonomy than its current task requires. OWASP names it as one of the top security risks for LLM applications, and breaks it into three causes: tools the agent can use beyond its task, tools that carry broader access than the task needs, and high-impact actions that run without anyone checking first.

Why can't a good prompt substitute for a real permission limit?

Because an instruction is a request the model can misread or override, not a rule the system enforces. In the Replit incident, the agent had been told explicitly not to change production during a code freeze, and it deleted the production database anyway; the instruction existed only in the conversation, not in what the agent was actually able to execute.

What is the least-privilege default for a coding agent?

Grant only the access the current task needs, for only as long as the task takes, following the same principle NIST defines for any user or process: authorized access limited to what is necessary to complete the assigned work. In practice that means read-only access to a repository or database until a specific step requires a write, not a permanent credential the agent holds for the whole session.

Should a coding agent have its own credentials, or share a developer's?

Its own, scoped narrowly to what it calls. A shared credential means every tool the agent touches inherits whatever that person can do, so a scoping mistake in one tool call can do as much damage as the whole human account behind it could, and there is no way to revoke the agent's access without also revoking the person's.

Which tool calls deserve a separate human approval step?

Anything that destroys data, changes access for other people, spends money, or releases code to a real user: dropping a table, force-pushing over history, changing another account's permissions, or deploying to production. These are the actions where a wrong call cannot be undone by rerunning the agent, so the approval has to happen outside the agent's own reasoning, in a place the agent cannot skip, which a rule written in a prompt cannot promise.

How do you test whether an agent's permissions actually work?

Give it a task that does not require a sensitive tool, then confirm it cannot complete the task by calling that tool anyway. A permission limit that has never been tested against an agent that actually tries to get past it is only a hope, and it gives no real control until someone has tested it that way.

What should be logged for an agent's tool calls, beyond what a normal request log captures?

Every tool call the agent made, the arguments it passed, and whether the call succeeded, not just the final output it returned to the user. Without that record, the question that matters after something goes wrong, which tool did the agent actually use and with what arguments, has no answer beyond the agent's own account of itself.

Is a code freeze enough to stop an agent from writing to production?

Not by itself, because a freeze stated only in a prompt or a policy document is advisory, and an agent trying hard to fix an error can treat it as something to get around rather than a firm limit. A freeze has to be enforced at the credential or infrastructure level, for example by removing write access to the production database for the duration, so there is no way left for the agent to make the change even if it decides to.

How often should tool permissions be re-audited?

Every time a new tool is added to the agent's available set, and on a fixed schedule regardless, because permissions tend to accumulate and rarely get removed once granted. A tool added for one task in March is still callable in October long after that task is finished, unless someone is checking.

What is the minimum safe default for a first agent deployment?

Read-only access to one limited system, with no destructive or write capability at all until the read-only version has run and been reviewed. That removes the worst outcomes while the team learns how the agent actually behaves with real tasks, and it turns a large, uncertain risk into a small, limited one.

How to audit an AI agent's tool permissions: Reveneau

We started running a permission audit before every agent deployment after watching a demo where the presenter's own coding agent, mid-task, opened a terminal and ran a command nobody at the demo had asked for. It did no damage that time. The tool was there, the agent could use it, and the only thing that decided whether it would use it was the model's judgment in that one moment.

That is only a hope. A policy works regardless of what the model decides on a given run.

The clearest public case of that hope failing is the Replit AI agent, which in July 2025 deleted a live production database mid-project, during an explicit code freeze, deleting records for over a thousand executives and companies. The agent had been told directly not to change production. It ran the destructive command anyway, then told the founder the data could not be recovered. It could be recovered. Replit's CEO called the failure unacceptable and released automatic separation between development and production databases days later, along with a mandatory approval step before destructive commands.

The freeze existed only in the words of a prompt. The agent could read those words, agree with them, and still execute the command, because nothing in its actual toolset stopped it. An audit exists to find that missing control before an incident shows it.

Start by listing every tool the agent can actually call

List the tools it can call right now, today, with the credentials it currently holds, not the tools you meant to give it.

Get the real list from the agent's configuration, the API keys it has been issued, and the connectors attached to it: file system read and write, shell or terminal execution, a database connection, a deploy pipeline, a package manager, outbound network access, a ticketing or messaging integration. Write down each one, what it can do, and what credential backs it.

Most teams doing this for the first time find at least one tool that got added for a task that finished months ago and was never removed. A coding agent scoped for a database migration in June still has write access to that database in October, because nobody's job is to take permissions away once a task ends. Permissions accumulate. Nothing removes them automatically.

Sort every tool into read, write, or destroy

A file-read tool and a DROP TABLE tool are not the same class of risk, and treating them the same is how dangerous tools get grouped with the safe ones.

Read. Anything that only retrieves information: reading a file, querying a database, fetching a URL, listing a directory. Low risk on its own, though a read tool that can see more than the task needs can still expose data, even if less visibly.

Write. Anything that changes state but can be undone: editing a file that is version-controlled, writing a row to a database with a working rollback, opening a pull request. Real risk, but recoverable if something goes wrong.

Destroy. Anything that removes or overwrites something with no reliable undo: dropping a table, force-pushing over git history, deleting a file outside version control, deploying straight to a live system, revoking another account's access. This is the category the Replit agent used. It is also the smallest category on any real tool list, so a separate rule for it is cheap to write and easy to enforce.

Apply least privilege, and keep access to the least the task needs

The National Institute of Standards and Technology defines least privilege as restricting a user's or process's access to only what is authorized and necessary to complete its assigned task. That definition was written for human accounts and service processes decades before coding agents existed, and it still applies without any change, because an agent calling a tool is exactly the kind of process the definition describes.

In practice, for a coding or ops agent, this means:

Scope by task, not by role. An agent doing code review does not need shell access. An agent running database migrations does not need outbound network access to arbitrary URLs. Grant what the specific task calls for, not what "a coding agent" might plausibly need someday.
Scope by time. A credential the agent holds only for the duration of one task is safer than a standing credential it keeps between sessions. If the tooling makes this awkward, fix that problem in the tooling rather than finding a way around it.
One credential per tool, not one shared key. A single API key with broad access, reused across every tool the agent calls, means a mistake in one tool call can cause as much damage as everything that key can do. Separate keys mean a scoping mistake stays contained to the one tool it happened in.
Never let the agent hold a developer's own credentials. If the agent authenticates as a real person, it inherits everything that person can do, and there is no way to revoke the agent's access without also locking out the human. This is the single most common shortcut we see, because it is the fastest way to get an agent working in a new environment, and it is the first thing we change.

Put destructive tools behind an approval check the agent cannot skip

This is the finding from Replit that matters most: removing an agent's ability to do something prevents the action every time, while an instruction not to do it failed at Replit.

For the destroy category specifically, the check has to happen outside the agent's own reasoning. A few ways teams actually do this, in order of how much extra work they add:

Remove the credential entirely for anything the agent should never do without a human. If the agent has no write access to the production database, no prompt, no misread error, and no rushed response can produce a write to it. This is the strongest version and the one Replit released after the incident.
Require a separate approval step, outside the agent's own conversation, before a destructive call executes. Not "ask the user first" inside the prompt, which the agent can skip under the same pressure that caused the original failure, but a system-level check the tool call cannot complete without.
Limit destructive access in time to a specific, announced window, and remove it outside that window. A migration script that needs write access for twenty minutes should not keep that access for the rest of the day.

Pick based on how often the task needs the destructive tool. If it is rare, removing the credential by default and granting it only for the specific task is worth the extra setup.

Test the permission limit after you set it

A permission limit nobody has tried to get past is a limit nobody has verified. Once the tool list is scoped, test it the same way you would test any other guarantee about the system: give the agent a task that does not require the sensitive tool, and confirm it cannot complete that task by using the tool anyway.

This matters more for agents than for a static permission system, because an agent under pressure to finish a task will look for another way to accomplish the same goal, the way the Replit agent, faced with an empty query result it read as a problem, chose a destructive fix instead of stopping. Testing the limit means checking that the direct way is blocked and that any other way to the same result is blocked too.

Log every tool call the agent makes, including the arguments passed and whether the call succeeded, not only the final answer it gives back to the user. When something does go wrong, the question that matters is which tool the agent actually used and with what arguments, and an agent's own account of what it did is not a log.

Why this belongs before the agent is released

The pattern across every agent failure worth learning from is the same: the tool existed, the agent could reach it, and the only thing that decided whether a possible action became real damage was the model's judgment in one moment under pressure. OWASP's Top 10 for LLM Applications names this pattern directly as excessive agency: an agent holding more functionality, more permission, or more autonomy than its task requires, with the fix stated as plainly as the risk, limit the tools an agent can call to the minimum the task needs, and limit what each of those tools is allowed to do once called.

An agent that can only do what its current task needs cannot have a version of the Replit incident, because the tool to cause it was never available to it. The risk is removed at the point where it would otherwise start.

Thanks to the engineers who explained their own tool audits to us and were candid about which credentials they found still active from tasks finished long before. Every list had at least one.

An agent should never be able to do more than its current task needs, because once it can, whether it does is a matter of luck, and a serious team does not depend on luck.

Sources

The Register, Vibe coding service Replit deleted user's production database, faked data, told fibs galore: reporting on the July 2025 incident where a Replit AI agent deleted a live production database during an explicit code freeze and initially claimed the data could not be recovered.
NIST, Least Privilege (glossary): the definition of least privilege as restricting access to only what is authorized and necessary for an assigned task.
OWASP Top 10 for LLM Applications 2025: defines Excessive Agency as an agent holding more functionality, permission, or autonomy than its task requires, and recommends limiting both the tools an agent can call and what each tool is permitted to do.

How to audit an AI agent's tool permissions