Prompt Injection Risks in Production Enterprise Agents

How Direct and Indirect Injection Differ, and Why Indirect Is the Harder Enterprise Problem

Direct injection is the version most people picture first. An attacker controls the input, overrides instructions, reassigns the model's role, or exploits delimiter confusion to make the system abandon its policy mid-conversation. The signal is at least theoretically visible: the attacker has to be the user, present in the session, doing something detectable.

Indirect injection removes that requirement entirely, and the threat model shifts in ways that most security teams are still catching up to.

The attacker needs no account or session. They control content the agent retrieves, not the input itself. Documents, emails, web pages, database records: any external material the agent reads can carry a hidden instruction the model executes because it arrived in the context window alongside everything else. A poisoned email footer instructs a summarization agent to forward confidential messages outbound. Invisible text sits white-on-white in an HTML comment. A GitHub README carries an injected instruction that a code agent processes before deciding which package to install. The only requirement is placing content somewhere the retriever will rank highly.

I keep coming back to this when I talk to security architects: the system treats retrieved context as trusted because it came from the knowledge base. But retrieved context and untrusted user input both collapse into the same context window. There is no privileged position for retrieved content. Trust is an assumption baked into the architecture, not a property the model can verify at inference time.

For enterprises processing non-textual data, including scanned documents and healthcare imaging, multimodal injection via image-based prompts opens an additional surface that text-only filters cannot reach. The content type changes. The structural flaw does not.

What Production Incidents Reveal About Real Blast Radius

The production record over the past two years is unambiguous about what this structural flaw costs, and the incidents are worth sitting with rather than just cataloging.

EchoLeak, disclosed in June 2025 with a CVSS score of 9.3, was the first documented zero-click exploit against a production AI system. A single crafted email achieved remote, unauthenticated data exfiltration from Microsoft 365 Copilot by chaining classifier evasion, Markdown link redaction bypass, auto-fetched images, and a Teams proxy the content security policy permitted. No user interaction required. One email, and the data was already out.

GitHub Copilot earned a CVSS score of 9.6 for a vulnerability in which injection embedded in public repository code comments instructed the agent to modify settings enabling code execution without user approval. The path from untrusted text to arbitrary code execution on developer machines was short and direct.

Slack AI in 2024 demonstrated data exfiltration via injected content in channels the agent had access to. A ChatGPT memory manipulation attack the same year showed something that gets overlooked: damage is not always confined to a single session. Persistence across sessions is achievable through the same mechanism. OpenClaw, serving over 15,000 enterprises, disclosed critical flaws allowing data exfiltration and unauthorized system access via injected prompts.

The Snyk ToxicSkills research is the one that should unsettle people the most. An audit of a public AI agent skills registry found that 36% of skills contained security flaws, with 1,467 malicious payloads identified. Nearly 3% of skills used remote instruction loading via curl-piped execution specifically to evade static analysis. That is supply-chain injection at the skills layer. Teams consuming unvetted agent capabilities because they were available and convenient, and the convenience itself being the attack vector.

What these incidents share is not a missing filter. The exploited surface is always the boundary between trusted agent context and untrusted external content. The same architectural flaw, every time, in different clothes.

Why Agentic Tool Calls and Multi-Agent Chains Multiply the Consequences of a Single Injection

In a standalone model, a successful injection changes what the model says. In an agentic system, it changes what the model does: sends emails, executes queries, calls APIs, modifies files. That gap in blast radius is not a small distinction.

Research cited by Obsidian Security in 2025 found that AI agents move sixteen times more data than human users. A compromised agent is not a single-user incident. It is a high-magnitude exposure event across every data source the agent can reach, all at once.

Security testing of agent frameworks found that roughly 40% contain exploitable prompt injection flaws in tool-execution logic, and that tool misuse via injection triggers unauthorized actions in close to a third of evaluated scenarios. These findings come from production-representative configurations, not contrived adversarial labs.

Multi-agent architectures compound this further in a specific way that I think most teams underestimate until they've watched it happen. Research tracking multi-stage attacks found that attacks propagated to nearly half of co-running agents during a single injection incident. Lateral movement across agent chains went from essentially no documented incidents in 2023 to a substantial fraction of tracked multi-stage attacks by 2025 and 2026. Multi-hop indirect attacks via agents and tools increased by over 70% year-over-year.

Here's the structural character of the chaining problem that makes it so difficult: in an orchestrator-subagent architecture, a poisoned instruction passed from one agent to the next is indistinguishable from a legitimate task. No agent in the chain has a vantage point from which to detect it. The malicious instruction simply looks like work.

RAG pipelines are the mechanism that feeds external content into this chain at scale, which is why they warrant their own examination.

How RAG Pipelines Create a Specific and Underappreciated Injection Surface

RAG pipelines embody a trust paradox that most enterprises haven't fully confronted, and I say that without hedging because I've watched it surface repeatedly in production deployments.

User queries are treated as untrusted input. Retrieved context from the knowledge base is implicitly trusted. Both enter the same context window, and once they arrive, there is no architectural distinction between them.

PoisonedRAG, published at USENIX Security 2025, demonstrated a 90% attack success rate when injecting just five malicious texts per query target. The attacker needs no access to the model or the system prompt; they need only to place a document somewhere the retriever ranks highly. A shared drive, an intranet wiki, a connected SaaS document. Five documents. That's the entire attack surface requirement.

Enterprise RAG deployments make this worse because production pipelines typically pull from many sources simultaneously: email, CRM, code repositories, document stores. The poisoning surface scales directly with the number of connected sources. Every new integration is a new avenue for attacker-controlled content to enter the context window under the implicit imprimatur of trusted retrieval.

