What is Indirect Prompt Injection?
Updated: Sep 22
AI assistants are moving beyond chat. They can read files, search the web, retrieve organizational knowledge, connect to business systems, and increasingly take actions on a user’s behalf. That expands their usefulness—and their attack surface. One risk to understand is indirect prompt injection.
OWASP continues to list prompt injection among the major risks for LLM applications. Direct prompt injection places adversarial instructions directly in the user’s input to the LLM. Indirect prompt injection places adversarial instructions in external content the AI system is asked to process, such as webpages, emails, documents, retrieved records, or connected data sources. In both cases, the goal is to influence model behavior; what differs is how the instruction gets there.

First, an Important Correction
It is too absolute to assume that instructions inside a file or webpage will always be treated as data rather than commands. OpenAI describes prompt injection as a form of social engineering intended to get an AI system to do something the user did not request. Microsoft likewise warns that external content can contain instructions that influence model behavior. A better principle is:
Treat externally supplied content as untrusted input—even when AI is processing it as part of a legitimate task.
The Attack Chain Matters
Prompt injection is a real risk, but exploitation usually depends on several conditions lining up:
The AI encounters malicious content.
It processes that content as part of a legitimate task.
The user or agent can access sensitive data, tools, or systems.
The malicious instruction changes the model’s behavior.
The system can take an unintended action or send data elsewhere.
No permission, approval, monitoring, or other control stops it.
OpenAI describes this in terms of sources and sinks: untrusted input needs a capability that becomes dangerous if manipulated. Remove part of that chain and the risk changes.
Does Prompt Injection Bypass Permissions?
Not necessarily. Many scenarios involve the AI misusing information or capabilities the user or agent was already authorized to access, rather than breaking through an access-control system.
Microsoft has demonstrated scenarios where malicious content could attempt to influence an agent to retrieve information it was permitted to access and send it somewhere unintended. That is primarily a prompt-injection and data-egress problem.
Permissions still matter because they define what the AI can reach if manipulation succeeds.
This Is Not a One-Platform Problem
Prompt injection can affect any AI system that combines untrusted content with sensitive data, connectors, APIs, browser access, tools, or autonomous actions.
That includes enterprise copilots, research assistants, coding agents, customer-service agents, AI-enabled browsers, custom applications, and systems connected through MCP. The stakes rise as AI moves from answering to acting. The more tools an agent can invoke, the more important it becomes to control what it can access and what actions it can take.
Connectors and MCP Change the Stakes
Connectors make AI more useful, but they can also expand what it can read or do.
Security teams should ask:
What data can the connection expose?
What actions can the AI initiate?
Is access read-only or write-enabled?
What identity and permissions does it inherit?
Can it send information outside the organization?
Which actions require approval?
Who reviews third-party or custom connectors?
OpenAI specifically warns that unsafe or untrusted MCP servers can increase prompt-injection exposure, which makes connector vetting part of AI security.
What Should Organizations Do?
The answer is not simply to disable AI. Reduce the number of conditions an attacker needs to succeed. Apply least privilege, limit unnecessary connectors and tools, treat retrieved content as untrusted, require approval for consequential actions, separate read access from write or send capabilities where possible, monitor agent activity, and test with adversarial content.
OpenAI also recommends giving agents narrow, explicit instructions rather than broad authority. Microsoft similarly recommends treating AI output and retrieved content as potentially untrusted.
Prompt Injection Is the New Email Phishing
The comparison works because both problems require layered defenses. We did not eliminate phishing by eliminating email. We added filtering, access controls, monitoring, authentication, education, and response processes. Prompt injection is likely to require the same mindset.
Current guidance from OpenAI, Microsoft, and OWASP points toward layered controls: constrain access, limit autonomous actions, monitor behavior, validate outputs, and keep humans involved where consequences matter.
Use this Prompt: Act as an AI security reviewer. Review this proposed AI workflow for prompt-injection risk: [describe the workflow, including what the AI reads, what systems it can access, and what actions it can take]. Identify any untrusted content sources, sensitive data or tools the AI can reach, possible “sinks” where data could be exposed or actions could be taken, and the controls that should be added before use. Pay special attention to indirect prompt injection through webpages, files, emails, retrieved records, connectors, or MCP servers. Return the answer as a table with: risk point, why it matters, likely impact, and recommended safeguard.




Comments