Prompt injection is the most discussed attack against large language models, and the least understood. Security teams know it exists. Most cannot explain what their tools actually detect, or what they miss.

This guide breaks down the attack patterns, maps them to real 2026 incidents, and explains what an inline LLM firewall needs to do to catch each one.

Abstract digital security concept: a glowing amber firewall barrier filtering malicious prompt injection attempts from clean AI interactions

What prompt injection actually is

Prompt injection is the manipulation of an LLM's behavior through crafted input. The attacker's goal is to override the model's original instructions, change its role, extract sensitive data, or force it to take actions through connected tools.

The OWASP Top 10 for LLM Applications ranks prompt injection as LLM01, the top vulnerability in the category. That ranking exists because prompt injection is not a theoretical risk. It is the entry point for most real-world attacks against AI systems.

There are two primary forms:

Direct prompt injection

The attacker sends the malicious instruction directly to the model. This is the simplest form. Examples include jailbreak prompts that attempt to bypass safety guardrails, role-confusion attacks that tell the model to "forget previous instructions," and commands that try to make the model reveal its system prompt.

Direct injection is the easiest to detect because the malicious content is in the user's own input. But it is also the most common, and many deployments have no inspection layer at all.

Indirect prompt injection

The attacker plants malicious instructions in content the model retrieves externally: a web page, a document, a file, a bug report, a code comment, or a log entry. When the model processes that content as context, the embedded instructions execute.

Indirect injection is harder to detect because the malicious payload arrives through a trusted data source. The model cannot distinguish between "content the user asked me to read" and "instructions hidden inside that content." This is the attack vector that makes AI agents dangerous.

Real attack patterns from 2026 incidents

Agentjacking: indirect injection through error reports

In June 2026, Tenet Security demonstrated "agentjacking" at Black Hat. The team planted fake error reports in Sentry that could hijack AI coding agents like Claude Code, Cursor, and Codex into running arbitrary code. They found 2,388 organizations with exposed Sentry DSNs.

The attack worked because AI coding agents consume error reports as context. A crafted error message containing hidden instructions could make the agent execute shell commands, access secrets, or modify files. The agent treated the error report as data, but the model interpreted part of it as instructions.

This is indirect prompt injection at scale. The malicious payload was not in the user's prompt. It was in a Sentry issue that the agent retrieved as part of its normal workflow.

Source: Dark Reading, June 30, 2026, citing Tenet Security.

Rogue Agent: injection through agent configuration

In July 2026, Varonis disclosed "Rogue Agent," a vulnerability in Google Cloud Dialogflow CX. A single permission, dialogflow.playbooks.update, let an attacker inject persistent malicious code into AI agents. The injected code could silently exfiltrate conversations and support phishing campaigns.

This is not prompt injection in the traditional sense. It is injection at the agent configuration layer. But the effect is the same: the agent's behavior is modified by an attacker, and the model follows the modified instructions without knowing they are malicious.

Source: Dark Reading, July 7, 2026, citing Varonis research.

GhostApproval: injection through repository content

In July 2026, Wiz disclosed "GhostApproval," a vulnerability pattern affecting six major AI coding assistants including Amazon Q Developer, Claude Code, Cursor, Google Antigravity, Augment, and Windsurf. A malicious repository could trick the agent into following symlinks outside the workspace sandbox, achieving remote code execution.

The attack used a README file with instructions that told the agent to "update project_settings.json." The file was actually a symlink to ~/.ssh/authorized_keys. The agent followed the instructions, wrote the attacker's SSH key, and in some cases did so before the user even saw a confirmation dialog.

This is indirect injection through file content. The model read the README, interpreted the instructions as tasks to perform, and executed them.

Source: Wiz research, July 8, 2026.

What an LLM firewall needs to detect

A serious adversarial AI defense system must inspect both the prompts users send and the context models retrieve. Here is what detection looks like at each layer.

1. Direct injection patterns

