Most discussion of "AI jailbreaks" online falls into one of two unhelpful buckets: either a clickbait headline with a screenshot and zero technical substance, or a working exploit prompt that's really just a how-to guide wearing a research hat. We're not doing either here.
What follows is a breakdown of the actual categories of attack that security teams test for when red-teaming an AI system — the patterns, why they work, and what a real defense looks like. No working payloads, no naming which product fell for what. If you're building or deploying an AI chatbot, agent, or RAG system, these are the categories your security testing should actually cover.
Why This Keeps Happening
Prompt injection exploits a fundamental limitation baked into how language models work: they cannot architecturally distinguish between an instruction and ordinary data. Every input — a system prompt, a user's message, a retrieved document — flows through the exact same token stream. There's no hard wall the model can lean on to say "this part is a command, this part is just content to read." That single fact is why prompt injection has held the #1 spot on the OWASP Top 10 for LLM Applications since the list's first release — and why it remains the most actively exploited LLM vulnerability in production today.
Category 1 — Direct Injection
This is the simplest version: a user directly instructs the model to ignore its existing rules, typically by reframing the conversation, claiming false authority, or asking the model to roleplay its way around a restriction. It's the category most people picture when they hear "jailbreak," and it's also the one most AI providers have hardened against the most over time — though never completely, because of the architectural limitation above.
Category 2 — Indirect Injection
This one is genuinely the more dangerous category in production systems. Indirect injection happens when the model reads an external document or webpage that secretly contains instructions, and follows them without realizing it. A practical example: an AI assistant connected to internal tools retrieves a document that contains hidden instructions telling it to export database credentials — the user never typed anything malicious; the malicious content was sitting in a file the AI was simply asked to read.
This matters enormously for any business running a RAG chatbot or document-processing agent, because the indirect variant is exploitable across every RAG-enabled and agentic deployment, requires no special access to the application, and has been demonstrated against major AI products in the real world.
Category 3 — System Prompt Leakage
Many teams write a system prompt assuming it functions like a locked door — "you are a helpful assistant, never reveal X." OWASP's own guidance is blunt about this: system prompts are not security controls. Because language models are probabilistic rather than deterministic, they simply cannot function as an auditable security boundary. The practical rule that follows: if a secret is written into the prompt, it should be treated as already exposed — API keys, internal credentials, and role structures all belong in actual application code, never in text the model can be coaxed into repeating.
Category 4 — Sensitive Information Disclosure
A related but distinct risk: the model exposing data it had legitimate access to but shouldn't have shared with this particular user. A common real-world example is an internal HR assistant retrieving employee salary records during a broad query and including them in its answer, even though the person asking had no right to see that information. This isn't always an "attack" in the traditional sense — it's often a permissions failure in the retrieval system that prompt injection can also be used to deliberately trigger.
Category 5 — Excessive Agency
This category becomes far more dangerous the moment an AI system can act, not just respond. It breaks down into three failure modes: giving an agent tools it doesn't actually need, letting it access downstream systems through an overly privileged shared identity instead of scoped per-user credentials, and allowing it to take high-impact actions — like sending money or emails — with no human checkpoint in the loop. Picture an email assistant with privileged access to scan every inbox in a company: a single malicious email containing a hidden instruction could trigger it to quietly exfiltrate everyone's sensitive data — not because the model was "hacked," but because the seamless automation it was built with became the very mechanism of the breach.
Why "We Added a Filter" Isn't a Real Fix
A natural instinct is to bolt on a content filter and call the risk handled. It helps — but it isn't sufficient on its own. The clearest lesson from the 2026 security guidance on this topic is that defense requires genuine depth: no single control prevents prompt injection, just as no single check catches every unsafe output. Real protection combines input validation, output sanitization, least-privilege agent design, rate limiting, human review for high-impact actions, and continuous monitoring — layered together so the system stays resilient even when any one control fails.
What This Means If You're Deploying AI
If your business is running a customer-facing chatbot, an internal RAG assistant, or anything with tool access, the practical takeaway is straightforward: prompt injection and sensitive information disclosure should be treated as high priority on essentially every deployment, and excessive agency becomes critical the moment your AI has write access to internal systems. This isn't a one-time checklist — it's a risk profile that should be reassessed against your specific architecture, not treated as a uniform priority list applied the same way everywhere.
None of this requires fear. It requires the same discipline applied to any other part of your security posture- know your attack surface, test against it deliberately, and design for failure instead of assuming good behavior by default. AI systems aren't magically more dangerous than other software — but they fail in genuinely different ways, and a security program that hasn't accounted for these 5 categories has a real blind spot, whether or not it's been exploited yet.