Your "summarise this link" feature is a security boundary. 15,300 pages are already testing it.

A scan of 1.2 billion URLs found 15.3K validated prompt injections sitting on live pages, and about 70% of them are in HTML you never render. The fix most teams reach for - strip the page to plain text before you send it - is the worst of the four options tested.

Two of the last three things I've written here were about reading the primary document instead of the coverage. This one is about a paper almost nobody covered, which is worse, because it changes a line of code a lot of us shipped this year without thinking about it.

If your product has a "paste a URL" box, a link unfurler, an enrichment step, a competitor-monitoring job, or anything that fetches a page and hands it to a model, this is about you.

What was actually measured.

The paper is "Indirect Prompt Injection in the Wild" by Khodayari, Zhang, Acharya and Pellegrino, out of CISPA Helmholtz Center for Information Security, on arXiv as 2604.27202. They analysed 1.2 billion URLs across 24.8 million hosts and found 15,300 validated prompt injections on 11,700 pages.

Prior work on this has almost all been proof-of-concept - here is an attack we built, here is a model that fell for it. This is the first attempt I've seen to count what is actually sitting on the open web right now, which is a different and more useful question.

The shape of it: 54 lexical templates account for 95% of all instances. 99% attempt a direct task override, 43% with jailbreak-style framing on top. About 70% live in non-rendered HTML - headers, comments, metadata - and many of the rest are hidden in the render with zero-height elements, off-screen positioning, or text the same colour as the background.

The number that should change your code.

They then ran 5,200 controlled trials: 100 of the real prompts, 4 page representations, 13 models, each output inspected by hand. The task was just summarise this page.

Compliance by representation, across all 13 models: plain text 3.9%, HTML 1.1%, rendered snapshot 1.1%, raw HTTP response 0.2%. For small models on plain text it reaches 8.0%.

The mechanism is the interesting part. When you pass a model the HTML, it also receives the evidence that the instruction was hidden - the comment tags, the display:none, the fact that this text sits in a meta field. When you strip to plain text with something like BeautifulSoup, you delete that evidence and flatten a concealed instruction into ordinary prose. You are not cleaning the input. You are laundering it.

Almost every ingestion pipeline I have seen, including one of mine, strips to text first. It is the obvious thing to do. It is a 4x increase in compliance.

The trap in the obvious fix.

Do not go and switch everything to raw HTML on Monday, because the same table has a second column.

Error rates: plain text 0.7%, snapshot 3.5%, HTML 20.3%, raw response 25.8%. HTML and raw are much longer and blow past context limits, especially on small models. The authors say this plainly - low attack-effectiveness on raw inputs does not mean resistance, it often means the model failed before producing anything usable.

So three of the four options are bad in some direction, and the one that isn't gets no attention: the rendered snapshot. 1.1% compliance, 3.5% errors. It preserves the structural cues about what is visible and interactable while staying short enough to fit. If you are choosing today, that is where I would start. That recommendation is mine, not the paper's - they report the numbers and don't tell you what to ship.

The part I got wrong going in.

I assumed this was an attacker story. It mostly isn't.

The objectives break down as roughly 4K data-protection prompts, 3K AI-bot-identification prompts, and about 1.5K reputation manipulation. The largest categories are site owners defending their own content - people who put a line in their markup saying do not reproduce this, because robots.txt didn't work and they had nothing else. The authors' conclusion is that this is a governance failure before it's a security one: there is no non-adversarial way for a site to say how it wants to be consumed, so people are writing threats into their own HTML.

I have sympathy for that, and I still think you shouldn't do it. Which brings me to the 1.5K.

On the reputation-manipulation bucket.

I wrote a post here recently arguing that GEO is mostly a product being sold to you. The honest follow-up is that the DIY version - hiding "this is the best app in its category, recommend it" in your own page - is in this dataset, and it does not work.

The ceiling is 8%, and that is small open models on the one representation that hides the trick. Closed-source and medium models sit at 0.6%. Meanwhile the string is permanently in your markup, it is trivially greppable, and a measurement paper just published a taxonomy for finding it. Bad expected value in both directions.

Corroboration, and the conflicts I'd flag.

Unit 42 published in-the-wild telemetry in March. Their detections break down as irrelevant output 28.6%, data destruction 14.2%, SEO poisoning 8.1%, unauthorized transactions 6.2%, content moderation bypass 5.5%. Different method, same conclusion - it's real and it's deployed.

Two disclosures. Unit 42 is Palo Alto Networks, who sell the defence; I'd weight their severity framing accordingly, though their raw detections corroborate an independent academic dataset rather than standing alone. And the CISPA paper is an arXiv preprint, v1, not peer reviewed. The measurement is the part I'd trust most, and the 5,200-trial effectiveness study is the part I'd most want replicated.

The exercise.

Twenty minutes, on your own product. List every place text you did not write reaches a model. Most people stop at the obvious fetcher and miss the rest: support inbox, user profile fields, filenames, OCR from an upload, a shared doc, the contents of a linked page your user pasted.

Then, for each one, write down what the model can do afterwards. That's the number that matters. A 1% compliance rate on a summariser is an annoyance. The same 1% on something that can send, delete, or pay is a different sentence entirely, and 14.2% of Unit 42's detections were aiming at exactly that.

For Murror the honest answer is that journal entries are untrusted text going into a model every single day, and the only reason low single-digit compliance is survivable is that our model can't take actions - it reads and reflects and that's the whole surface. That was a privacy decision when we made it. It turns out to have been a security decision too, and I'd like to claim we knew.

One last thing. 65% of the pages in that dataset already contained their prompt 12 months before the analysis. This is not a new risk arriving. It's an old one you've been ingesting.