Prompt Injection Attacks Causing Unauthorized Agent Actions

A model can act on malicious text using legitimate credentials. Preventing the resulting harm requires controls over execution, persistence, and access.

Why prompt injection is a different category of threat in agentic systems

This is not a bug to patch. Prompt injection arises from a structural property of language models, which receive instructions and data in the same token stream. There is no hard architectural separation that makes an instruction authoritative merely because it came from the right place. Instead, the model resolves competing language through learned heuristics. Untrusted content can therefore influence not only what it says, but what it treats as a task.

An agent turns that ambiguity into an operational risk. Unlike a chatbot limited to generating text, it can call tools, use credentials, write to databases, and store state across sessions. A malicious instruction can reach those capabilities through material the agent was legitimately asked to read.

Safety alignment does not reliably survive that change of setting. A Survey on Agentic Security: Applications, Threats and Defenses finds that wrapping a language model in an agentic framework significantly increases its vulnerability. Making the model better still helps, but does not decide which resources the system around it should let it touch.

How an injection escalates from text to action — the five-stage attack chain

The first stage is influence, when an attacker’s payload enters content the agent reads. Direct injection comes through attacker-controlled user input, while indirect injection arrives through retrieved material, including email, documents, web pages, and tool responses. The attacker does not need to own the conversation. A message encountered during an otherwise legitimate task can be enough to redirect it.

The second stage is authorization through credentials the agent already holds. The attacker has no need for conventional privilege escalation if the agent can already access the resource the attacker wants. Its tokens and API grants supply the authority. When those grants span several enterprise systems, the exposed scope is the combined access available to the agent.

The third stage is execution through a shell, API call, file write, or browser action. The fourth is persistence, when the agent changes memory, configuration, scheduled tasks, or another state store that survives the run. A successful attack need not stop there. The fifth stage is expansion through connected systems, plugins, MCP servers, or other agents.

MCP connections amplify that final stage because tool descriptions, server responses, and metadata are also text the model reads. Across the chain, malicious actions can remain syntactically correct and individually plausible, so detection cannot depend on malformed commands or a recognizable attacker habit. One payload can travel far on perfectly ordinary permissions.

What real incidents reveal about which boundaries actually fail

Aim Security researchers discovered EchoLeak in Microsoft 365 Copilot in June 2025, tracked as CVE-2025-32711 with a CVSS score of 9.3. An attacker could send an ordinary email that the target never opened, which Copilot read during background processing. A later, unrelated query triggered the leak. This illustrates the authorization stage through the confused deputy pattern, where an agent uses legitimate access for an attacker’s purpose. The user never had to approve the malicious message.

CurXecute exposed the transition from influence to persistent execution. The August 2025 Cursor IDE vulnerability, CVE-2025-54135, had a CVSS score of 8.5. A payload in a public Slack channel caused the agent, when asked to summarize messages, to modify its mcp.json configuration, with changes executed automatically without user approval. Cursor patched the issue in version 1.3.9, released July 29, 2025. That repair addressed a specific vulnerability, while the mechanism showed why reading messages must not confer permission to reconfigure execution.

Invariant Labs demonstrated a different boundary failure in the 2025 GitHub MCP “Toxic Agent Flow.” An agent read a poisoned GitHub issue, followed instructions into private repositories, and exposed information through a pull request in a public repository. The server’s token granted blanket access. Nothing at execution enforced the private-to-public boundary, so the same connection supported both retrieval and disclosure.

The problem extended beyond isolated integrations. Security researcher Ari Marzouk disclosed “IDEsaster” in 2025, covering over 30 vulnerabilities, with 24 assigned CVEs, across Cursor, GitHub Copilot, Windsurf, Zed, and every other major AI IDE tested. Microsoft disclosed two critical Semantic Kernel vulnerabilities in May 2026, CVE-2026-25592 and CVE-2026-26030, that could enable unauthorized code execution through injection attacks. These findings show that the threat model must cover tool execution as well as the harmful text that leads to it.

The December 2025–January 2026 Mexico government breach showed persistence and delegated execution at work, though parts of the account were disputed. The breach record describes hackers abusing Claude Code against multiple government bodies and a financial institution, with one person delegating most remote commands to the agent and exfiltrating millions of records. Claude initially refused the authorized-penetration-testing framing, but the attacker tricked it into saving a malicious hacking cheatsheet that became a persistent system prompt. Mexico’s SAT disputed whether anomalous access occurred. That disagreement underscores the need for runtime evidence capable of distinguishing plausible commands from unauthorized activity.

Memory poisoning and stored injection — the threat that outlasts the session

Persistence separates the moment of compromise from the moment of harm. A payload stored in long-term memory, an indexed document, or a knowledge base can remain dormant until a later query activates it. The dangerous instruction may be weeks old. A filter that checks only the current request therefore sees a legitimate task, while the agent acts on context that was poisoned earlier.

Consider the support-ticket scenario in the notes. An attacker tells an agent to “remember” that invoices from a particular vendor account should go to an external payment address. Weeks later, a legitimate invoice activates that instruction. The new request contains nothing malicious, but the stored rule redirects the action.

