The demo escaped the lab

For a couple of years, indirect prompt injection lived in the comfortable category of "concerning if it ever happens." Researchers would show that an AI agent reading a web page could be tricked by hidden instructions embedded in that page, everyone would nod about how that was a problem for the future, and the world would move on. On March 3, 2026, Palo Alto Networks' Unit 42 published telemetry showing that the future had arrived. The attacks were no longer hypothetical. They were live, on real websites, aimed at real AI agents.

The core technique is unchanged from the demos: an attacker plants instructions inside ordinary-looking web content - in the HTML, in user-generated text, in metadata or comments - and waits for an AI agent to come along and read the page during some routine task like summarizing, analyzing, or making an automated decision. The agent ingests the page, cannot distinguish the legitimate content from the instructions buried in it, and does what the hidden text tells it to. What Unit 42 added is proof that this is being exploited in production, at scale, right now.

What the poisoned pages actually did

The abuse Unit 42 caught is not subtle. Hidden instructions on real web pages hijacked AI agents into initiating payments through Stripe, deleting databases, leaking their own system prompts, and approving scam advertisements. That last one is a notable first: the researchers documented AI-based ad-review systems being fooled by injected instructions into approving scam product ads, which means the AI put in place to catch fraudulent advertising was itself turned into the thing that waved the fraud through.

The distribution of attacker goals in Unit 42's telemetry is its own small horror. Around 14.2% of the observed attacks targeted data destruction - instructing agents to delete things. Roughly 9.5% attempted to bypass AI content moderation. Others went after payment rails through Stripe and PayPal, attempted denial of service, tried to extract sensitive information, or aimed to leak the agent's system prompt. These are the actions of software that has broad permissions and follows instructions, being pointed at destructive ends by text it read off a webpage.

Twenty-two ways to hide a command

Part of what makes the report valuable is its catalogue of how the instructions are concealed, because it maps how much effort attackers are already putting in. Unit 42 documented 22 distinct payload-engineering techniques.

The concealment methods are a tour of every way to put text on a page that a human will not see but a machine will read: fonts sized to zero pixels, elements positioned off-screen with negative coordinates, content suppressed with CSS "display: none," opacity turned to invisible. Beyond simple hiding, attackers used obfuscation - wrapping payloads in XML or SVG, cloaking them inside HTML attributes - and dynamic assembly, where Base64-encoded content decodes and comes together only at runtime, so the malicious instruction does not even exist as readable text in the raw page.

One scam page Unit 42 examined embedded 24 separate injection attempts at once, layering zero-sized fonts, off-screen positioning, CSS suppression, SVG encapsulation, and runtime-assembled JavaScript. That is not a curious researcher poking at an edge case; that is an attacker throwing everything at the wall because enough of it works. Notably, the single most common delivery method was not any exotic trick but plain visible plaintext, at 37.8% - attackers frequently do not even need to hide the instructions, because the agent will follow them either way.

"This is a security update"

The most telling statistic is behavioral. In 85.2% of cases, the attackers wrapped their instructions in a social-engineering frame, most often an authority override: phrasing the malicious command as a routine system task or an official-sounding directive like "this is a security update." The same manipulation that works on a distractible human works on a language model, because the model has been trained to be cooperative and deferential to instructions that sound legitimate. Tell the agent that following your command is the responsible, expected thing to do, and it tends to comply. The attackers figured out that you do not need to defeat the model's guardrails so much as talk past them.

The persistence twist

Unit 42 also demonstrated a nastier variant against Amazon Bedrock Agents, where a crafted URL, once fetched by the agent, wrote malicious XML-structured instructions into the agent's session memory. Those instructions then persisted across conversations, quietly exfiltrating data on every future interaction. This is the escalation that should worry anyone deploying agents with memory: the poison does not have to be re-delivered. Read the bad page once and the compromise rides along in the agent's own memory indefinitely.

Why this is on the pile

It is fair to ask whether this is really an AI failure or just criminals being criminals. The answer is that the systems failing here are the AI agents. Attackers have always tried to poison web content; what is new is that a whole class of software now reads that content and treats instructions hidden in it as commands to execute, with real permissions behind it. The vulnerability is the agent's inability to separate data from instructions, and Unit 42's contribution is to show that this weakness is being exploited in the wild, not merely theorized.

The practical warning is stark for anyone wiring an AI agent up to browse the web and take actions. Every page that agent visits is now potential attacker input. Give it the ability to spend money, delete data, or approve content, and you have given those abilities to whoever can get a webpage in front of it with the right hidden text and a confident "this is a routine system task." The demos were the warning. This is the part where the warning stopped being a demo.