Review scope and evidence labels
This page defines Prompt Injection as a security concept for hostile or conflicting instructions inserted into an AI system through user input, documents, retrieved context, tool output or other content channels.
Evidence labels used on this page:
- Community security guidance — based on public OWASP or similar security community material.
- Community security knowledge base — based on MITRE ATLAS or similar adversary-knowledge material.
- Official guidance — based on public official guidance such as NIST material.
- Author analysis — interpretation for AI security, architecture, governance and operational risk on this site.
- Implementation evidence required — local records that must exist before a mitigation can be treated as operating.
This entry is a public Research profile. It does not claim that prompt injection can be solved by a single filter or prompt template.
Concept snapshot
| Field | Value |
|---|---|
| Category | LLM application and instruction-boundary security |
| Research type | Concept |
| Core question | Can the application preserve trusted intent when untrusted content contains instructions? |
| Main scope | User prompts, system prompts, RAG documents, web pages, tool outputs, agents, logs and generated answers |
| Main risks | Policy bypass, data exfiltration, tool misuse, hidden instructions, retrieval poisoning and misleading answers |
| Companion methods | AI Threat Modeling, OWASP LLM Top 10, RAG Security, MITRE ATLAS, Zero Trust |
| Review status | Public guidance reviewed; real mitigation requires application-specific controls and tests |
What Prompt Injection means
Prompt injection happens when an LLM application treats untrusted text as if it were a trusted instruction channel. Evidence: Community security guidance; Author analysis.
It is especially important in systems that read external documents, browse websites, call tools, access internal data or run agentic workflows. In those systems, the instruction boundary is not only the chat box; it includes every source that can influence the model. Evidence: Community security guidance; Author analysis.
For this site, Prompt Injection is used as a practical test of whether AI Security Architecture, RAG Security and AI Threat Modeling are concrete enough to define trust boundaries and retained evidence. Evidence: Author analysis.
What it is not
Prompt Injection is not:
- only a funny jailbreak prompt,
- only a text-filtering problem,
- only a model-provider problem,
- solved by telling the model to ignore malicious instructions,
- proof that all LLM use is unsafe,
- a replacement for broader access control, logging and data minimization.
A safe design must assume that untrusted content can contain instructions and then limit what those instructions can influence. Evidence: Author analysis; Implementation evidence required.
Practical control questions
| Control area | Practical question | Evidence to retain |
|---|---|---|
| Trust boundaries | Which content sources are trusted instructions and which are untrusted data? | Architecture diagram, prompt/data classification |
| Retrieval | Can documents or chunks inject instructions into the model context? | RAG abuse tests, source review, chunk metadata |
| Tools | Can injected text trigger actions through plugins, APIs or agents? | Tool policy, allowlist, confirmation design |
| Data exposure | Can a prompt cause secrets or restricted context to be revealed? | Data-flow review, redaction tests, access checks |
| Output handling | Can generated output become executable code, HTML, SQL or workflow commands? | Output validation, escaping, sandbox records |
| Monitoring | Can suspicious instruction patterns be detected and investigated? | Logs, alert rules, review records |
Evidence: Community security guidance; Author analysis.
Relationship to existing Research entries
Prompt Injection connects to:
- OWASP Top 10 for LLM Applications — prompt injection is a core LLM application risk class.
- RAG Security — indirect prompt injection can enter through retrieved documents.
- AI Threat Modeling — scenarios should include user, document and tool-output abuse paths.
- AI Security Architecture — architecture must separate trusted instructions from untrusted content.
- MITRE ATLAS — adversary patterns can help describe abuse cases.
- Zero Trust — never treat model context as automatically trusted.
- Audit Evidence — mitigation claims need retained tests and logs.
Governance relevance
Prompt-injection risk is a governance issue because it can convert content ingestion into a control bypass. A system owner should be able to explain which content sources can influence decisions, which actions require confirmation and which logs prove the system behaved as intended. Evidence: Author analysis; Implementation evidence required.
Useful governance outputs include prompt/data classification, RAG source inventory, tool-use policy, abuse-case tests, exception records and residual-risk acceptance. Evidence: Author analysis.
Current limitations and follow-up research
This entry is a concept profile. Real assessment requires system-specific prompts, data sources, model provider, tool permissions, retrieval pipeline, action capabilities and logging design.
Follow-up Research nodes should cover:
- Agent Security,
- Tool-Use Security,
- Model Context Protocol security,
- Output Handling for AI applications,
- Evaluation and abuse-test design for LLM systems.