The agentic AI security corpus has no shortage of feasibility research. Benchmarks, red-team papers, novel attack constructions — the work demonstrating that indirect prompt injection can compromise an agent is substantial and well-represented across arXiv and institutional repositories. What has been missing is the other side of the empirical ledger: ground-truth data on what threat actors are operationalizing in the wild. The Google scan is that missing piece.
The authors — Thomas Brunner and Yu-Han Liu at Google DeepMind, with Moni Pande from the Google Threat Intelligence Group — scanned Common Crawl snapshots between November 2025 and February 2026, pattern-matched IPI signatures, classified candidates with Gemini, and human-validated the results. The post does not introduce a new attack. It does something rarer: it tells the field what attackers are actually doing today, and at what rate. For enterprise architects, three observations from the data and one structural reading follow.
Three Observations From the Data
The longitudinal signal matters more than the absolute volume. The Google team reports a 32% relative increase in malicious-category detections between their November 2025 and February 2026 scans — measured across multiple snapshots of Common Crawl, not a single pull. The absolute base remains small and the observed sophistication remains low. That is not the point. The point is the slope. Longitudinal data of this kind has been effectively absent from the corpus until now; every prior quantitative signal on IPI has come from adversarial construction rather than field measurement. A three-month upward slope across independent scans is the first empirical indicator of growth velocity the defender community can cite.
Relative increase in malicious-category detections — November 2025 to February 2026. Measured across multiple Common Crawl snapshots. Small absolute base; the value is the slope, not the level.
False-positive dominance is itself the signal. The authors note that naive scans return mostly benign content — research papers, educational posts, security write-ups discussing IPI — and that distinguishing these from functional threats required an LLM-assisted classifier followed by human review. Read structurally: the public web is currently saturated with educational discussion of IPI, which means the technique is widely understood, cheap to demonstrate, and conceptually resolved at the attacker’s end. What remains unresolved is the productionization of advanced variants into real campaigns. That asymmetry — high awareness, low weaponization — is the window.
The observed sophistication gap is a window, not a reassurance. The Google team writes that attackers have yet not productionized advanced 2025 research at scale, and explicitly attributes this to cost-benefit: historically exotic, with unreliable exploitation, now becoming cheaper to attempt as agentic systems become more capable and attackers automate their own operations. That framing is accurate and cautious. It is also a narrowing window. Enterprise architects reading this post should treat the low-sophistication observation as a timeline, not a verdict.
Two Failure Modes, One Scan
The Google team groups observed injections into six categories: harmless pranks, helpful guidance, SEO manipulation, agent deterrence, exfiltration, and destruction. Two of these are worth separating analytically — not because they overlap, but because they surface in the same scan and break at different layers of the agent stack.
One class of injection the scan surfaced is the tarpit: a page that, when opened by an AI reader, streams an infinite amount of text that never finishes loading. The authors describe this as an attempt to waste resources or cause timeout errors. Structurally, this is not a tool-call vulnerability — it is a containment failure on the inbound side. The agent has no runtime boundary around what it will consume, how long it will consume it, or what happens when the stream does not terminate.
Detection can flag the pattern after the fact. It cannot resolve the absence of a bounded read operation at the agent’s content-ingestion layer.A second class the scan surfaced is the destruction attempt: injected content instructing the agent to execute commands that, if propagated to a shell or filesystem tool, would delete user files. Structurally, this is the tool-call layer vulnerability our Series 1 research identified — content becoming command because the boundary between instruction and data is probabilistic rather than enforced.
Pattern matching can catch some known payloads. It does not resolve the absence of a structural policy over which injected text is permitted to authorize a destructive tool call.The same detection pipeline finds both failure modes. No amount of pattern matching structurally resolves either. The tarpit requires a bounded read at the content-ingestion boundary; the delete-file injection requires a deterministic authorization policy at the tool-call boundary. Neither is what Google’s field survey was designed to measure, and nothing in the Google post claims otherwise. The scan’s empirical value is that it makes the boundary between mitigation and resolution visible.
Detection mitigates; structural enforcement resolves. Both are required; neither substitutes for the other.Same scan, different layers. Detection mitigates both; pattern matching structurally resolves neither.
— Luminity Digital, analytical observation on the Google field surveyWhat the Detection Layer Does — and Doesn’t
The pipeline the Google team describes — coarse pattern match, Gemini-based classification of suspicious text, human review of classified results — is a well-designed operational detection layer. It scales, handles false positives intelligently, and incorporates human judgment where ambiguity is highest. For the provider, it is the right thing to build. For the enterprise, it is essential infrastructure when deploying agents into production.
It is also, at every stage, probabilistic. Pattern matching catches known signatures. LLM classification generalizes to unseen variants but produces its own false positives and negatives. Human review is bounded by review capacity. This is not a critique of the Google approach; it is a description of what operational controls can and cannot do. Detection mitigates. It does not resolve at the layer where the failure originates.
The tarpit failure would be structurally resolved at the agent’s content-ingestion boundary — bounded reads, enforced timeouts, hard byte-and-token ceilings on a single retrieval. The delete-file injection would be structurally resolved at the authorization boundary — a policy that destructive tool calls require provenance that cannot be established by injected content alone.
What To Do With the Window
The practical implication for enterprise architects is narrower than the scan’s language suggests. The Google post ends with a commitment to continued hardening, red-teaming, and scale monitoring. Those are all provider-side actions. The enterprise question is different: given that the detection layer is necessary and not sufficient, what moves enforcement earlier in the lifecycle before the cost-benefit shifts?
The answer is not a new tool. It is a set of architectural choices made at deployment time — the choice to route certain tool calls through deterministic policy rather than agent judgment, the choice to bound content ingestion at the runtime boundary rather than trust in-context instructions, the choice to treat any externally retrieved content as potentially adversarial by construction rather than by classifier verdict. These are not novel ideas. They are the structural enforcement patterns the research corpus has been describing for two years, now carrying an empirical field signal alongside them.
The Google scan does not say enterprise architects are out of time. It says the window is open and narrowing. Attackers have not yet productionized advanced 2025 research. The economics are shifting.
That is a more useful finding than either “the sky is falling” or “nothing to see here” — which is why it is worth reading carefully, and acting on while the architectural choices are still enterprise-defined.
