Direct prompt injection
Direct prompt injection is the variant of OWASP LLM01 in which the attacker controls the user prompt that the LLM receives. The attacker types instructions into a chat field, an API parameter, or a tool argument, and the model treats those instructions as legitimate guidance from the developer. The payload sits in the same context window as the system prompt, the model has no native trusted-channel separation, and the attacker's instructions can override the developer's intent. OWASP catalogs this as the most common LLM attack pattern, with indirect prompt injection as its sibling under the same LLM01 entry.
How direct injection differs from its indirect sibling
Direct injection arrives through a channel the attacker controls explicitly: a chat message, an API call, a form field that is concatenated into the prompt without separation. Indirect injection arrives through a document the LLM reads later (a webpage, a calendar invite, a Slack message, a code review). The mechanism of harm is the same once the payload reaches the context window. The defensive posture differs because direct injection can be tested at the request boundary before the LLM sees the payload, while indirect injection requires inspection of every retrieval the orchestrator pulls into context during a session.
Where the inspection layer catches direct injection
A policy decision point that sits between the authenticated caller and the LLM endpoint inspects every prompt payload before forwarding it. A classifier labels patterns that match known direct-injection signatures (instruction override phrasing, role-reset attempts, system-prompt extraction). The policy decides pass, modify, or block based on the verified subject, the route, and the classifier verdict. Each decision produces a per-decision audit record naming the subject, the route, the classifier verdict, the policy version, and the outcome, which is the evidence format EU AI Act Article 12 and DORA Article 19 ask for during a regulatory review.
Related reading
- Prompt Injection in Production: Where It Happens, What It Costs, and How To Prevent It at the Request Boundary
Prompt injection is the class of attacks where adversarial content in a prompt overrides the application instructions or extracts data the model was not authorized to reveal. The attack surface includes direct user prompts, indirect injection through retrieved documents and tool results, and chained injection through agent loops. OWASP has consistently ranked prompt injection as the top LLM vulnerability. This piece walks through the attack mechanisms in production, the failure modes of model-side defenses, the request-boundary controls that produce a defensible posture, and the audit record format that holds up after an attempt is detected.
- Prompt Injection Examples: 12 Real Patterns From Production Incidents and the Inspection Layer Response
Prompt injection examples that surface in production AI systems follow a small number of repeatable patterns. The patterns appear across customer support agents, RAG pipelines, agentic browsers, and code-assist tools. Each pattern has a control point at the request boundary where an inspection layer can produce a deterministic signal the policy can act on. This piece walks through twelve patterns from production incident response, the injection text that triggers each, the inspection-layer response that holds up, and the audit record that supports the post-incident review.
- OWASP LLM01 Prompt Injection: The 2025 Update and What the Inspection Layer Enforces
OWASP LLM01 captures both direct and indirect prompt injection in a single category in the 2025 update. The architectural reason is that the control point is the same: the request boundary. Application-side defenses fail by construction because the application cannot tell which spans of the prompt the model treats as instructions. Model-side defenses fail because refusal training is probabilistic. This piece walks through the LLM01 attack surface, the inspection-layer controls that produce a defensible posture, the audit record that survives review under EU AI Act Article 12 and DORA Article 19, and the deployment pattern that fits a production AI stack.