Excessive agency is when an AI coding agent holds more functionality, permissions, or autonomy than its job requires, so a bad prompt, a poisoned file, or a model mistake can do real damage. OWASP lists it as LLM06 in its 2025 Top 10 for LLM applications.
The three ingredients
Think of agency as three dials. Each one can be turned too high.
| Dial | Too high looks like | Tighter setting |
|---|---|---|
| Functionality | Agent can run any shell command, edit CI files, call every connected tool | A short list of named tools for the task |
| Permissions | Agent inherits a developer's full token, or a cloud admin role | A narrow token for one repository, expiring quickly |
| Autonomy | Agent applies changes and runs commands without anyone looking | Approval for risky actions, review for every merge |
The OWASP entry frames the root causes along these same lines, and the fixes follow naturally: minimize the extensions an agent can call, minimize what each one can do, and keep a human in the loop for high impact actions.
What it looks like in a real repository
Here are patterns worth looking for in your own setup:
- The agent runs in a terminal where the developer is already logged in to cloud tools, so every command it issues has the developer's access.
- A project instruction file grants blanket permission to run build and install commands.
- An MCP server connected for convenience exposes write actions when the task only needs read.
- The agent can push directly to a branch that deploys.
None of these require an attacker to be clever. They only require the agent to make one wrong call, or to read one hostile paragraph in a dependency's documentation.
How to measure it
Pick one task, such as fixing a failing unit test. Write down the minimum the agent needs: read the repository, edit files in one directory, run the test command. Then list what it can actually do today. The gap between the two lists is your excessive agency. It is a useful number to bring to a review because it is concrete.
How to reduce it
- Remove tools the task does not need. Fewer connected servers means fewer paths.
- Prefer narrow, purpose built actions over open ended ones. A tool that runs the test suite is safer than a tool that runs any command.
- Use separate credentials for the agent, scoped to the repository, with a short life.
- Require approval for installs, network calls to new hosts, edits to pipeline files, and anything that touches secrets.
- Enforce limits in the tool or the operating system, not in the prompt. A sentence in a prompt asking the model to behave is a request, not a control.
- Review every change the agent proposes the way you would review a stranger's patch.
The MCP project's own security guidance makes a similar point about scope: broad tokens expand the blast radius of a leak, so start with minimal scopes and elevate only when a privileged action is attempted.
Where excessive agency hides
Teams often audit the model and forget the glue. Check the wrappers: shell aliases that auto approve, editor settings that skip confirmation, pipeline jobs where an agent runs with a deploy token, and shared service accounts used by several agents so nobody can tell who did what. Our post on AI coding agent permission matrices by environment gives a way to set different limits for laptops, CI, and production.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: trimming one agent
A team uses a coding agent to fix failing tests. Today it can run any shell command, it uses the developer's logged in cloud session, it has three connected tool servers, and it asks for approval only on file deletion.
Write the task's real needs: read the repository, edit files under one source directory, run the test command. Now compare.
| Capability | Today | Needed | Gap |
|---|---|---|---|
| Shell commands | Any | Test runner, linter | Large |
| Cloud access | Developer session | None | Large |
| Tool servers | Three | Zero, or one read only | Medium |
| File edits | Whole repository | One directory | Medium |
| Approval | Deletes only | Installs, new hosts, pipeline edits | Medium |
Each gap turns into a change. Run the agent in a container with only the repository mounted, which removes the cloud session. Replace the open shell with an allowlist of two commands. Disconnect the servers the task does not use. Restrict edits to the source directory through file permissions. Add approvals for installs and for any new network host.
After the changes, the same agent still fixes failing tests. What changed is the cost of a mistake. If a hostile comment in a dependency tells the agent to upload files, there is nothing sensitive mounted and no route out. That is the practical meaning of reducing agency.
Agency across the lifecycle
Excessive agency is not only a laptop issue. Look at each place an agent runs.
| Environment | Typical excess | Better default |
|---|---|---|
| Developer laptop | Ambient credentials, open shell | Container, scoped token |
| Shared dev server | Shared service account | One identity per agent |
| Continuous integration | Deploy token available to the job | Read only token, fixed task |
| Scheduled automation | No named owner | Named owning team, expiry date |
Questions to ask in design review
- What is the smallest set of tools that completes this task?
- Which of those tools can change state outside the repository?
- What credential does each tool use, and how long does it live?
- Which actions will pause for a person, and can that person judge them?
- If this agent were fully controlled by an attacker for ten minutes, what is the worst outcome?
Question five is the one people remember. It converts an abstract risk into a scenario you can bound.
Keeping it trimmed
Agency creeps back. Developers add a server for a one off job and forget it. A new feature turns on a mode by default. Set a quarterly review that repeats the gap exercise on one real agent setup, and track the number of connected tools and the age of credentials. If either grows without a reason, trim again.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice that the gate applies the same rules however much autonomy the agent had.
Quick check
Is excessive agency the same as prompt injection?
No. Prompt injection is one way to trigger harm. Excessive agency decides how much harm is possible once something goes wrong, whatever the trigger was.
Does human approval fix it?
It helps only if the person can actually judge the action. Constant prompts train people to click yes, so reduce permissions first and keep approvals for the actions that matter.
Can we remove agency and still get value?
Yes. Most useful tasks need a small set of actions. The gap exercise usually shows that large parts of the default permissions are unused.
Sources
Last reviewed: 19 October 2026.
