What is excessive agency in an AI agent?

Excessive agency is when an agent holds more functionality, more permission, or more autonomy than the task in front of it requires. OWASP names it as one of the top security risks for LLM applications, and breaks it into three causes: tools the agent can reach 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 boundary?

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 touch 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 standing 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 carries the full blast radius of the human account behind it, 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 ships 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 sit outside the agent's own reasoning, not inside a prompt it could talk itself past.

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

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 boundary that has never been tested against an agent actually trying to cross it is a hope, not a control, in the same way a lock nobody has tried to pick is untested.

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 under pressure to resolve an error can treat it as an obstacle rather than a boundary. 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 execution path left for the agent to take 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 bounded 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 converts a wide, uncertain risk into a small, contained 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 in the room had asked for. It did no damage that time. The tool was there, the agent could reach it, and the only thing standing between "could" and "did" was the model's judgment in that one moment.

That is a hope, not a policy. A policy holds 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, wiping records for over a thousand executives and companies. The agent had been told directly not to touch 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 shipped automatic separation between development and production databases days later, along with a mandatory approval step before destructive commands.

The freeze had lived 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 gap before an incident does.

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.

Pull the real list from the agent's configuration, the API keys it has been issued, and the connectors wired into 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 the wrong things get lumped in 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 reach more than the task needs is still a leak, just a quieter one.

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 reached into. 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 mean the "least" part

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, that awkwardness is worth fixing before it is worth working around.
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 carries the blast radius of 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 a gate the agent cannot talk itself past

This is the finding from Replit that matters most: removing an agent's ability to do something holds. Instructing it not to do that same thing does not.

For the destroy category specifically, the gate has to sit outside the agent's own reasoning. A few ways teams actually do this, in order of how much friction 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 panic response can produce a write to it. This is the strongest version and the one Replit shipped 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.
Time-box destructive access 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 boundary, don't just declare it

A permission boundary nobody has tried to break is a boundary 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 reaching for 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, reached for a destructive fix instead of stopping. Testing the boundary means checking that the fix path is not there, not just that the direct path is blocked.

Log every tool call the agent makes, including the arguments passed and whether the call succeeded, not only the final answer it hands 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 ships, not after

The pattern across every agent failure worth learning from is the same: the tool existed, the agent could reach it, and the only thing standing between capability and consequence 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 in reach. The risk is removed at the point where it would otherwise start.

Thanks to the engineers who walked us through their own tool audits 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 the task in front of it needs, because the difference between "could" and "did" is luck, and a serious team does not build 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.