Prompt Injection Is Now a Wild-Internet Problem, Not a Research Curiosity
The finding
Google's security team has done what most of us had been quietly assuming someone should do: measure the prevalence of prompt-injection payloads on the open web. The short version of their post is that injection content — pages that try to steer a downstream LLM into ignoring its system prompt, leaking secrets, or executing tool calls — is no longer a CTF exercise. It's present, in the wild, on pages your retrieval pipeline is highly likely to crawl.
What changes in practice
Two things move from "good practice" to "load-bearing" once injections are common in your retrieval corpus:
- **Trust boundaries around tool calls.** Treat anything the model produces as untrusted user input when it becomes a tool argument. Validate, sanitise, enforce allowlists. The model's intent is irrelevant — the prompt that produced it may have been hijacked three retrievals deep.
- **Provenance tracking on retrieved chunks.** Every chunk in your context window needs to carry a "where did this come from" tag, and high-risk tool calls should refuse to fire if the supporting evidence came from an untrusted source.
Why this matters for KYAX clients
If you've shipped an agent (RAG over your docs, customer-support assistant, internal copilot), this is the single most important paper to read this month. We're seeing clients with agents in production whose retrieval surface includes the open web, ticket systems, customer-submitted attachments — all of which are now plausible injection vectors. The fix isn't to lock everything down; it's to **stop trusting model output the moment retrieval can be poisoned**. That's a design change, not a config flag, and the sooner it's done the cheaper it is.
---
*Source: [Google Online Security Blog](https://security.googleblog.com/2026/04/ai-threats-in-the-wild-current-state-of-prompt-injections.html) — Thomas Brunner, Yu-Han Liu, Moni Pande, 2026-04-23. Commentary is original to KYAX.*