# AI Agent Security: 4 Failure Modes That Are Not Prompt Injection > Source: > Published: 2026-09-18 11:46:10+00:00 Prompt injection is one item on a list of ten. That is worth sitting with, because if you read the agent security conversation online you would think it was the whole list. The [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/llm-top-10/) opens with LLM01:2025 Prompt Injection, and then names nine more things that will take your system down: Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption. Nine of the ten are not about someone typing something clever into your chat box. Here is why that matters more every month. Prompt injection is an input problem, and the model vendors are working on it with resources you do not have. The other nine are architecture problems, permission problems, budget problems and dependency problems. Those are yours. They do not get fixed by a better model, and in my experience they are the ones that actually cost a business money, because most of them do not require an attacker at all. Four of them are the ones I would check first on any agent that is allowed to act. Each one below is quoted from the standard, then translated into what it looks like on a Tuesday when the agent is working exactly as designed. OWASP defines this as a system that has been "granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions", and then does damage through unexpected or manipulated output. The important clause is the last one: regardless of cause. No adversary required. The standard breaks it into three root causes, and they are worth memorizing as three separate questions: **Excessive functionality.** Capabilities beyond what is operationally necessary. The classic version is handing an agent a shell tool because it was easier than writing four narrow ones. OWASP says it plainly: avoid open-ended extensions in favour of granular functionality. **Excessive permissions.** Broader access rights than the role needs. The agent runs as a service account that can write to every table because that is the credential you had lying around. **Excessive autonomy.** High-impact actions executed without independent verification. The agent sends, refunds, deletes or publishes with nothing between the decision and the effect. Most teams I talk to have all three, and none of them were decisions. They were defaults. The control is not clever. It is a written list of what this job may touch, scoped to that job, plus a human approval gate on anything consequential. One line from the mitigation guidance is the part people skip: implement authorization validation in downstream systems rather than relying on the LLM to police itself. The model is not your access control layer. It never was. LLM05 covers "insufficient validation, sanitization, and handling" of model output before it reaches something else. This is the failure mode that feels least like security and most like plumbing, which is exactly why it survives review. An agent emits a string. The string gets interpolated into a query, or a shell command, or a rendered page, or a config file. Nothing was injected from outside. The model simply produced a plausible sentence in a context where a sentence is executable. The test I use is a single question: where does this agent's output stop being text and start being an instruction to another system? Every one of those boundaries needs the same validation you would apply to a form field filled in by a stranger, because in terms of trust, that is what it is. LLM10 is the one I think is most underrated, and the standard gives it a name I like: "Denial of Wallet (DoW)". OWASP describes it as attackers initiating high-volume operations to exploit pay-per-use cloud AI service models, imposing an unsustainable financial burden. The agent version does not need an attacker. It needs a retry. An agent that fails, retries with its full context appended, fails again and retries again is a cost loop that nobody wrote and nobody sees until the bill arrives. Multi-turn agent runs already grow context faster than most people expect, and a retry loop multiplies whatever that per-turn cost had already become. The failure is silent, it looks like normal usage in every dashboard, and the alert is an invoice at the end of the month. The mitigations are unglamorous and they are the same ones you already know from API design: rate limits and per-user quotas, timeouts and throttling on intensive operations, resource monitoring, anomaly detection, and graceful degradation under load. The only new part is remembering that the agent is a user of your system, and a poorly behaved one. LLM03 covers vulnerabilities inherited through the chain: models, training data, deployment platforms, and the third-party components around them. An agent's real surface area is rarely code you wrote. It is a model you did not train, a tool server you installed last month, a package that wraps an API, and a prompt template you copied. Every one of those is something that can change under you without a deploy on your side. The question I would put on every agent review is uncomfortable and cheap to answer: if each third-party component in this agent were replaced tomorrow with a subtly worse version, which one would we notice, and how? If the answer for most of them is "we would not", you do not have a supply chain, you have a collection of assumptions. None of them requires a villain. Excessive agency is a permission you granted. Improper output handling is a boundary you did not name. Unbounded consumption is a loop with no ceiling. Supply chain risk is a dependency you did not review. Prompt injection gets the attention because it has a narrative, an attacker doing something sneaky. The other four just sit there and behave like ordinary engineering debt until the day they do not. This is where I think agent work is heading, and it is a good thing for the people reading this. Building an agent that demos is now table stakes. The scarce skill is running one: bounding what each job can touch, naming an owner for every action with a consequence, putting a ceiling on spend, and keeping a record you can actually check afterwards. That work looks a lot more like change management than like red teaming, and it does not get commoditized by the next model release. If you want to be paid for agent work in a year, get good at the boring half. Anyone can make one run. Making one run for nine months without a surprise is the job. I put the whole operator layer I use into the Agent Ops Club, and the free tier is genuinely free: [the eight AI Employees](https://club.reinventing.ai/ai-employees) on GitHub under an MIT licence, the Hire Your First AI Employee walkthrough, Masterclass modules 1 and 2 in full, the free public trainings and calendar, and Agent Ops Chat. No card required. Each one is a named role with a named job, which is the whole point of this post. The next step is small. Open one of them on GitHub, read what it is allowed to do, and check it against the first failure mode above. If you cannot name the boundary of a job, that is the work. If you build or run agents and want to compare notes with other builders, come and find us in [Vibe Coding is Life on Facebook](https://facebook.com/groups/vibecodinglife).