Direct injection vs indirect injection
Direct injection
The attacker provides instructions through user-controlled inputs like chat, form fields, API requests, aiming to bypass refusal behavior, uncover hidden context, alter tasks, or push the assistant beyond its intended function.
Indirect injection
The attacker injects instructions into the content that the model will come across at a later time, and a legitimate user activates the payload by requesting the assistant to search, summarize, analyze, retrieve, browse, or utilize a tool.
Both types capitalize on the same structural flaw: the interaction between trusted policies and untrusted content can impact a language model. The main distinction lies in the source. In a direct attack, the suspicious input and attacker are clearly identified during the active interaction. However, in an indirect attack, the payload could have been implanted days in advance by an individual who never interacts with the assistant.
| Dimension | Direct injection | Indirect injection | Security implication |
|---|---|---|---|
| Payload source | Current user input | Retrieved or processed content | Preserve source identity through the entire context pipeline |
| Typical trigger | User submits the attack text | Legitimate user asks the system to read affected content | Do not infer safety from normal user intent |
| Visibility | Often obvious in the transcript | It could be concealed, encrypted, visually obscured, or buried within lengthy material. | Inspect transformed content, metadata, OCR, and tool output |
| Attacker reach | Usually limited to what the caller can access | May run with the assistant’s or victim user’s permissions | Never let the model decide or expand authorization |
| Persistence | Often session-bound | Can persist in documents, indexes, memory, caches, and datasets | Support source quarantine, re-indexing, and memory cleanup |
| Primary controls | Input controls, role boundaries, refusal testing, rate limits | Provenance, retrieval isolation, least privilege, action approval | Combine behavioral defenses with deterministic enforcement |
What direct prompt injection looks like
A direct attacker intentionally formulates a request to rival higher-priority commands, with objectives such as obtaining limited output, exposing internal prompts, altering assigned roles, bypassing safety measures, or convincing an agent to utilize an unauthorized tool. While "jailbreaking" is a well-known example, direct injection encompasses a wider range of activities, including efforts to manipulate business regulations, compliance terms, routing protocols, and automation functions.
Direct attacks are limited in scope as the caller usually does not have access to resources beyond what the application already allows for that identity. However, this limitation can be removed if the application grants shared credentials, cross-tenant retrieval, or unrestricted tools to the attacker.
Direct-injection variants
- Instruction override: requests to disregard policy, alter roles, or consider low-trust input as valid.
- Prompt extraction: tries to uncover guidelines, inner workings, instances, or covert criteria.
- Refusal suppression: A fictional setup, encoding, or translation intended to undermine security measures.
- Task redirection: replacing a business meeting with a leisurely stroll
- Tool manipulation: causing invalid arguments, too many calls, unauthorized scopes, or unintended consequences.
What indirect prompt injection looks like
Indirect injection transforms regular data into a means of delivery. Malicious commands are hidden within content that the system could access, categorize, search, or transfer between applications. The harmful payload could take various forms such as plain text, small or encrypted text, tags, data about data, code notes, text extracted from an image, or a result from a different service.
The authorized user could be performing a variety of routine tasks such as summarizing an email, comparing vendor documents, reviewing a support ticket, browsing a website, or requesting a coding assistant to examine a repository. If the assistant reads the contaminated source, they may mistakenly view it as a new directive.
Common indirect-injection paths
- Documents and PDFs: policy files, résumés, reports, invoices, presentations, spreadsheets, and uploaded attachments.
- Web content: pages, search results, user remarks, organized data, obscured components, and information retrieved from connected sources.
- Communications: Email content, signatures, help desk tickets, chat messages, event details, and customer relationship management notes.
- Developer content: repositories, READMEs, issues, pull requests, code comments, package descriptions, logs, and errors.
- System state: vector indices, memory for the long haul, synopses, stored information, data points, findings from tools, and feedback from a different model or agent.
- Multimodal inputs: The multimodal model can detect text in images, screenshots, scanned files, audio transcripts, and visual instructions.
How an indirect attack propagates
- Plant: A hacker inserts a harmful command into a location where the target system could come across it.
- Ingest: A crawler, uploader, connector, indexer, OCR service, or tool is used to import data from that source.
- Retrieve: When a regular user makes a request, the system picks the tainted content as the appropriate context.
- Interpret: the model considers certain content as guidance rather than proof.
- Escalate: A privileged agent obtains extra information, modifies a strategy, utilizes a tool, or generates a risky outcome.
- Persist: The altered outcome could be saved to memory, a synopsis, a downstream system, or the context of another agent.
This chain illustrates the limitations of only scanning the initial user prompt, as risky content may appear after retrieval, within a tool response, or at a later stage in a multi-agent workflow.
Risk depends on capability, not only attack success
A model limited to drafting text poses less risk compared to one with the ability to access private repositories, send messages, edit records, run code, make payments, or interact with external services. The level of risk increases when four factors align: untrusted content is inputted into the model, the model can impact actions, there are broad credentials, and the workflow lacks independent validation or approval.
| Risk factor | Lower-risk design | Higher-risk design | Recommended boundary |
|---|---|---|---|
| Data access | User-scoped, minimal retrieval | Shared or cross-tenant access | Authorize before retrieval and filter by identity |
| Tools | Read-only, narrow functions | Broad write, code, network, or admin tools | Use typed interfaces and scoped credentials |
| Destinations | Approved internal resources | Arbitrary URLs, recipients, or storage | Apply destination allowlists and data-loss controls |
| Autonomy | One proposal, user confirms | Long autonomous loops with retries | Limit steps, tokens, time, spend, and side effects |
| Output use | Displayed as untrusted text | Executed or rendered without validation | Parse, encode, validate, and policy-check downstream use |
Controls for both injection types
Source provenance
Documenting the origin, edit permissions, ingestion date, and trustworthiness of each context item.
Context isolation
Precisely define unreliable evidence, eliminate extraneous material, and avoid allowing extracted text to alter policies or tools.
External authorization
Ensure that identity, tenant, resource, and action permissions are enforced in deterministic code prior to retrieval and execution.
Least-privilege tools
Limit access to specific operations using schemas, temporary credentials, predefined endpoints, limits, and controlled network connections.
Validation and approval
Consider model output as unreliable; verify inputs and seek approval for any external, harmful, or confidential tasks.
Monitoring and response
Track the origins of content, data retrieval, prompts, tool requests, approvals, outputs, and documentation to prevent contamination.
Controls that matter most for indirect injection
- Ensure that content is sanitized and normalized before indexing, while also accounting for the possibility that some malicious instructions may go undetected.
- Structurally separate instructions from evidence by including source labels, trust labels, and purpose constraints in the context.
- Obtain the necessary passages while excluding unauthorized content.
- Prevent retrieved text from choosing tools, modifying permissions, altering recipients, or adding random external destinations.
- Contain browsing, code execution, file processing, and external network calls within sandboxes with limited resources.
- Avoid allowing model-generated summaries and memory to be passively accepted as authoritative instructions during subsequent interactions.
A secure execution pattern for RAG and agents
- Authenticate the request. Preserve user, tenant, service, and session identity through every step.
- Authorize retrieval. Filter sources before search results enter model context.
- Assemble minimal context. Include only necessary passages with provenance and trust labels.
- Let the model propose. Request a reply or a written plan of action without granting direct authorization for implementation.
- Validate independently. Implement schemas, policies, ownership rules, destination restrictions, data classification, and rate limits separately from the model.
- Approve by impact. User or reviewer confirmation is required for sensitive disclosure, external communication, financial activity, deletion, or permission changes.
- Execute narrowly. Utilize a service tailored for the specific operation and short-term credentials with minimal access.
- Audit and contain. Document the lineage from source to action and provide support for cancellation, rollback, revocation, quarantine, and re
How to test injection resilience
Evaluate the full application, including advanced features such as adversarial prompts, poisoned content, manipulated outputs, cross-language variations, distractions, multimodal inputs, and complex agent scenarios.
- User text cannot directly override tenant boundaries, retrieval permissions, or tool authorization.
- Content from documents, webpages, images, email, code, or tool output containing instructions is considered untrusted.
- A model is unable to include tools, scopes, recipients, resources, or network destinations within its own execution context.
- Harmful content is unable to trigger the release of sensitive information or prompt any actions without proper verification and approval.
- The model output must undergo validation before being used as executable code, unsafe markup, a query, or tool arguments.
- Injected text cannot linger as reliable data or influence subsequent entities without identifiable origin.
- Security operators have the ability to identify the origin, impacted index entries, alerts, tool activations, data modifications, users, and results.
Measure more than attack success rate
Monitor if the system complied with the injected instruction, accessed unauthorized information, proposed unsafe actions, was blocked by policy, requested approval, and was detected during the incident. A defense can still be beneficial even if the model is altered, as long as deterministic controls prevent significant harm.
Frequently asked questions
What is direct prompt injection?
Prompt injection happens when a user deliberately inserts commands into their input to bypass system rules, circumvent safeguards, expose restricted data, or manipulate the model to behave in ways not intended by the application.
What is indirect prompt injection?
Indirect prompt injection happens when malicious commands are hidden within content that the model will read later, like a document, webpage, email, PDF, code comment, database record, tool response, or memory item.
What makes indirect prompt injection particularly risky for RAG and AI agents?
To compromise the system, the attacker could poison a source accessed by the system, allowing the payload to execute within a legitimate user's request and potentially manipulate a privileged assistant with access to sensitive information or powerful resources.
Which controls reduce prompt-injection risk?
Employ provenance and trust labels, limited retrieval, context isolation, scoped credentials, deterministic authorization, typed tool interfaces, output validation, destination allowlists, human approval for significant actions, monitoring, and adversarial testing.
Authoritative guidance
This article’s risk model and defense-in-depth guidance align with the OWASP Top 10 for LLMs and Generative AI ApplicationsGovernance and lifecycle practices are influenced by issues such as prompt injection, inadequate output handling, excessive agency, sensitive information disclosure, and weaknesses in vectors or embeddings. NIST AI Risk Management Framework: Generative AI Profile.