AI agents fail in ordinary, checkable ways: they hold too many tools, too many permissions, act without approval, trust manipulated content, run without limits, or leave no record. Most of the list comes from OWASP guidance. Preparing means shrinking what an agent can touch and keeping a trail you can read after something goes wrong.
We could not find an authoritative list of "systemic" agent risks, so we do not claim one. The first eight items follow OWASP's 2025 LLM Top 10. The last two are our own synthesis, and we label them.
The ten failure modes
1. Excessive functionality. OWASP's LLM06 describes an agent given extensions it does not need, for example one that can read documents but also modify and delete them. Preparedness check: list every tool each agent can call and remove any it does not use. Delete trial plugins that were dropped but never unplugged.
2. Excessive permissions. A read-only extension that connects to a database as an identity with insert, update and delete rights, or one acting for a single user through a shared high-privilege account. Check: give each tool the narrowest identity, and run user-scoped actions with that user's rights.
3. Excessive autonomy. A deletion or payment that runs without confirmation. Check: mark high-impact actions and require human approval for them.
4. Hallucinated actions. OWASP lists hallucination or confabulation as a common trigger: the model confidently calls the wrong tool or invents a parameter. Check: validate tool arguments against a schema outside the model, and test with deliberately odd inputs.
5. Manipulated input. Direct and indirect prompt injection can steer an agent through a web page, document or email it reads. Check: treat all retrieved content as untrusted, and keep untrusted content away from tools that can send data out or change state.
6. Compromised tool or peer agent. OWASP notes injection can come from a malicious extension or, in multi-agent systems, a compromised peer agent. Check: inventory every extension and MCP server, pin versions, and review what each can reach.
7. Unbounded consumption. OWASP LLM10 covers uncontrolled inference leading to denial of service and cost blowups. Agents loop, so one request can trigger many calls. Check: cap model calls, tool calls and runtime per task, and set a budget with an automatic cutoff.
8. Supply chain of agent components. Models, tools, plugins and packages all arrive from somewhere, and LLM03 in the OWASP list is about those supply chains. Check: keep an inventory of agent dependencies, scan the packages, and use an allowlist for tool servers.
9. No usable audit trail (our synthesis). If you cannot tell which agent called which tool with which identity, you cannot investigate. Check: log agent identity, tool, arguments hash, result status and approver for every action, and test that you can reconstruct one incident from logs alone.
10. Shared fate (our synthesis). Many agents may share one model, one credential or one tool server, so one failure spreads. Check: map shared dependencies, give agents separate credentials, and rehearse a kill switch that cuts a whole agent class off.
What does a kill switch look like?
It is a control you can use in minutes without a deploy. Examples: revoke the agent's credential, disable a tool server in your gateway, or switch off a client type. Safeguard lets tenant admins switch off any client type, including MCP clients, CLI, runners, IDE extensions and browser extensions. Whatever platform you use, test the switch before you need it.
How should you test?
Write five abuse cases per agent in plain language: "the agent reads a hostile web page", "the tool returns an error loop", "the user asks for something outside scope". Run them in a sandbox with fake data, and record whether a limit, approval or log caught each one. This is red teaming at a small scale and needs no attack tooling.
What are the limits of this list?
It focuses on tool-using agents. It does not cover model training risks, and it is not a forecast of events. NIST's AI Risk Management Framework offers a broader, voluntary structure for governing AI risk, and the framework is under revision, so check its current page.
What to do
- Inventory agents, their tools and the identities they use.
- Remove unused tools and narrow every permission.
- Require approval for high-impact actions.
- Validate tool arguments outside the model.
- Cap calls, runtime and spend per task.
- Log every action with agent identity.
- Scan and pin agent and tool dependencies.
- Test a kill switch, then run five abuse cases per agent.
Quick check
What are the root causes of excessive agency?
OWASP names excessive functionality, excessive permissions and excessive autonomy.
Is human approval enough on its own?
No. Approvals help for high-impact actions, but you also need narrow permissions, input validation, limits and logs.
Sources
- OWASP GenAI: LLM06:2025 Excessive Agency
- OWASP GenAI: LLM10:2025 Unbounded Consumption
- OWASP GenAI: LLM Top 10 for 2025
- NIST AI Risk Management Framework
Last reviewed: 18 October 2026.