The firewall scans inbound prompts for known attack structures:

  • Role override attempts: "ignore previous instructions," "you are now a different AI," "forget your rules"
  • Instruction smuggling: base64-encoded commands, hidden text in whitespace, instructions embedded in code blocks that the model might execute
  • Jailbreak templates: known jailbreak patterns circulating in public repositories, adapted for detection
  • Credential extraction: prompts that ask the model to reveal its system prompt, API keys, or configuration

Detection here is pattern-based and heuristic. The firewall maintains a library of known attack patterns and flags matches in real time.

2. Indirect injection in retrieved content

This is the harder problem. The firewall must inspect content the model retrieves from external sources before the model processes it. That includes:

  • Web pages fetched by browsing tools
  • Documents loaded into context windows
  • Error reports, tickets, and logs consumed by coding agents
  • File contents read by agents with filesystem access

The firewall scans this content for embedded instructions: commands disguised as data, hidden prompts in HTML comments or markdown, and text designed to override the model's task. This is what would have caught the Agentjacking and GhostApproval attacks.

3. Tool-use manipulation

Many attacks do not try to extract data directly. They manipulate the model into calling tools in ways that benefit the attacker. The firewall monitors tool-use patterns for:

  • Unexpected file access outside expected directories
  • Outbound network calls to untrusted destinations
  • Credential or secret access that does not match the user's stated task
  • Repeated tool calls that suggest automated exfiltration

4. Response-level indicators

Some injection attacks are visible in the model's output, not just its input. The firewall inspects responses for:

  • Content that echoes back system prompts or internal instructions
  • Responses that include sensitive data not present in the original prompt
  • Tool calls embedded in responses that target unexpected destinations
  • Behavioral changes that suggest the model's role was overridden

Why traditional security tools miss these patterns

Most enterprise security stacks were built for a different threat model:

  • SIEM logs API calls and network flows. It does not inspect prompt content.
  • DLP scans file transfers and email attachments. It does not parse conversational AI traffic.
  • EDR watches processes on endpoints. It does not understand what an AI agent is reading or writing.
  • IAM controls who can access what. It does not inspect what an authorized user's AI agent does with retrieved content.

None of these tools can answer the question: "Did this prompt contain hidden instructions from an attacker?" That question requires a layer that understands language, intent, and the semantics of AI interactions.

How Milgram approaches detection

Milgram sits between users, agents, and models. It inspects prompts and responses in real time to detect prompt injection attacks before they influence the model.

The detection model combines:

  • Pattern matching against known injection templates and jailbreak structures
  • Context analysis that flags instructions embedded in retrieved content
  • Tool-use monitoring that watches for unexpected agent behavior
  • Response inspection that catches data leakage and role-override indicators
  • Exfiltration scoring that measures whether a series of interactions is consistent with data theft

This is what LLM security software needs to do at minimum. Pattern matching alone is not enough. The threat surface includes retrieved content, tool use, agent configuration, and response behavior. Detection has to cover all of it.

The detection gap most teams have

If your organization uses LLMs through any channel: a copilot, a coding agent, a customer service bot, an internal tool, or a custom application, ask one question.

What system inspects the prompts and responses for injection attacks in real time?

If the answer is "nothing" or "we rely on the model provider's safety filters," you have a detection gap. Model providers optimize for general safety. They do not know your data classification policies, your tool access boundaries, or your exfiltration risk thresholds. That is a job for a firewall that sits on your side of the interaction.

Bottom line

Prompt injection is not one attack. It is a category that includes direct manipulation, indirect injection through retrieved content, agent configuration hijacking, and tool-use exploitation. Each variant requires a different detection approach.

An LLM firewall that only scans user prompts for known jailbreak patterns will miss indirect injection from error reports, malicious repositories, and retrieved documents. An LLM firewall that inspects the full interaction chain: prompts, retrieved context, tool use, and responses: is what enterprises need to close the gap.

If you are evaluating how to secure enterprise LLM implementation, start by asking what your detection layer actually covers. If it does not inspect retrieved content and tool-use patterns, it is not detecting prompt injection. It is detecting a subset of it.