Finding a prompt injection is different from proving it worked

An AI assistant researching a subject may read a webpage, email or document that tells it to abandon its task. That is the basic problem behind indirect prompt injection: material supplied as evidence also tries to become an instruction. The attacker does not need to be the person chatting with the assistant.

Google’s 23 April study looked for these patterns in Common Crawl, a large collection of public webpages. The researchers described a practical obstacle: security tutorials and research papers often contain the same phrases as attacks. Counting every match would confuse discussion of a threat with an attempt to exploit it. Their process therefore added model classification and human review. Common Crawl also leaves out much content behind logins or anti-crawling controls. The results describe the observed public-web sample, not every place an agent might read.

Google’s 2 April Workspace account describes another part of the problem: turning newly found attacks into maintained defences. Its workflow combines human and automated red teams, external vulnerability reports, reproductions and a catalogue of attack patterns. Confirmed cases can inform new test examples, configuration changes and model updates. That continuing process differs from declaring prompt injection permanently solved.

For a team choosing an assistant, spotting malicious text is a warning signal. The harder questions concern outcomes: whether the assistant followed it, which tools it could reach and whether a sensitive action required approval. A security test should record those boundaries. Google’s two accounts describe research and its own defensive process; they do not independently establish that another product is safe or that every observed page instruction succeeded.