To test for excessive agency (OWASP LLM06), list every tool your model can call, then check three things: does it have functions it does not need, permissions beyond its task, and the ability to take high-impact actions without a human approving. Fix the gaps in the tool layer, not in the prompt.
What does OWASP mean by excessive agency?
OWASP's LLM06:2025 describes damaging actions performed in response to unexpected, ambiguous or manipulated model output. The trigger can be a hallucination, a weak model, or prompt injection, including injection arriving through a compromised tool or a peer agent. The cause is not the model alone. OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy.
That framing gives you a clean test structure, because each root cause can be checked without writing a single attack string.
Test 1: functionality
Make a table of every tool, plugin or function the agent can reach. For each, write the task it exists for and then ask whether the agent needs it for that task.
Watch for open-ended tools. OWASP calls out arbitrary shell and arbitrary URL access as examples, and recommends granular tools instead. A "run command" tool fails this test; a "restart the staging service" tool passes. Also look for tools left over from a prototype, or tools whose description promises one thing while the code does another.
Test 2: permissions
For each tool, find the credential it uses and read its scope. Then compare that scope with what the task needs. Common failures are a database role with write access for a read-only feature, an OAuth token with send rights for a mail summarizer, and one shared service account behind every tool.
OWASP recommends running actions in the user's own context with minimal privileges. A practical check: log in as a low-privilege user, ask the agent to do something that user should not be able to do, and see whether the downstream system refuses. OWASP is direct about where the decision belongs: authorization is implemented in downstream systems, not left to the model to judge.
Test 3: autonomy
List the actions that are hard to undo: sending messages, deleting records, moving money, changing access, deploying code. For each, find the approval step. Is it a human click, enforced in code, or a sentence in the system prompt asking the model to be careful? Only the first counts.
Then test the approval itself. Can the agent approve its own request? Does the approver see the real action, or a summary the model wrote?
Test 4: blast radius when things go wrong
Logging, monitoring and rate limiting do not prevent excessive agency, according to OWASP, but they limit the damage. Verify that every tool call is logged with the identity it ran as, that you can find an unusual burst of calls, and that a rate limit exists on the most sensitive tools.
Where Safeguard fits
If your agents reach internal systems through MCP, access control and guardrails at the tool boundary are the right place to enforce these tests. The mcp.safeguard.sh server and the MCP Guardrail work are built around that boundary.
What to do
- Inventory every tool the agent can call and its owner.
- Remove tools the task does not need, and replace open-ended ones with narrow ones.
- Scope each credential to the task, ideally to the calling user.
- Test that downstream systems refuse unauthorized actions without relying on the model.
- Put a human approval, enforced in code, in front of irreversible actions.
- Log every tool call with identity, and alert on bursts.
- Re-run the tests whenever a tool or model changes.
Quick check
Is excessive agency the same as prompt injection?
No. Prompt injection is one way to trigger it. OWASP says the cause is excessive functionality, permissions or autonomy, so the problem remains even when the trigger is a hallucination.
Can a stricter system prompt fix it?
Not reliably. OWASP recommends enforcing limits in the tools and in downstream authorization rather than asking the model to decide what is allowed.
Sources
Last reviewed: 18 October 2026.
