OWASP defines excessive agency as damaging actions taken in response to unexpected, ambiguous or manipulated model output. A remediation bot that edits code and opens pull requests fits the definition. The three root causes, too much functionality, permissions and autonomy, each have a concrete control you can check this week.
The definition
Per OWASP, excessive agency is a vulnerability in systems that let a model call functions or tools. Triggers include hallucination and prompt injection, direct or indirect. The root cause is not the model being wrong. It is the system giving a wrong answer the power to do harm.
A remediation bot is a good example because its output is code and its tool is a repository.
Root cause 1: excessive functionality
OWASP's example is an agent with access to tools it does not need. For a fix bot, ask what it can do beyond proposing a patch.
- Can it run arbitrary shell commands, or only a defined set of steps?
- Can it read every repository, or only those enrolled?
- Can it change CI configuration, workflow files or branch rules?
OWASP advises avoiding open-ended extensions in favor of narrow tools. In practice, a fix bot should be able to change dependency manifests and source files in scope, and nothing about the pipeline that judges its work. Exclude workflow files and protection settings from its reach.
Root cause 2: excessive permissions
Here the issue is downstream rights. OWASP recommends least privilege identities and minimal scopes.
- Give the bot its own identity, not a developer's token, so its actions are attributable.
- Grant the smallest repository permissions that let it open branches and pull requests.
- Never put it on a bypass list for branch rules.
- Rotate and review its credentials on a schedule.
This is where the related post on what permissions a remediation bot should have goes into detail.
Root cause 3: excessive autonomy
OWASP describes high-impact actions performed without independent verification or approval. Its prevention advice is to require a human to approve high-impact actions before they are taken. Applied here:
- Merging into a protected branch is high impact. Require a reviewer.
- Deploying is higher still. Keep it behind your normal release controls.
- Start every category in a manual mode and move up only on evidence.
OWASP also says to enforce authorization downstream and not rely on the model to decide whether an action is allowed. For a bot, that means your repository rules, not the bot's own settings, are the real gate. If the bot is told to merge and your rules say no, the rules win.
What logging can and cannot do
OWASP notes that logging, monitoring and rate limiting do not prevent excessive agency, but can limit the damage. Log each proposal, the inputs, the check results and the human decision. Cap the number of pull requests per day so a runaway loop stays small.
A one page audit
| Check | Pass condition |
|---|---|
| Scope | Bot cannot edit pipeline or protection settings |
| Identity | Dedicated, revocable, named owner |
| Approval | Human review before merge, enforced by repository rules |
| Limits | Volume and diff size caps in place |
| Logs | Proposal to decision trail is retained |
Safeguard offers autonomous remediation with fix PRs. They are off by default and every category sits on Manual, so autonomy starts at the lowest level and rises only by your decision.
Quick check
Is a hallucinated fix the same as excessive agency?
No. The hallucination is the trigger. Excessive agency is the system letting that bad output act without a check.
If the model is accurate, can we relax these controls?
No. The controls exist because manipulated or ambiguous output happens whatever the average accuracy is.
Sources
Last reviewed: 19 October 2026.
