An employee asks an AI agent to analyze a document. Hidden inside that content is an instruction written for the agent rather than the user.
The instruction might tell the agent to disregard its original task, retrieve sensitive information, launch another application, or send data to an external destination. If the agent treats that instruction as an authoritative command, an ordinary business workflow becomes a new attack vector.
This is indirect prompt injection.
Unlike a direct attack, the threat actor does not need to interact with the AI system or enter a malicious prompt into its interface. They place instructions somewhere the agent may encounter later and wait for the system to process them.
What is a prompt injection attack?
A prompt injection attack occurs when an attacker uses deceptive instructions to manipulate a large language model (LLM) into departing from its intended task or rules.
LLM applications can receive natural-language content from several sources:
- System instructions established by the developer
- Prompts submitted by users
- Emails, webpages, and documents retrieved for context
- Data returned by applications, APIs, and plugins
- Information stored in knowledge bases or agent memory
The security challenge is that instructions and data can both arrive as natural language. An LLM must determine which content represents an authoritative command and which content it should simply analyze.
Attackers exploit that ambiguity by making untrusted data resemble a valid instruction.
Prompt injection attacks generally fall into two categories:
- Direct prompt injection: The attacker enters a malicious instruction directly into an AI application.
- Indirect prompt injection: The attacker embeds instructions in external data that an AI system later retrieves or processes.
With indirect prompt injection, the person using the agent may never see the malicious content. The attack can take place in the background as part of an otherwise legitimate workflow.
How does indirect prompt injection work?
Consider an AI agent used to review incoming vendor emails and summarize any required actions.
An attacker sends a legitimate-looking message containing a concealed instruction intended for the agent. That instruction tells the agent to search the inbox for financial information and send the results to an external address.
When the employee asks the agent to review the email, the system processes both the legitimate message and the concealed instruction. If the LLM treats the injected prompt as authoritative, it may attempt to use its email, search, or storage tools to complete the attacker’s request.
No malicious executable necessarily needs to be installed. The attacker is trying to misuse the applications, permissions, and integrations already available to the agent.
The outcome depends on what that agent can access and what actions it can take. A summarizer with read-only access might generate a manipulated response. The same agent connected to corporate storage, outbound email, scripting tools, and business databases could expose sensitive data or make unauthorized changes.
Prompt injection creates the manipulated decision. Excessive permissions and autonomy determine how much damage that decision can cause.
Where attackers can hide indirect prompts
Any external source that becomes part of an agent’s context should be considered a possible prompt injection vector. These sources may include:
- Emails and attachments
- Webpages and online forums
- PDFs, spreadsheets, and shared documents
- Source code and repository comments
- Support tickets and customer forms
- Calendar invitations
- SaaS records and API responses
- Retrieval-augmented generation knowledge bases
- Images and other multimodal content
- Information retained in agent memory
Malicious instructions do not always resemble an obvious attack. Defenders cannot rely on blocking phrases such as “ignore previous instructions.”
Attackers can rephrase or encode commands, split them across several pieces of content, imitate system-message formatting, use alternative languages, or hide instructions in images. A prompt may also remain dormant until a specific event, word, or condition activates it.
This variety makes prompt injection difficult to address through content filtering alone. Security teams cannot realistically predict every possible combination of language that may influence an LLM.
Why prompt injection is difficult to prevent
Traditional applications can often separate commands from user-supplied data through clearly defined syntax and data types. LLMs work differently. They are designed to interpret flexible natural-language input, including instructions, questions, documents, and retrieved context.
That flexibility is what makes generative AI useful, but it also creates uncertainty over which text the model should follow.
Stronger system prompts, input validation, and injection detection can make attacks more difficult. None should be treated as a complete security boundary. Attackers can change their wording, combine multiple techniques, or place instructions in formats a filter does not recognize.
Organizations should therefore plan for the possibility that a malicious instruction will eventually reach the model and influence its output.
The defensive question must extend beyond “Can we detect malicious prompts?” Security teams must also ask, “What can the agent do if a malicious prompt succeeds?”
What can a prompt injection attack achieve?
A successful prompt injection should not automatically give an attacker unlimited control. Its impact is determined by the capabilities available to the affected agent.
Possible outcomes include:
- Retrieving confidential customer, employee, or financial information
- Exposing system prompts, credentials, or internal conversations
- Sending unauthorized emails or publishing attacker-controlled content
- Directing users to a phishing or malware-hosting website
- Manipulating recommendations, summaries, and business decisions
- Launching scripts or other applications outside the intended workflow
- Modifying records, files, configurations, or permissions
- Transmitting sensitive information to an unapproved destination
These outcomes show why prompt injection is not only a problem with AI-generated text. Once an LLM is connected to tools and business systems, model manipulation becomes an access, execution, data security, and containment problem.
How to reduce prompt injection risk
Because no single control can eliminate prompt injection, organizations need layers that reduce both the likelihood of manipulation and its potential impact.
Treat external content as untrusted
Emails, documents, webpages, tool responses, and retrieved data should not become authoritative simply because an agent can access them. Separate external content from system instructions wherever the application architecture allows it.
An agent processing content from an unknown source should not retain unrestricted access to privileged tools.
Apply least privilege
Give each agent its own identity and only the access required for its defined task. Separate read, write, modify, and delete rights instead of granting a broad connection through an employee or administrator account.
An IT support agent may need to review and categorize service tickets, but that should not automatically apply to permissions like resetting administrator passwords or modifying security policies.
Apply least agency
Least privilege limits what an agent can reach. Least agency limits how freely it can act with that access.
Require meaningful human approval before an agent sends external messages, exports sensitive information, installs software, changes permissions, deletes records, or modifies production systems. Approval requests should clearly state the proposed action, target, and expected consequence.
Restrict tools and integrations
Every plugin, API, browser, shell, and connector expands what an attacker may be able to influence. Remove integrations that do not support the agent’s purpose and expose narrow functions rather than general-purpose tools whenever possible.
Enforce policy outside the model
Do not depend entirely on the LLM to decide whether its own proposed action is safe. Use deterministic controls to validate destinations, commands, file paths, data access, and privilege requests.
The model may propose an unsafe action. The surrounding environment should decide whether that action is allowed to occur.
Monitor the entire workflow
Logging should cover retrieved content, model output, tool calls, API activity, network connections, approval decisions, and failed attempts. Repeated efforts to access unauthorized files or destinations can reveal an attempted injection before it succeeds.
How ThreatLocker limits the impact of prompt injection
ThreatLocker helps organizations enforce Zero Trust boundaries around AI agents, even when malicious content influences the model.
Application Allowlisting controls which AI tools, scripts, executables, and child processes can run while Ringfencing™ limits what those approved applications can access, which other applications they can invoke, and where they can communicate.
Data Storage Access Control restricts the files and storage locations available to an agent. Privileged Access Management removes standing administrative rights and controls when elevation is permitted.
Zero Trust Endpoint Firewall limits network communication to approved destinations, while Zero Trust Cloud Access helps restrict cloud and SaaS access to trusted devices. Web Content Control can govern access to public AI tools and unauthorized online resources.
The end goal is an agent whose access, tools, privileges, and autonomy remain within an explicitly defined boundary. This allows the user to maintain productivity without unknowingly inviting risk into the environment.
FAQs
What is a prompt injection attack?
A prompt injection attack is when an attacker hides deceptive or malicious messaging to manipulate an LLM (large language model) into deviating from its intended instructions.
What’s the difference between a direct and indirect prompt injection?
In a direct prompt injection attack, the attacker enters the malicious instructions directly into an AI application. In an indirect prompt injection attack, the attack embeds the instructions in external data that the AI later reads and processes.
Where are indirect prompts hidden?
Indirect prompts can be hidden in emails, attachments, PDFs, customer support tickets, forms, calendar invites, multimedia content, and more.
How can security teams prevent prompt injection attacks?
Security teams need a layered approach to prevent prompt injection attacks. This includes:
- Deny-by-default Allowlisting policies that prevent unknown tools, scripts, or child processes from running
- Containment policies that control how trusted applications can behave and interact with one another
- Storage control and Privileged Access Management that limits administrator rights, elevation, and the ability for agents to access sensitive data
- Restrict agent access to SaaS applications
- Policies that restrict access to unauthorized AI tools and online resources
