LLM excessive agency: what to log and alert on

For OWASP LLM06 excessive agency, log every tool call with the identity it ran under, the arguments, the result and any human approval, then alert on calls outside the agent's expected scope, unusual volume, repeated denials and high-impact actions. OWASP notes logging does not prevent the problem, but it limits damage and speeds investigation.

What is excessive agency?

OWASP defines it as the risk that an LLM-based system takes damaging actions because its output was unexpected, ambiguous or manipulated. The cause can be hallucination, a weak model, or prompt injection from a user, a compromised extension or another agent. It names three roots: excessive functionality (more tools than needed), excessive permissions (more downstream access than needed, or a generic high-privilege identity), and excessive autonomy (high-impact actions run without checks or approval).

Its examples read like an audit finding list: a read-only extension that also has delete functions, a discarded extension left available, a shell tool with no limits on commands, and a read task using a database identity that can write.

What should you log?

Make each record answer who, what, with what authority, and who approved.

• Identity. The end user, the agent, and the credential or scope used.
• Tool and arguments. Which function, with parameters, redacted for secrets and personal data.
• Result. Success, failure or denial, and the size of any data returned.
• Approval. Whether a human approved, who, and when.
• Context link. A session or request ID that ties the call to the prompt and the retrieved content.
• Tool inventory changes. When a tool is added, removed or its scope changed.

Store logs where the agent cannot edit them, and set retention that fits your investigations.

What should you alert on?

Each alert maps to one of OWASP's three roots.

Functionality. A call to a tool that is not on the agent's allow list, or a tool that has not been used in months suddenly active. Alert on new tools attached to an agent.

Permissions. A call that ran under a broader identity than the user's, a denial from a downstream system, or repeated denials in a short window. Denials are a good early signal that the agent is trying something it should not.

Autonomy. High-impact actions such as delete, send, pay or deploy that ran without approval, or an approval that arrived in under a second. Also alert on volume: a burst of calls, large data reads, or many outbound messages.

Tune with a baseline. Watch a week of normal use before setting thresholds, then review alerts weekly.

Which controls come before logging?

Logging is the last layer. OWASP's mitigations start with limiting the tools and the functions each exposes, preferring narrow, purpose-built tools over open-ended ones, restricting downstream permissions, running actions in the user's context with minimal scopes, requiring human approval for high-impact operations, and enforcing authorization in downstream systems instead of trusting the model. Safeguard's MCP server at mcp.safeguard.sh gives agents access to security tools, and a guardrail view shows how tool calls can be checked. Try it here.

Open the full version at /demos/mcp-guardrail.

What to do

1. Inventory every agent, its tools and the identity each tool uses.
2. Remove tools and functions the agent does not need.
3. Switch to per-user, least-privilege credentials.
4. Require approval for delete, send, pay and deploy.
5. Log each call with the fields above and ship them to a store the agent cannot write to.
6. Build the five alerts above and test them with a safe, planned exercise.
7. Review denied actions and approvals weekly.

Quick check

Sources

• OWASP GenAI: LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.