Yes, someone can hijack your AI agent through the data it reads, without you clicking anything, and it has already happened to a shipped, widely used product. In June 2025, researchers at Aim Security disclosed EchoLeak (CVE-2025-32711), a zero-click prompt injection against Microsoft 365 Copilot: an attacker sent a normal-looking email with a hidden instruction inside it, and the next time anyone asked Copilot an unrelated question, it silently leaked internal company data. No attachment opened, no link clicked, no warning shown. This is not a rare edge case. OWASP, the standard-setting nonprofit for application security, ranks prompt injection the number one risk for LLM applications for the second edition running, and a 2026 survey of 750 technology leaders found 54% of organizations had already experienced or suspected an AI agent security incident in the past year. This article explains exactly how the attack works, in plain terms, and what to actually check before you trust an agent with real access to your systems.

If you want a second opinion on how a specific agent is protected against this, see how we approach responsible AI governance and risk. Everything below is the reasoning we use ourselves, free to apply.

What is prompt injection, exactly?

Prompt injection is an attack that exploits a basic limitation of how AI models process text: everything the model reads, your instructions, a document it was asked to summarize, an email in its inbox, a search result it retrieved, arrives as the same kind of input, plain language in a stream of tokens. The model has no built-in, foolproof way to tell "this is a command from my owner" apart from "this is data I was asked to process." An attacker exploits that gap by hiding an instruction inside content the agent will read, so the agent follows it as if it were a legitimate command.

There are two versions. Direct prompt injection is when an attacker types the malicious instruction straight into a chat with the AI, "ignore your previous instructions and do X," which is the easier version to catch because it is visible and often looks obviously out of place. Indirect prompt injection is the dangerous one: the instruction is hidden inside content the agent reads as part of its normal job, an email, a webpage, a shared document, a customer support ticket, a calendar invite, and the agent never sees anything that looks like an attack, only a task it was already going to do. OWASP's own guidance describes indirect injection as the most actively exploited pattern in production agents today, and its newer framework for agentic applications found that prompt injection touches six of its ten top risk categories, because a single injected instruction can cascade into data leakage, unauthorized tool use, and actions well outside what the agent was supposed to do.

How did a real attack actually work, step by step?

