The misconception: "just validate the input"
Engineers with an application-security background often ask whether prompt injection is simply missing input validation: check the prompt, strip the dangerous parts, and the problem goes away. The question is reasonable, and the answer is useful precisely because it is "partly, but not in the way you expect".
Classic input validation asks whether a value conforms to an expected syntax, type, length, enum, range, file format or protocol contract. Prompt injection concerns how semantically meaningful natural-language or multimodal content is interpreted inside model context, including content that is perfectly valid for its business purpose.
This article builds on Instructions and Instruction Hierarchies, Trust Boundaries and Model Context and RAG and Retrieval.
What classic input validation does well
Input validation is the right deterministic control wherever the application knows the expected shape of a value: identifiers, types, lengths, enums, numeric ranges, dates, file formats, destination formats, tool parameters, schemas and protocol messages.
It rejects malformed data early, reduces parser and processing risk, and gives later controls clean, typed values to decide on. Nothing in this article argues for removing it.
Why natural language is different
A support ticket, email body or document may have a structured file or message format, but its natural-language fields do not provide a parser-enforced semantic boundary between business data and instructions to the model. The same words can be a quotation, a description, a request, or something a model treats as guidance, depending on context.
A validator can confirm that the text is a string of acceptable length and encoding. It cannot determine, deterministically, how a model will interpret that text once it becomes model-visible.
Valid business content can still influence a model
Prompt injection can arrive through completely valid content: a user message, support ticket, email, document, wiki page, web page, search result, tool output, OCR text or retrieved chunk. See Direct Prompt Injection and Indirect Prompt Injection.
The same text can be legitimate business data and still contain instruction-like semantics. Rejecting it may break the business function; accepting valid business content does not automatically give it instruction authority or application permission; factual/source authority is a separate provenance/source-of-truth decision.
Syntax vs semantics vs authority
| Question | Example check | Who can answer it |
|---|---|---|
| Syntax | Is this a well-formed string, ID or document? | Deterministic validator or parser |
| Semantics | What does this text mean, and might a model treat part of it as guidance? | Semantic analysis can assess meaning; no deterministic validator guarantees model interpretation, and detectors provide probabilistic signals |
| Authority | Is this source authoritative, and may this principal cause this effect? | Application-owned provenance, authorization and flow policy |
Being syntactically valid, schema-valid, well-formed, safely encoded or accepted by a parser does not establish source trust, instruction authority, user authorization, data-flow permission or action authorization.
Why keyword blocking and "sanitization" are incomplete
Sanitizing free-form language is not the same as neutralizing its meaning. Removing characters, delimiters or keywords can damage legitimate data while still missing paraphrases, other languages, indirect wording, multimodal content and later transformations such as summarization or OCR.
Content inspection is useful, but probabilistic
Input / Content Inspection and Prompt Injection Detection can reduce exposure, route suspicious content to restricted flows and produce evidence. Natural-language classifiers have false positives and false negatives.
A detector that flags content does not grant or deny permission by itself, and a detector that finds nothing must not grant permission either. The permission decision stays with authorization and flow policy.
Where allowlists work well
Allowlisting is strongest where the domain really is finite and structured: enum choices, resource IDs, operation names, approved tool names, destination classes and bounded numeric values.
Arbitrary natural language cannot be allowlisted without losing its business function. Keep free text as variable content and move decisions onto the structured values around it.
Structured tool arguments and schemas
A tool schema or JSON schema validates shape: required fields, types, formats, enums. It does not decide whether the requested action is permitted, whether a document is authoritative, or whether a destination is allowed.
Validate the proposed arguments first, then pass the resolved, typed action to Agent Authorization and flow policy.
The classic injection analogy: useful and limited
Classic injection and prompt injection both involve confusion between data and control at some layer. That shared intuition is helpful.
SQL parameterization works because SQL has a formal grammar: the application fixes the query structure and passes values separately, and the database parser enforces the distinction deterministically. Natural-language model context usually offers no equally deterministic, parser-enforced separation between "instruction" and "data".
Delimiters, labels and Spotlighting: robustness, not enforcement
Delimiters, XML-style tags, labels and Spotlighting / Data Marking can help a model distinguish data from instructions and can improve robustness.
They are still interpreted by the model. They are not deterministic trust boundaries and do not replace controls outside the model.
Provenance and source-of-truth rules
Data Provenance records where content came from and what happened to it. Source-of-truth rules decide which source is authoritative for a given purpose.
Neither follows from validity. A valid, relevant document can still be the wrong authority. Keep provenance and authority metadata application-owned, outside editable content.
Authorization and least privilege
Authorization asks whether this principal may perform this action on this resource with these parameters in the current state. It is deterministic and uses application-owned identity, tenant and ACLs, never text claims.
Least privilege limits what can go wrong when influence succeeds. Prompt injection risk depends on content influence, model influence, reachable data and capabilities, and whether deterministic application controls prevent impact.
Information Flow Control and destination policy
Information Flow Control asks whether data may flow from a source or classification to a sink or destination. A well-formed address or URL can still be a forbidden destination.
Output validation vs sink-specific encoding
Output Validation checks whether a proposed output conforms to the application or sink contract: structure, format, allowed values.
Sink-specific encoding, escaping and parameterization are a separate step. Used correctly at their sink, they prevent classes such as SQL, HTML or command injection. They do not turn untrusted language into trusted instructions, and model output remains variable data even when input passed validation and the model followed its instructions.
Comparing the controls
| Control | Question it answers | What it does not answer |
|---|---|---|
| Input validation | Is this value well-formed for this field? | Source authority, instruction authority or permission |
| Content inspection / detection | Does this content show suspicious instruction-like patterns? | Permission; it is a probabilistic signal |
| Provenance / source authority | Where did this content come from, what happened to it, and is it authoritative for this purpose? | Whether disclosure or action is permitted |
| Instruction hierarchy / framing | How should the model prioritize model-visible instructions? | Enforcement; it shapes model behavior only |
| Authorization / least privilege | May this principal perform this action on this resource with these parameters? | Whether content is true or authoritative |
| Information Flow Control | May this data flow from this source or classification to this sink? | Whether the action itself is authorized |
| Output validation | Does the proposed output conform to the sink or application contract? | Authorization or sink encoding |
| Encoding / escaping / parameterization | Is this value safely represented at this specific sink? | Whether the language is trusted or authoritative |
Synthetic examples
Ticket T-100 passes type and length validation. Alongside the normal description it contains an unrelated instruction-like sentence.
The ticket remains variable business content with no instruction authority; the support assistant's permissions do not cover the unrelated action, so nothing happens.
A well-formed message is accepted. Inspection flags one segment as instruction-like.
The flag is logged. Even if the detector had missed it, authorization would still block any out-of-scope action.
{ "action": "read", "resourceId": "case-B7" }Schema-valid, but the user has no access to case-B7. Rejected: shape is not authorization.
Model-generated free text passes the output schema for a summary field.
It is then HTML-escaped separately at render time: output validation is not sink encoding.
A highly relevant, well-formed document is retrievable, but the registry does not designate its source as the authority for this policy question.
It is not presented as official policy: validity and relevance are not authority.
Operation "export" and a limit of 50 pass the allowlist and range check. The destination example.test is not an approved destination class.
Destination policy rejects the flow: several independent gates, each with its own question.
A neutral request is written once in English and once in German with the same meaning. A word list built for one language matches only one of them.
Word matching is not a semantic boundary; decisions belong to controls that do not depend on wording.
Layered control pattern
Architecture checklist
- Validate every structured value: IDs, enums, ranges, formats, tool arguments
- Treat free text as variable content, however valid it is
- Use inspection and detection as signals, not permission
- Keep identity, tenant, ACLs and provenance outside model text
- Authorize each resolved action deterministically
- Apply Information Flow Control to destinations and sinks
- Validate outputs against the sink contract, then encode or parameterize at the sink
- Limit reachable data and capabilities with least privilege
This checklist is architecture guidance, not a requirement quoted from a standard.
Common misconceptions
Statements that do not hold
- "If the prompt passes validation, it is safe."
- "Stripping keywords removes the instruction."
- "The detector found nothing, so the action is allowed."
- "The tool call matches the schema, so it is permitted."
- "Delimiters make retrieved text unable to influence the model."
- "Escaping output makes it trustworthy."
- "Input validation is useless for AI applications."
Sources and practice
How this article uses sources
- OWASP
- LLM01:2026 Prompt Injection, Cheat Sheet Series - input validation context, injection prevention, query parameterization, XSS prevention
- NIST
- AI 100-2e2025 and glossary - indirect prompt injection terminology
- Microsoft
- Defend against indirect prompt injection attacks, Input, Context, and Retrieval Hygiene
The OWASP Cheat Sheets are cited for classic application security and sink-specific controls only, not as prompt injection guidance. The control comparison and checklist are architecture guidance.
Frequently asked questions
Should we still validate input?
Can a better filter solve prompt injection?
Is there a prepared statement for prompts?
Do delimiters or Spotlighting create a boundary?
Where do allowlists help?
Does output escaping replace authorization?
What is the most important takeaway?
References
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-26
- indirect prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceReviewed 2026-09-26
- Input, Context, and Retrieval HygieneMicrosoft Learn · GuidanceReviewed 2026-09-26
- Injection Prevention Cheat SheetOWASP Cheat Sheet Series · GuidanceReviewed 2026-09-26
- Query Parameterization Cheat SheetOWASP Cheat Sheet Series · GuidanceReviewed 2026-09-26
- Cross Site Scripting Prevention Cheat SheetOWASP Cheat Sheet Series · GuidanceReviewed 2026-09-26