Indirect prompt injection exposes the real AI security perimeter

At a glance

What this is: This is Lakera’s analysis of indirect prompt injection and the finding that poisoned inputs, not visible prompts, are the real attack surface for modern AI systems.

Why it matters: It matters because identity and access controls now have to govern what AI agents can read, retrieve, and execute across NHI, autonomous, and human workflows.

👉 Read Lakera’s analysis of indirect prompt injection in modern AI systems

Context

Indirect prompt injection is a context-level attack on AI systems. Instead of targeting the user prompt, the attacker hides instructions inside webpages, PDFs, emails, memory, code, or MCP metadata that the model later ingests during normal operation. That makes the AI security perimeter broader than the chat interface or model API.

The identity governance problem is that modern AI systems increasingly treat untrusted text as actionable input while also holding credentials, tool access, and execution rights. Once browsing, retrieval, or execution are connected to the same context window, a poisoned document can move from content to control.

Lakera’s framing is directionally right for practitioners: the risk is not a clever jailbreak, but a structural trust failure in how AI systems combine instructions and data. For teams governing NHI, agentic AI, and human-accessed workflows, the question is where text becomes authority and where that authority must stop.

Key questions

Q: How should security teams stop indirect prompt injection in AI systems?

A: Security teams should isolate untrusted content from the instruction channel, validate tool calls on the server side, and treat every ingestion source as part of the attack surface. The goal is not to make the model smarter about trust, but to prevent poisoned text from ever gaining authority over actions. Strong provenance controls matter more than better prompts.

Q: Why does indirect prompt injection create so much risk for AI agents?

A: Indirect prompt injection becomes dangerous when an AI agent can browse, retrieve, write, or execute, because a single poisoned input can lead to real-world actions. The agent turns hidden instructions into operational consequences. That is why the issue is architectural: the model is not only reading text, it is acting on it.

Q: What do teams get wrong about protecting AI systems from prompt injection?

A: Teams often focus on prompt wording while leaving ingestion, memory, and tool metadata untrusted. That misses the actual failure mode. The model will process anything in context as potentially meaningful, so the real control problem is how data enters the session, how it is labelled, and what actions it can trigger.

Q: Should organisations reduce agent autonomy to lower prompt injection risk?

A: Yes, where the use case allows it. Reducing autonomy limits how far a poisoned input can travel, especially if the system can browse, execute, or persist memory across sessions. For high-risk workflows, narrower tool permissions and stronger human approval gates can be the difference between a nuisance and an incident.

Technical breakdown

Why blended context makes indirect prompt injection work

Most AI applications assemble system instructions, user input, retrieved content, tool metadata, and memory into one token stream. The model does not reliably separate trusted instructions from hostile text, because it is optimised to follow language patterns rather than enforce security boundaries. That means hidden directives inside a PDF, web page, or tool description can be interpreted as part of the task. The failure is architectural: the model is asked to reason over data that has not been isolated from control signals.

Practical implication: separate retrieval from instruction-bearing channels before the model can act on the content.

Why agentic AI expands the blast radius of poisoned inputs

A passive summariser can be misled, but an agent that can browse, write, send, or execute turns mistaken interpretation into operational impact. Once tool use is connected to ingestion, even small injected instructions can trigger credential disclosure, unsafe queries, or unintended actions. The issue is not autonomy alone, but autonomy plus exposed action surfaces. This is why AI systems with execution rights need stronger validation than systems that only generate text.

Practical implication: restrict tool scope and validate every high-risk action before the agent can complete it.

Why MCP and other structured metadata channels are risky

Model Context Protocol and similar structured layers do not eliminate indirect prompt injection when the content they expose comes from untrusted sources. Tool descriptions, resource listings, and schema text can carry hidden steering language just as easily as a webpage can. Structured transport does not equal trusted content. If the model can read the metadata and use it to decide behaviour, the metadata itself becomes part of the attack surface.

Practical implication: treat protocol metadata as untrusted input and screen it at the boundary.

Threat narrative

Attacker objective: The attacker wants the AI system to convert untrusted text into action, enabling data leakage, control misuse, or unsafe execution without direct prompt access.

1. Entry occurs when an attacker plants hidden instructions in a webpage, PDF, email, memory entry, or tool description that a model will later ingest.
2. Credential or control access occurs when the model accepts the poisoned content as part of its working context and begins following the embedded instructions.
3. Escalation happens when the model uses connected browsing or tool access to leak data, alter output, or trigger harmful actions beyond the original document.
4. Impact is achieved when the AI system exposes secrets, performs unsafe operations, or propagates attacker-controlled instructions into downstream workflows.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Indirect prompt injection is a trust-boundary failure, not a prompt-tuning problem. The model is being asked to consume content that can be both information and instruction at the same time. That collapses the separation traditional security assumes between data and control, which is why prompt hardening alone does not hold. Practitioners should treat the ingestion pipeline as part of the security perimeter, not as a neutral pre-processing step.

