Give a coding agent only the tools and permissions its task requires, run it with scoped credentials, and require a person to approve high-impact actions. OWASP names the opposite problem Excessive Agency: too much functionality, too many permissions or too much autonomy. Enforcement belongs in the systems the agent touches, not in the agent's prompt.
The three root causes
OWASP's page on LLM06:2025 describes damaging actions taken in response to unexpected, ambiguous or manipulated output. The trigger can be a hallucination, a weak model or prompt injection. The page traces the root cause to three things:
- Excessive functionality. The agent has tools it does not need.
- Excessive permissions. Its downstream access is wider than the task.
- Excessive autonomy. High-impact actions run with no independent check.
A permission ladder
| Level | Example access | Suitable for |
|---|---|---|
| 1 | Read files in one repository | Explaining code, reviews |
| 2 | Level 1 plus write to a working branch | Drafting changes |
| 3 | Level 2 plus run tests in a sandbox | Verified drafts |
| 4 | Open a pull request, no merge rights | Normal day-to-day work |
| 5 | Deploy or change production | Only with human approval each time |
Start at the lowest rung that gets the job done. Moving up should be a decision someone records.
What OWASP recommends
The prevention list is concrete: minimise extensions and what they can do; avoid open-ended tools such as raw shell execution when a narrow tool such as a file writer will do; give downstream identities minimal access, for example a read-only database role; act in the user's context with least-privilege credentials such as OAuth with minimal scopes; require user approval for high-impact actions; and implement authorization in downstream systems instead of relying on the model to decide.
Logging and rate limiting do not prevent the problem, but they limit the damage.
Steps to apply it
- Inventory every tool the agent can call, and remove any it does not use.
- Replace generic shell access with named tools where you can.
- Issue the agent its own scoped credential, never a developer's personal token.
- Keep merge, deploy and secret-management rights out of its reach.
- Make the repository enforce reviews and status checks, so the agent cannot skip them.
- Log every tool call and review the log after incidents.
For governance beyond permissions, see AI coding agent governance.
Where Safeguard fits
Safeguard offers an MCP Guardrail, agent identity and policy gates, so an agent's actions can be checked and tied to an identity. Try a free scan on your repositories.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the setup and look at which tools and scopes are granted to the connection.
Quick check
Is a read-only agent safe?
Safer, not safe. It can still read secrets in files it can see, so scope what it can read.
Can the prompt limit what the agent does?
It can guide behavior, but OWASP advises enforcing limits in downstream systems.
Sources
Last reviewed: 19 October 2026.