The EchoLeak case is worth walking through in detail because it is not a lab demo, it is a documented, CVSS-scored (9.3) vulnerability that fully worked against a mainstream enterprise product.

  1. The attacker sends a normal-looking email. Inside it, hidden as an HTML comment or rendered as white text on a white background, invisible to a human reading the email, sits a malicious instruction.
  2. Nothing happens yet. The email sits in the inbox like any other. No one clicked anything, no attachment was opened.
  3. A user later asks Copilot an unrelated question. For example, "summarize my recent updates." Copilot's retrieval system automatically pulls relevant recent content into its context to answer, which includes the planted email, because the system has no way to know that email was booby-trapped.
  4. The hidden instruction executes as if it were a legitimate command. Copilot treats the invisible text as part of what it was asked to do, and the exploit chained several additional bypasses (evading Microsoft's built-in cross-prompt-injection classifier, working around link redaction, exploiting how the assistant auto-fetches images, and abusing an allowed internal proxy) to quietly exfiltrate sensitive internal data.
  5. The user sees nothing. No warning, no confirmation prompt, no sign anything unusual happened.

Microsoft has since shipped a server-side patch for this specific vulnerability. The point of walking through it is not that this exact exploit still works, it is that the underlying attack class, hiding an instruction inside routine content an agent will read, worked completely against a major, well-resourced product, with zero user interaction required. Any AI agent that reads emails, web pages, documents, or tickets on your behalf faces the same category of risk.

How often does this actually happen to real companies?

More often than most buyers assume, and the trend is toward more deliberate attacks, not fewer. A 2026 survey of 750 senior technology leaders (CIOs, CTOs, VPs of Engineering) across the UK and US found 54% of organizations had experienced or suspected an AI agent security or data-privacy incident in the past 12 months, with 34.9% confirming an incident definitely occurred. Telecom (67.3%) and financial services (54.7%) reported the highest rates. The same research specifically flagged prompt injection as the fastest-growing threat pattern, describing a shift from mostly accidental misuse toward deliberate, adversarial exploitation as "the most significant change" between its two most recent survey waves.

Prompt injection has also proven to be more than a data-leakage risk. Microsoft's own security research team disclosed, in May 2026, two vulnerabilities in their widely used Semantic Kernel agent framework (over 27,000 GitHub stars) where a successfully injected instruction chained into full remote code execution on the host machine, not just leaked text, but an attacker running arbitrary code. One flaw let an attacker turn a normal data lookup into executable Python by closing a quote and appending malicious code through unsafely handled input. The other abused a file-download function accidentally exposed to the model to escape an isolated sandbox entirely. Microsoft noted similar categories of issues exist in other major agent frameworks too.

Can't a content filter just catch these hidden instructions?

Not reliably, and this is the part most buyers do not expect. A 2026 meta-analysis synthesizing 78 separate studies on prompt injection against agentic systems found that when researchers used adaptive attack strategies, meaning the attacker adjusts based on what gets blocked rather than trying the same fixed trick every time, all 12 defenses they evaluated were bypassed more than 78% of the time, with most exceeding 85%. The same research found 73% of tested agent platforms failed to properly enforce even one basic trust boundary, the separation between what a user is allowed to instruct, what the agent's tools are allowed to do, and what one tool's output is allowed to influence.

The same study rated specific real tools by risk, and the pattern is instructive. Cursor was rated "Critical," driven by auto-approve behavior, unsandboxed connections to external tools, and no controls on outbound network traffic. Codex CLI was rated "High." GitHub Copilot had an actual assigned vulnerability (CVE-2025-53773) where an attacker could poison configuration to make subsequent tool calls auto-approve without asking the user. Claude Code, by contrast, was rated "Low," attributed specifically to requiring confirmation before tool use, having no auto-approve setting, and sandboxing external connections by default. The difference between "Critical" and "Low" in that comparison was not the underlying model, it was how much the surrounding system trusted the agent to act without a check.

What actually stops a successful prompt injection from causing real damage?

Since no filter catches every attempt, the practical answer is containment: assume some injected instructions will get through occasionally, and make sure that when one does, the damage is small and recoverable. A few concrete practices do most of the work:

  • Treat everything an agent reads as untrusted content, not commands. Design the system so retrieved documents, emails, and web pages are clearly separated from instructions, the way a well-built application never lets user-submitted text execute as code.
  • Give the agent the least access it needs, and nothing more. If an injected instruction tricks the agent, the blast radius is capped by what the agent could ever reach in the first place, not by whether the trick was caught.
  • Require human approval for anything irreversible, sensitive, or high-value. A refund, a data export, an external email, a permission change, these should always pause for a person, regardless of how convincing the instruction looked.
  • Sandbox the agent and limit its outbound network access. This is the control that actually stopped real attacks in documented cases: even a tricked agent cannot exfiltrate data it has no network path to send anywhere.
  • Log every action so an incident is discoverable, not invisible. EchoLeak's most alarming property was that the user saw nothing; monitoring and audit trails are what catch what a human in the moment cannot.

How is this different from a phishing email or a normal hack?

Traditional phishing tries to trick a person into clicking something or handing over a password. Prompt injection skips the person entirely and targets the AI system reading the content on that person's behalf. That is what makes it a genuinely new category of risk rather than an old one with a new name: your employees can be trained to spot a suspicious email, but the AI agent reading that same email was never trained the way a skeptical human was, and by design it is supposed to follow instructions written in plain language. The email that would set off alarm bells if a person read it can sail straight past an agent that has no reason to distrust the content it was asked to process.

This is also why basic email security and endpoint protection do not cover this gap on their own. A spam filter checks whether an email looks malicious to a human-oriented model of what malicious looks like, spoofed senders, suspicious links, known bad domains. A hidden instruction in white-on-white text, invisible to a person and to most conventional filters, was never what those systems were built to catch. The visibility most companies already have over "did someone click a bad link" simply does not exist yet for "did our AI agent quietly follow a hidden instruction," and that blind spot is a large part of why OWASP treats this as its top risk rather than a footnote.

What should you ask a vendor or your own team about this?

A short, direct set of questions turns "we take security seriously" into something you can actually verify:

  • How does the agent distinguish content it reads from instructions it should follow? If the answer is vague, the separation was probably never designed in.
  • What can this agent actually reach if it is successfully tricked? The honest answer should be a short, specific list, not "the whole system."
  • Which actions require a human to approve before they run? Anything irreversible or high-value should be on that list, no exceptions.
  • Is the agent sandboxed, and is its outbound network access limited? This is the control that held when filters failed in documented real-world cases.
  • Can you show me a test or a real incident, not just a claim? A team that has genuinely thought about this will have specifics, not a generic reassurance.

If those answers are vague or rest entirely on "the model is well-behaved," the risk has not actually been addressed, no matter how good the demo looked.

The bottom line

Prompt injection is the top-ranked security risk for AI agents in 2026 because it exploits something structural, not a bug that gets patched away: a model reading an email cannot always tell a legitimate instruction from a hidden one planted by an attacker. It is not hypothetical. A documented, zero-click exploit fully worked against a major production AI assistant, current defenses are bypassed more than 85% of the time by an adaptive attacker, and over half of organizations surveyed in 2026 had already experienced or suspected an AI agent security incident. None of that means agents are too dangerous to use. It means the agent's access has to be built assuming an injection will eventually get through: least privilege, sandboxing, human approval on anything that matters, and logging everything, so a successful trick becomes a contained, recoverable event instead of a silent breach.

If you want this built in from the start, with the isolation, scoped access, and human gates that actually contain a prompt injection, that is exactly what we do. Book a free consultation below and we will walk through what this looks like for your first agent.