The structural fix is to treat retrieved content with the same skepticism as user input, and to enforce access controls at retrieval time so the agent never fetches documents the requesting user isn't authorized to see. If retrieval respects the permissions of the requesting principal, a poisoned document in a restricted folder cannot reach an agent operating on behalf of a lower-privilege user. The access control does not prevent the malicious document from existing. It prevents it from entering a context window where it can do anything.

What Attack Success Rates Say About the Limits of Detection-Only Defenses

The numbers on detection efficacy are sobering for anyone whose security posture depends primarily on filtering, and the math is worth doing explicitly.

Anthropic's Claude Opus 4.5 system card, using Gray Swan Shade methodology on agentic coding tasks, found indirect injection success rates of 4.7% on a single attempt, 33.6% at ten attempts, and 63% at one hundred attempts. Automated attackers operate at scale. Those attempt counts are not hypothetical.

Against Google Gemini in 2025, the most effective attack technique succeeded 53.6% of the time after applying best defenses including adversarial fine-tuning. Pillar Security findings cited by Vectra AI indicate that over 60% of prompt injection attempts succeed at least partially in real-world enterprise testing, with 90% of successful attacks resulting in sensitive data leakage.

A system receiving thousands of agent invocations per day does not need a high attack rate to accumulate significant damage. It needs only for the attack to work often enough that the expected frequency of success exceeds the organization's tolerance for exposure. Classifiers and output filters reduce surface area; they cannot close it.

This reframes the engineering question entirely, and I think it's where a lot of teams are still stuck in an outdated frame. If detection fails roughly half the time even on well-defended systems, the correct design assumption is that some injections will succeed, and the question becomes: given a successful injection, what can it actually reach?

That is what motivates least-privilege architecture and blast-radius reduction, not as supplements to detection but as the primary structural bet.

Architectural and Governance Controls That Reduce What a Successful Injection Can Do

Least-privilege tool access is the most direct structural response to the detection problem. Agents should hold only the permissions required for their specific task at the moment of execution. An email-summarization agent should not have send access. A read-only reporting agent should not have write access to any data store. Permissions that do not exist cannot be abused; that logic is simple but surprisingly underimplemented in production.

Permission inheritance at retrieval time is the specific application of least privilege to RAG pipelines. When an agent retrieves content on a user's behalf, it should surface only documents that user already has access to. Poisoned content in a restricted location cannot reach an agent operating for a lower-privilege principal.

Human-in-the-loop gates for high-risk actions are explicitly recommended by OWASP 2025. The injection can still reach the model; it cannot complete an irreversible action — sending email, executing code, modifying records — without human approval. This is a blast-radius control, not a detection mechanism, and the distinction matters. The model is not trusted to be the last line of defense on consequential operations.

Scoped agent boundaries in multi-agent chains address lateral movement directly. Each agent in a chain should operate within a defined permission scope. Orchestrators should not automatically propagate the full permission set of the requesting user to every downstream subagent. Lateral movement via injection requires traversable permissions; scoped boundaries constrain traversal, and that constraint is architectural rather than inferential.

Skill and agent versioning with a governed registry is how teams maintain visibility into what their agents actually do. Without a registry, a modified or malicious skill propagates silently to every team consuming it. With a versioned registry, an incident investigation can identify exactly which skill version was running, which tools it held, and who authorized the deployment.

Adversarial testing as a continuous practice, not a launch-time checkpoint, follows directly from the attempt-count data. Attack success rates rise steeply with repeated attempts. A system that passed a red-team exercise at launch faces a different risk profile after new tools, new data sources, and new prompt patterns have been introduced. Testing production agents against current techniques is maintenance, not milestone.

Output channel controls belong in the architectural perimeter alongside input controls. EchoLeak's exploit chain included a Teams proxy the content security policy permitted. The exfiltration path was an output channel the model was allowed to use. Constraints on what an agent can fetch or render are part of the blast-radius architecture.

How the Governance Layer Connects Individual Mitigations into a Defensible System

Each of these controls reduces blast radius in isolation. Their compounded value comes from sharing a consistent, enforced model of who can call which agent, with which tools, on whose data. Without that shared model, you have a collection of independent controls; with it, you have something you can actually reason about under adversarial conditions.

Prompt injection maps across at least seven major compliance and risk frameworks: OWASP, MITRE ATLAS, NIST, the EU AI Act, ISO 42001, GDPR, and NIS2. For regulated enterprises deploying production agents, governance documentation is not optional. The critical distinction is whether that documentation describes the actual runtime behavior of the system or only the intended behavior. Most enterprises currently fail at that distinction, and the gap is where incidents live.

Policies that exist only in documentation do not constrain agent behavior at runtime. Access controls and permission inheritance do. The Snyk ToxicSkills finding illustrates the cost plainly: teams consuming skills with a 36% security flaw rate because those skills were available and convenient, rather than because they had been reviewed. Convenience without governance is an attack surface with good UX.

A governed registry with access scoping does two things simultaneously. It limits what any agent skill can reach at the moment of execution. And it makes incident investigation tractable, because the registry captures exactly which version of which skill was running, which tools it had authorized access to, and who approved the deployment. Without that record, investigation is reconstruction from fragments. With it, it is repeatable process.

Prompt injection will remain a durable attack class because the structural condition enabling it — one context window with no native privilege separation — is inherent to current LLM architecture and will not be resolved at the model level anytime soon. The mitigations that hold are the ones that stop waiting for the model to solve the problem it was never designed to solve: access controls at retrieval, scoped permissions at execution, human gates at consequence, versioned governance at the skill layer. That is the system you can actually build, and building it is the only move that ages well.