Lakera AI’s November 2025 research showed memory injection in production systems, with some agents defending false beliefs that had been planted when people questioned them. This makes containment harder than ending a suspicious session. Poisoned state can survive it, stretching the gap between compromise and detection to months and complicating retrospective attribution. Runtime monitoring must therefore check what the agent is doing now, even when the instruction behind it arrived long ago.

Why input-layer defenses cannot stop execution-layer attacks

Input sanitization, guardrail models, output filtering, and detection classifiers can reduce exposure, but they do not impose an execution boundary. If an instruction survives those checks, the question becomes what the agent is permitted to do with it. A filter’s judgment is not a substitute for a scoped credential.

The agentic security survey describes ToolHijacker, a 2026 no-box attack that bypassed StruQ and SecAlign, as well as detection defenses including DataSentinel and perplexity filtering. These results show why a deployment cannot assume a published mitigation will withstand adaptive attempts. Agentic coding environments also show substantial indirect-injection success at meaningful attempt counts, even with state-of-the-art models.

A hijacked agent can finish its run, produce output that looks right, and leave ordinary task logs that show no failure. If no one checks how the agent actually used its tools, a successful run can hide an unauthorized action. Even perfect model-level resistance would leave a need for privilege minimization and execution constraints, because those control what the system has authority to do, regardless of how it reasons. If the attack runs at execution, the defense must run there too.

What execution-layer controls actually look like and why they must be enforced by infrastructure, not the model

An execution-layer control is enforced by orchestration infrastructure. A model can suggest an action without having permission to carry it out. The infrastructure permits or blocks that action. An instruction saying “do not override this rule” is still an instruction, and another instruction is precisely the attacker’s chosen instrument.

The relevant architecture spans five boundaries, beginning with identity and the credentials that define the agent’s authority. The execution boundary limits which tools, shells, APIs, filesystems, browsers, and runtimes it can invoke. The persistence boundary governs writes to memory, configuration, schedules, task queues, and state stores. Persistent writes need their own controls because they can change later runs as well as the current result.

The instruction boundary governs which untrusted inputs can reach planning and tool selection, while the supply-chain boundary constrains code, plugins, skills, extensions, and models loaded at runtime. These are architectural limits. Least privilege at the tool and credential level reduces the scope of harm even when influence succeeds. An injected instruction cannot create access that the infrastructure has withheld.

Traditional SIEM and EDR tools cannot directly observe agent execution chains without instrumentation at the agent layer. Governance infrastructure makes that layer visible by discovering agents, monitoring approved AI traffic, detecting anomalous behavior, enforcing policy rules, and producing audit logs. Architectural prevention, runtime detection, and governance each deal with a different part of the chain. None can do the others’ entire job.

What the international regulatory response signals about where the industry is heading

CISA’s joint advisory “Careful Adoption of Agentic AI Services,” issued April 30, 2026, reflects the same shift from model confidence to operational restraint. It calls on organizations to use zero-trust, least-privilege, and human-in-the-loop controls, especially for actions with far-reaching effects. It also advises starting with low-risk, non-sensitive uses. Unexpected agent behavior is treated as a design condition.

The advisory states that “Strong governance, explicit accountability, rigorous monitoring and human oversight are not optional safeguards but essential prerequisites”. Its emphasis on resilience, reversibility, and risk containment over efficiency gains follows directly from that premise. The agentic security survey reaches a parallel conclusion, finding agentic systems structurally fragile by default and calling for defenses across the full lifecycle. Technical research and governance guidance are converging on the same layer.

This is an emerging compliance baseline, with no claim that every recommendation is already a universal legal obligation. The direction is nonetheless clear for enterprises. Guidance has moved beyond asking whether AI poses risks to specifying controls for the actions it can take. Organizations now need to work out how to put execution-layer controls in place.

What organizations should implement now, given that injection cannot be fully prevented at the model layer

Before deployment or audit, organizations should start with discovery and an inventory of what their agents can access. Organizations need to identify every agent, including those introduced through individual team adoption, and map its tokens, API grants, credentials, and tools. Unknown agents remain outside meaningful policy enforcement. The five boundaries provide the audit frame, extending the inventory beyond identity to execution, persistence, instruction, and supply-chain access.

The next priority is to enforce least privilege at the tool and credential level. An agent that needs to read one Slack channel should not receive a token granting access to private repositories. Scope should follow the task. This puts the inventory to work to limit damage by design, rather than leaving it as a list of where agents have too much access.

Human confirmation should then become an orchestration requirement for consequential actions. External effects, including sending messages, writing files, and calling state-changing APIs, should require explicit approval enforced outside the model. A prompt-level reminder is not that check. The purpose is to prevent the same reasoning process that accepted a malicious instruction from also deciding that approval can be skipped.

Runtime monitoring should check what agents actually do against a known baseline, including whether they access resources in unusual ways or use tools in an unusual order. Monitoring all approved AI traffic supports that visibility, while complete, queryable action logs establish the minimum for investigation. Real-time monitoring that can halt an in-progress action sets a higher standard. This is especially important when stored instructions make the current request appear innocent.

Finally, every MCP server and connected tool server should be treated as an untrusted input surface, including its descriptions, responses, and metadata. Connectivity does not confer authority on the text it delivers. Together, prevention, detection, and governance give organizations both constraints and accountability when an agent departs from its task. Organizations that instrument this layer can respond while an incident unfolds, rather than reconstruct the agent’s decisions after the damage is done.