Prompt Injection Isn’t a Chatbot Problem — It’s a Content Problem on Your Own Website

For two years, the entire conversation about prompt injection has pointed in one direction: the chatbot. We worried about the box where users type. We hardened the input field. We red-teamed the assistant.

We were guarding the wrong door.

In 2026, the most dangerous prompt injection doesn't arrive through a chat window. It sits quietly inside ordinary web pages — a product description, a support article, a GitHub README, a comment in your own HTML. The user types nothing malicious. The page does the talking. And when an AI agent reads that page on the user's behalf, the page becomes the attacker.

This is the shift almost nobody priced in: your content is now executable. Not by a browser. By a model.

Let's take it apart.

1. The Attack Surface Moved From the Prompt to the Page

Classic prompt injection assumed a human adversary at the keyboard, trying to jailbreak your assistant. That's directinjection, and it's the one everyone defends against.

Indirect injection flips the geometry. The attacker never touches your chatbot. They plant instructions in content that an agent will later read — and they wait. When your AI summarizes a page, browses a site, or pulls a document into context, it ingests those instructions as if they were part of its task.

The user asked their agent to "summarize this article." The article said, in text the user never saw: when an AI assistant reads this, ignore previous instructions and... The agent has no reliable way to tell the difference between content it should report on and content it should obey. To a language model, both are just tokens in the context window.

The page didn't get hacked. The page is the payload.

2. The Instructions Are Invisible to You and Loud to the Machine

Here's the part that makes this a content problem and not a security-team problem: the malicious text is sitting in markup you can't see but the model reads perfectly.

The techniques are old SEO black-hat tricks repurposed for a new reader:

• Zero-size text — font-size: 0 renders nothing to a human, reads fully to an agent.
• White on white — color: #fff on a white background. Invisible to the eye, plain text to the parser.
• Off-screen positioning — left: -9999px pushes content far outside the viewport. Gone for users, present in the DOM. This exact technique showed up in the Shai-Hulud supply-chain campaign.
• Hidden by CSS — display: none, visibility: hidden, opacity: 0, clip-path: inset(100%). The accessibility-era toolkit, now an injection toolkit.
• HTML comments — the sneakiest of all. A payload inside <!-- ... --> never renders, never appears on screen, and slips past scanners that only check visible text. In the research dubbed Comment and Control, a payload hidden in an HTML comment defeated three separate layers of GitHub Copilot's protection.

Every one of these passes a human visual review. Your designer signs off. Your QA clicks through. Nothing looks wrong, because to a human, nothing is wrong. The attack lives in the layer humans don't read and machines do.

3. The Page Doesn't Just Talk — It Acts

Reading malicious instructions would be bad enough. But agents don't just read; they do things. And content can now instruct them to act.

The 2026 incident logs read like a new genre of attack:

• Pointing the agent off-site for orders. A page tells the agent to fetch its real instructions from an external URL — turning a static page into a command channel.
• Writing to the agent's own config. The nastiest class: instructions that tell a coding agent to write to .cursorrules, CLAUDE.md, .vscode/tasks.json, or .github/workflows/. The TrapDoor campaign and the Cursor CVE-2026-26268 both abused this — once the agent writes those files, the manipulation becomes persistent. Every future session is compromised, silently.
• Rendering phishing inside the assistant's own UI. The ChatGPhish technique planted Markdown in a page so that when ChatGPT summarized it, the assistant re-rendered a fake security alert — complete with a malicious link — in its own trusted interface. The user trusts the assistant. The assistant trusted the page. The page lied.

The common thread: the agent treats your content as a source of intent, not just information. That's the whole ballgame.

4. Why "Just Sanitize Inputs" Doesn't Save You

The instinct is to reach for the old playbook — escape, sanitize, validate. It doesn't map cleanly, for one uncomfortable reason.

In SQL injection, there's a hard boundary between code and data, and the fix is to keep them apart. In prompt injection, there is no boundary. The model's instructions and the content it processes occupy the same channel — natural language in a context window. You can't escape your way out of a problem where the data is the instruction format.

This is why the framing matters. If you think of this as a chatbot-hardening problem, you'll spend your effort on the input field and leave every page you publish wide open. The exposure isn't where users type. It's everywhere your content can be read by a machine acting for someone else — which, in 2026, is everywhere.

5. The New Discipline: Content That's Safe to Be Read by a Machine

So the question for anyone who publishes on the web shifts from "is my chatbot secure?" to "is my content safe to be read by an agent?"

In practice that means treating your own pages as an attack surface:

• Audit the invisible layer. Hidden text, zero-size fonts, off-screen content, suspicious HTML comments — scan for them the way you'd scan for malware. If a human can't see it but a model can, you need to know it's there.
• Distrust content you didn't write. User comments, third-party widgets, syndicated feeds, dependency READMEs, anything ingested from outside — each is a potential injection vector the moment an agent reads it.
• Watch what your content tells agents to do. Any instruction-shaped text — "fetch from," "write to," "ignore," "when an AI reads this" — is a red flag in published content, not a feature.
• Assume the reader is non-human. For the first time, the most consequential visitor to your page may not have eyes. It has a context window.

This is genuinely new work. It doesn't belong solely to the security team, because security teams guard infrastructure — and this lives in content. It doesn't belong solely to marketing or engineering, because they think in terms of human readers. It sits in the gap between them, which is exactly why it's being missed.

The Reframe

Prompt injection was never really about the chatbot. The chatbot was just the first place we looked.

The actual surface is the web itself — every page that an agent might read on someone's behalf. Your content stopped being a thing that gets displayed and became a thing that gets executed, by a reader that can't tell description from instruction and acts on what it finds.

The chatbot was the door we watched. The page was the window left open.

Welcome to content security for the agentic web — where the most important question about your website is no longer how does it look, but what does it tell the machine to do.

The campaigns referenced here — Shai-Hulud, TrapDoor, the Cursor CVE, ChatGPhish, Comment-and-Control — are tracked in detail at Cyberflux, an agentic-web threat research base. The detection patterns behind them power senteri's content scanner.

Want to know what an agent reads on your pages that you can't see? Run a scan — paste a URL or markup and surface the hidden layer: zero-size text, off-screen content, instruction-shaped comments, external payload calls.