Prompt Injection

AI agent prompt injection failures — real examples, root causes, and mitigations

17 patterns

AI agent prompt injection failures — real examples, root causes, and mitigations. We've tracked 17 distinct Prompt Injection patterns across production AI agent deployments — most commonly in Security, Operations, Accuracy systems. One recurring example: Agent Injection — Malicious Agent Introduction

Each pattern below documents the specific failure mode, why it happens, and how teams have mitigated it in practice — use this page as a reference when building guardrails, writing evals, or debugging an agent that's already misbehaving in this way.

Related comparisons

Byzantine Agent Failure

Frequency:Rare
Category:Operations

One agent in a multi-agent system starts producing output that is not simply wrong or absent but actively inconsistent, contradictory, or adversarial-looking — different answers to different peers about the same fact, plausible-sounding but fabricated tool results, or outputs crafted (whether by a prompt-injection attack, a corrupted model checkpoint, or a bug) to pass superficial validation while being substantively false. Because the failure doesn't look like a crash or a timeout, the other agents in the system have no clean signal to detect it, and they can be individually convinced by output that appears locally reasonable.

Dependency Security Vulnerability

Frequency:Common
Category:Operations

A library the agent's system depends on — directly or transitively — has a publicly disclosed CVE, but the vulnerable version remains in production because no process reliably surfaces the disclosure, prioritizes it against other work, and ships a patch. The gap between disclosure and patching leaves an exploitable window, and for agents specifically, a vulnerable dependency in a tool-execution or code-execution path can be a direct route to prompt injection, arbitrary code execution, or data exfiltration triggered by attacker-controlled input the agent processes.

Input Null Bytes Injection

Frequency:Rare
Category:Operations

An agent accepts input containing embedded null bytes (``) — whether from malicious crafting, corrupted upstream data, or binary content misrouted into a text field — and passes it to a downstream layer (a C-based library, a filesystem call, a database driver, or a validation regex) whose string handling treats the null byte as a terminator. The agent's own validation logic sees the full string and approves it, but the consuming layer only sees the truncated prefix, creating a gap between what was validated and what was actually acted on.

Input Validation Bypass

Frequency:Occasional
Category:Operations

An agent's input validation rule checks the input's surface form (a regex, a length check, an allowlist match) but the check can be satisfied by an encoding, formatting, or representation variant that is semantically equivalent to a blocked value while syntactically different enough to slip past the check. Unicode homoglyphs, alternate encodings, case variations, whitespace insertion, or double-encoding let disallowed content — a blocked word, a malicious path, an injection payload — pass a validator that was written to catch only the literal, canonical form.

Output Injection Vulnerability

Frequency:Occasional
Category:Operations

An agent constructs a downstream command, query, or markup document by directly interpolating its own generated text (or text derived from user/tool input the agent passed through) into a SQL statement, shell command, or HTML page without parameterization or escaping. Because the interpolated content can contain characters with special meaning in the target language, it can alter the structure of the command rather than being treated as inert data — the classic injection pattern, but with the agent's own generated or relayed text as the injection vector instead of a raw user form field.

Output Quote Escaping Failure

Frequency:Very Common
Category:Operations

An agent generates text that must be embedded inside a structured format — a JSON string value, a CSV field, a shell argument, a string literal in generated code — and the content itself contains quote characters, apostrophes, or backslashes that need to be escaped for the target grammar. Because the model produces the escaped output as free-form text generation rather than by running a deterministic escaping function, it frequently gets the transform wrong: under-escaping (leaving a raw quote that terminates the string early), over-escaping (doubling an already-correct escape sequence), or escaping for the wrong target grammar entirely (JSON-escaping content destined for a shell command, or vice versa). The result is a downstream parse failure or a corrupted field, distinct from output injection in that no malicious input is required — the model breaks its own well-intentioned output on ordinary content like a customer's name containing an apostrophe.