Google hardens Workspace against indirect prompt injection

Google has published more detail on how it is trying to keep indirect prompt injection out of Workspace with Gemini. The company pitches a continuous, layered defence that blends governance, fast configuration changes, model retraining, and what it calls model hardening. The target is clear: stop malicious instructions hidden in documents, emails, or tools from steering a Large Language Model (LLM) away from the user’s intent.

The discovery pipeline is broad. Human red teams simulate realistic users and attack paths. Automated red teaming generates payloads at scale. A public vulnerability rewards programme pulls in external findings. Open-source intelligence adds whatever is circulating in the wild. All of this lands in a central catalogue where issues are reproduced, de-duplicated, mapped to technique and impact, and assigned to owners.

From there, Google leans heavily on synthetic data. Using an internal system called Simula, the team expands each attack into variants to stress different edges of the defences. They say this boosted synthetic data generation by 75 percent. Those variants feed three layers of protection: deterministic rules, machine learning models, and LLM prompt-level tweaks.

Deterministic controls sit behind a policy engine and include user confirmations, URL sanitisation, and tool-chaining rules. This layer is tuned for speed, with configuration pushes and, when needed, regex takedowns. ML-based defences are retrained on partitioned synthetic sets to keep evaluations clean. LLM-based defences get prompt updates using the same synthetic pool and are judged against agreed metrics. Finally, Google works on Gemini itself, training the model to ignore embedded instructions while staying useful. End-to-end tests across Gmail, Docs, and other apps measure before-and-after effects of each change.

What looks solid

The operational discipline matters. Treating IPI as a vulnerability management problem, not a single filter, is the right move. The separation between rapid, deterministic fixes and slower model updates makes sense. The synthetic pipeline creates scale for evaluation and retraining that most enterprises currently lack. And the before-and-after testing across actual product surfaces is the right way to validate changes.

What is missing

There are few hard numbers. We do not get baseline or post-mitigation attack success rates, nor any view of false positives from URL sanitisation or aggressive tool policies. How much user friction do confirmations add, and how quickly do users consent-click through them? The paper does not discuss latency or cost impacts of additional ML and LLM checks.

The reliance on synthetic variants raises a familiar concern: coverage. Do these variants generalise to attacker creativity, especially multi-step chains that cross apps and tools? Regex takedowns are quick, but brittle. Encoded payloads, template hijacks in shared drives, or instructions buried in images, PDFs, and spreadsheets are not addressed here. Nor are third-party add-ons and connectors in Workspace, which are common enterprise entry points.

LLM prompt defences can drift or be bypassed when context changes. Model hardening is promising, but we do not see evidence of durability across unseen patterns, or how it behaves when the model faces conflicting embedded instructions from trusted sources. Cross-tenant boundaries and data exfil controls get no airtime.

If you are an attacker, you go where the tools are. You target link previews, email signatures, calendar invites, and shared documents with embedded instructions to trigger permitted tool calls. You hide inside trusted domains and allowed workflows. You exploit consent fatigue. The question for Google’s policy engine is whether it can keep up across products without blocking legitimate work.

For enterprises, the template is useful even if the proof points are thin. A central vulnerability catalogue, a fast policy layer for deterministic controls, and a synthetic-variant pipeline that feeds retraining are replicable patterns. What you still need from a vendor is evidence: measurable reductions in attack success, acceptable false-positive rates, and clear limits on where the system will say no.

• Establish a governed IPI catalogue with ownership and reproducibility.
• Centralise deterministic policies for rapid point fixes across apps and tools.
• Invest in synthetic variant generation to drive repeatable evaluation and retraining.

The lede is simple: the framework is credible, but the scoreboard is blank. Until vendors publish durable metrics, you are buying process, not outcomes.