The web is adversarial now: what Google's prompt-injection scan means for your agents

Picture the smallest version of the problem. One of your engineers points an AI coding agent at a public repository to fix a bug. The code looks ordinary. Buried in a comment, in text no human would bother to read, sits an instruction: create this file, run this command. The agent reads the comment the way it reads everything else, as input worth acting on, and does what the note says. Nobody typed that command, and nobody approved it. It arrived inside a file that looked like work.

This actually happened. In January, researchers at Pillar Security showed they could do exactly this to Google's Antigravity — an agentic coding tool — and get it to run arbitrary code on the user's machine. The instruction didn't need to come from a hacked account. It could ride in on a benign-looking source file pulled from a public repo. Google patched the hole and paid a bounty. The mechanism is what should change how you think: an ordinary-looking bug fix talked a coding agent into running code on someone's machine.

The reframing worth taking to whoever signs off your AI strategy is this. The moment an agent reads content it didn't write, whether that's a web page, an email, a document or a public repo, it's working in hostile territory. For thirty years we've treated the web as a publishing surface, mostly safe with the odd bad neighbourhood. For an agent, it's an attack surface. That shift isn't a job you can hand to the security team and forget about. Deciding what your agents are allowed to read is a strategy call — it shapes what you can safely automate, which vendors you end up depending on, and how fast you can move — and it belongs with your operating decisions, not buried in a risk register.

What “indirect prompt injection” actually means

The technique has an ugly name and a simple shape. An attacker writes instructions into content your agent will eventually read. They never touch your prompt — they plant the instruction in something your agent will read later, and let the agent carry it in. The page might carry text shrunk to a single pixel, drained to near-transparency, tucked inside an HTML comment, or hidden in the page's metadata — invisible to you, perfectly legible to the model. Your agent reads the page and can't reliably tell the content apart from the commands buried inside it, so it follows them.

A person skims a dodgy website and, worst case, gets fooled or wastes a few minutes. An agent skims the same page and might act on it, with your credentials, inside your systems. The gap between reading and doing, which keeps humans mostly safe online, is exactly the gap an agent doesn't have.

A 32% rise in three months

Google's threat-intelligence team went looking for how common this has become. They scanned two to three billion crawled web pages a month for hidden instructions lying in wait for an AI to read them, and reported a 32% relative rise in the malicious category between November 2025 and February 2026. Three months. A third more.

The same researchers were careful to add that the sophistication is still low. Much of what they're seeing is crude, and their own defences catch most of it. I'd hold both facts at once, because crude-and-rising isn't reassuring. It's the profile of an attack that's cheap, easy to automate, and worth doing at scale.

That's why attackers have found it: it's about the cheapest attack surface they've had in years. You don't need to breach anything. You publish a page and wait for someone else's agent to come and read it.

What the Antigravity bypass showed

Plenty of teams will reach for the vendor's safety setting, switch it on, and assume the problem is handled. The Antigravity disclosure is why that isn't enough. Pillar's exploit worked against Secure Mode, Google's most restrictive configuration, the one you'd point to in a board meeting as evidence you'd done the sensible thing. A native file-search tool ran before Secure Mode could evaluate what it was doing, and that was the gap. The reassurance of a named safety setting turned out to be worth rather less than it looked.

Google fixed this specific hole, and it won't be the last one. The underlying problem is a property of how these systems work today: an agent that can't reliably separate the content it reads from the instructions it follows. Patches close individual doors. They don't stop the agent walking up to the next one.

Closed loop, allow-list, verifier

So what works? Three design choices, in rising order of how much freedom you're willing to give up.

1. Closed-loop deployments. The agent never reads third-party content at all. It works inside data you control — your own documents, systems and repositories, and nothing else. Nothing from the open web enters the loop. This is the strongest control and the most limiting, which is exactly the trade you're making. For a lot of internal automation, it's the right one.
2. Allow-listed sources. If the agent has to read outside content, it only reads from sources you've vetted: a fixed list of domains, feeds or repositories you trust and monitor. Everything else stays out; a known, bounded slice comes in. Most real deployments live here, and the discipline is in keeping the list short and honest rather than letting it creep back towards “the whole internet.”
3. Verification layers. Before the agent acts on anything that matters, such as sending money, running a command or changing a record, an independent check sits between the intent and the action. Sometimes that's a second model whose only job is to ask whether this instruction matches what the user actually wanted. Sometimes it's a person. What you're buying is separation: the thing reading the hostile content isn't the same thing with its finger on the trigger.

None of these is exotic, and none is a guarantee. A verifier can be fooled and an allow-list drifts if you stop watching it, so whichever you pick, assume it ages: the attack side is moving fast enough that a control which looks adequate now may not survive the year.

But notice what these choices really are. Closed-loop or open, vetted sources or the whole web, a human sign-off or none — those aren't settings a security engineer flips after the fact. They're decisions about how the product works and how much you'll let it do on its own, which is why they belong to whoever owns the strategy, not whoever owns the firewall. They're the agent-era version of controls every operator already understands: segregation of duties, an approved-supplier list, a second signature on the big cheque. What's new is that you now apply them to software that reads and acts on its own, at a speed no human sign-off was designed for.

The board-level question

I've argued before that the hardest part of agent governance is the part you can't see: the shadow agents already running on staff laptops, wired into company systems by people who never asked. This is the mirror image. Shadow agents are about what's running inside without your knowledge. This is about what the agents you do know about are reading from outside. Same governance gap, pointed the opposite way.

So the exercise is straightforward, and worth doing this quarter. List every agent running in your organisation. Mark the ones that read third-party web content, anything that browses, clicks, opens email or pulls from a public source. For each one you've marked, ask a single question: does it have a closed loop, an allow-list or a verifier? If the answer for any of them is “none,” you've just found your next sprint.

If you're not even sure which of your agents are autonomous enough to matter, that's its own kind of answer, and it's worth an honest look at where you actually are before you start worrying about which ones read the web.

The web didn't get more dangerous this year. It's the same messy, mostly-fine place it always was. What changed is that we started sending software into it that reads everything, trusts too readily, and acts on its own, and we're only now deciding what we'll let it touch. That's a decision worth making on purpose, before something out there makes it for you.