Agentic behaviour turns hidden instructions into operational risk. A text-only model can be misled, but an agent that can browse, retrieve, write, or execute can turn one poisoned document into many downstream actions. This is where OWASP-NHI and OWASP-AGENTIC thinking intersect: the boundary problem starts in content handling and ends in execution authority. Practitioners need to re-evaluate how much real-world consequence they have attached to model outputs.

Context isolation is the named control gap this attack class exposes. The security assumption was designed for systems where instructions and data could be distinguished before execution. That assumption fails when the actor processes untrusted content in the same context window that drives tool use. The implication is not more prompt engineering, but a different operating model for trust and authority.

Protocols do not fix trust unless the inputs are governed. MCP, RAG, memory, and browsing expand the number of places where hidden instructions can enter the session. The category is moving toward AI systems that need identity-style control points around content provenance, action validation, and least-privilege execution. Practitioners should expect the AI security perimeter to sit around the environment, not the model.

Runtime validation will become the differentiator between exposure and containment. The organizations that fare better will be the ones that can prove what content entered the session, what actions were permitted, and which outputs were blocked. That is the practical shape of AI governance now: visibility into ingestion, authority, and execution, across both NHI and human-operated workflows.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The same research found that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• That speed gap is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains the right next step for teams tightening secret governance.

What this signals

Context isolation is becoming the new operating expectation for AI programmes. Teams that let browsing, retrieval, memory, and execution share one undifferentiated context are creating avoidable risk. As Lakera’s analysis shows, the weak point is not the model alone but the pipeline around it, which means governance now has to follow content as closely as it follows identity.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec, the next control conversation is no longer about whether AI can see data. It is about whether the organisation can prove that seeing data does not equal being authorised to act on it.

Runtime control points will define the next maturity step for AI governance. Organisations should be preparing for provenance checks, tool-call validation, and session-level trust boundaries to sit beside IAM and PAM controls. The teams that can separate read, reason, and act will be the ones that can scale AI without turning every ingestion surface into an attack path.

For practitioners

• Isolate untrusted content from instruction channels Split retrieval, browsing, and memory from the prompt context that authorises tool use. Tag content provenance before it enters the model session, and deny execution when the source is not trusted for that action.
• Validate every tool call against policy Require server-side checks for destination, scope, and data sensitivity before the model can send messages, fetch records, or run commands. Do not rely on the model to self-police risky actions.
• Treat MCP metadata as attack surface Scan tool descriptions, resource listings, and schema text as untrusted input. Block hidden directives, sanitize capability text, and enforce allowlists for what the model is allowed to invoke.
• Red team ingestion paths, not just prompts Test webpages, PDFs, email bodies, internal docs, and memory stores for hidden instructions that change model behaviour. Measure whether a poisoned source can influence output or trigger an action.

Key takeaways

• Indirect prompt injection succeeds because AI systems still blend trusted instructions and untrusted content in the same working context.
• The risk grows sharply once the model can browse, retrieve, write, or execute, because a poisoned input can become an actual action.
• Practitioners need trust boundaries, tool validation, and content provenance controls, not just better prompts or model tuning.

Key terms

• Indirect Prompt Injection: An attack in which malicious instructions are hidden inside content an AI system will later ingest. The model does not need a visible prompt attack to fail. It reads the poisoned content as context, then may treat it as instruction, which can redirect reasoning or trigger unsafe actions.
• Context Isolation: A design pattern that keeps instructions, retrieved data, memory, and tool metadata separate enough that untrusted content cannot steer execution. In AI systems, this means the model should not be able to turn arbitrary text into authority without checks outside the model itself.
• Tool-Call Validation: A runtime control that checks whether an AI system is allowed to perform a specific action before the action executes. It matters when a model can browse, send, retrieve, or run commands, because the model’s internal reasoning is not a security boundary.
• Content Provenance: The record of where content came from, how it was transformed, and whether it is trusted for a given use. For AI security, provenance helps distinguish source data from instruction-like text and gives governance teams a way to block unsafe inputs before they influence behaviour.

What's in the full article

Lakera's full article covers the operational detail this post intentionally leaves in the source:

• The Perplexity Comet incident breakdown, including the hidden-text technique and the one-time-password leakage path
• The MCP and Cursor examples that show how structured metadata can still carry attacker instructions
• The comparison between direct and indirect prompt injection in browser, RAG, and memory-driven workflows
• The research and red-team references that support runtime validation and context isolation as practical controls

👉 Lakera’s full post covers the Comet, MCP, and agentic AI examples in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.