Zero-Click AI Assistant Attacks: Lessons from Gemini

A zero-click exploit used to mean something pretty specific: a nasty bug in a messaging app or OS that let attackers run code just by sending a message. December’s disclosure about a no-click weakness in Gemini Enterprise expands that mental model in an uncomfortable way.

The headline isn’t “Google fixed a bug” (they did). The real story is that enterprise AI assistants have become a new access layer to your organization’s most sensitive data—email, calendars, documents, and search. If attackers can influence what the assistant reads, they can influence what it does, and they can do it in ways that look like normal productivity.

This post is part of our AI in Cybersecurity series, and I’m going to be opinionated: if your security program treats “AI assistant access to Workspace/M365” as a nice-to-have productivity add-on, you’re already behind. These tools need the same rigor you’d apply to identity, endpoints, and privileged services.

What happened with Gemini Enterprise—and why it matters

Answer first: The Gemini Enterprise flaw (dubbed GeminiJack by researchers) enabled indirect prompt injection via everyday artifacts—Docs, Calendar invites, or emails—so that later, during a normal employee query, the assistant could be tricked into retrieving sensitive internal data and exfiltrating it.

Here’s the part that should make CISOs and SOC leads sit up: the employee didn’t have to click anything. The “interaction” was simply using the assistant as intended.

The mechanics: indirect prompt injection meets enterprise search

The attack pattern is straightforward and therefore repeatable:

1. Attacker creates a normal-looking artifact (a shared doc, a meeting invite, or an email).
2. They embed hidden or subtle instructions inside the content—crafted to be interpreted by the assistant when it ingests the artifact.
3. Later, an employee asks Gemini Enterprise something routine like “show me Q4 budgets.”
4. The assistant’s retrieval step pulls in the attacker’s artifact as “relevant context.”
5. The embedded instructions run inside the assistant’s context, telling it to pull extra sensitive content.
6. The output includes something that triggers data exfiltration (in the reported scenario, an external image request that carries data in the request).

The uncomfortable takeaway: RAG (retrieval-augmented generation) can turn your enterprise search pipeline into an attack pipeline if you don’t treat retrieved content as untrusted.

Why traditional tools didn’t light up

Answer first: Most security controls are designed to detect known bad binaries, suspicious process behavior, unusual auth flows, or explicit data transfer patterns—not an AI assistant “helpfully” retrieving internal documents and summarizing them.

In this scenario:

• The user’s query looks normal.
• The assistant’s access looks legitimate (it’s using granted permissions).
• The retrieval and summarization steps occur inside an application workflow that often lacks deep security instrumentation.
• Exfiltration can be hidden in “innocent” web requests (like loading an external resource).

This is exactly why AI in cybersecurity can’t just mean “use an LLM in the SOC.” It also has to mean deploying detection and response that understands AI assistant workflows as first-class telemetry.

The bigger shift: AI assistants are now privileged infrastructure

Answer first: Once an assistant can read across Gmail/Calendar/Docs (or M365 equivalents), it behaves like a privileged service account plus a search engine plus a summarizer—and that combination creates new blast radius.

Most companies get this wrong. They focus on “what data the assistant is trained on” and ignore “what data the assistant can retrieve at runtime.” Training data matters, but runtime retrieval is where the operational risk lives.

A simple mental model that helps

Treat your AI assistant as three components:

1. Identity & permissions (what it can access)
2. Retrieval layer (what it chooses to pull into context)
3. Action/output layer (what it can send, render, or do)

If any one of these is too permissive, you get incidents that feel mysterious because no single control “failed.” The system did what it was designed to do—just with adversarial content in the loop.

Why this is a zero-click problem, not “just prompt injection”

Classic prompt injection often requires a user to paste something, click something, or interact in a way that’s at least suspicious in hindsight.

The Gemini Enterprise case is more dangerous because it hides inside normal work:

• A shared doc from a partner
• A calendar invite from an external sender
• An email thread with copied content

That’s not exotic. That’s Tuesday.

How AI-driven cybersecurity helps stop zero-click assistant exploits

Answer first: AI helps here in two practical ways: anomaly detection across assistant behavior and automation to contain and remediate faster than humans can triage.

If you want a modern defense posture for enterprise AI assistants, you need controls that watch the behavioral chain, not just isolated events.

1) Detect anomalous retrieval and “context poisoning”

A strong approach is to build (or buy) detection that flags unusual patterns such as:

• Retrieval spikes for sensitive keywords (e.g., “budget,” “acquisition,” “payroll,” “M&A,” “wire instructions”) immediately after ingesting externally shared artifacts
• The assistant pulling content from unexpected sources for a query (e.g., a budget query pulling from an externally shared doc created yesterday)
• Repeated retrieval of high-sensitivity documents by many users who don’t typically access them (a sign of systemic prompt poisoning)

This is where machine learning actually earns its keep. Rules alone struggle because:

• “Budgets” searches are normal.
• Externally shared docs are normal.
• The combination, timing, and downstream behavior is what’s abnormal.

A practical stance I’ve found works: model what “normal assistant retrieval” looks like per department and per sensitivity tier, then alert on deviations.

2) Catch covert exfiltration in the output layer

Exfiltration in these scenarios can be sneaky: loading an external image, making a request to an attacker-controlled domain, or embedding data into a URL.

AI-driven security analytics can help by:

• Classifying outbound requests triggered from assistant sessions
• Detecting unusual URL patterns (high entropy strings, unexpected query parameters, base64-like blobs)
• Correlating assistant activity with browser/network telemetry in near real time

The key is correlation. A single external request might be benign. An external request immediately after the assistant retrieved multiple sensitive docs is not benign.

3) Automate containment (because speed matters)

Zero-click assistant attacks are designed to be quiet. Your best chance is to reduce dwell time.

Good automation playbooks include:

• Quarantining or restricting externally shared artifacts that match poisoning patterns
• Temporarily disabling the assistant’s connector to a high-risk data source (Docs, Mail, Drive) when a high-confidence alert triggers
• Forcing step-up authentication or human approval for queries that attempt to access high-sensitivity collections
• Rolling back or reindexing poisoned content in enterprise search

If your incident response requires three meetings and a ticket, you’re going to lose.

Practical mitigations you can implement this quarter

Answer first: You don’t need to ban AI assistants to be safe. You need least privilege, better boundaries in retrieval, tight egress controls, and auditability.

Here’s a pragmatic checklist you can execute without turning your workplace into a museum.

Lock down connectors and scopes (least privilege, for real)

• Start with narrow use cases: e.g., allow the assistant to read a defined knowledge base before granting access to email or all documents.
• Use scoped access by group/role (Finance assistant access should not look like Engineering access).
• Separate “assistant can search” from “assistant can open full content” where possible.

Snippet-worthy rule: If an AI assistant can read everything your users can read, it becomes the most attractive target in your environment.

Treat retrieved content as untrusted input

Your AI system should behave like a browser:

• Assume retrieved text may contain malicious instructions.
• Apply instruction hierarchy: system and policy prompts must dominate retrieved content.
• Strip or neutralize suspicious markup and hidden text patterns.

Even better: maintain a “retrieval firewall” that scores documents for prompt-injection indicators and limits their influence.

Add “human in the loop” where it actually matters

Don’t force approvals for every query. People will route around it.

Instead, require confirmation for:

• Accessing highly sensitive labels (M&A, payroll, legal holds)
• Bulk retrieval or cross-domain retrieval (email + docs + drive in one response)
• Any action that sends content outside the organization (emailing, posting, sharing)

Instrument assistant activity like you would a privileged service

Log these at minimum:

• Query text (or a privacy-preserving hash plus category)
• Retrieval sources (which doc IDs, which mail threads, which calendars)
• Sensitivity labels of retrieved items
• Output actions (rendered links, external requests triggered, shares created)

Then feed it to your SIEM/SOAR and actually write detections.

Red-team the “boring” paths: email, docs, calendar

Most security testing still focuses on endpoints and cloud configs. Add a track for AI assistant abuse cases:

• Externally shared doc with hidden instructions
• Calendar invite containing injection content
• “Helpful” email from a vendor that includes retrieval triggers

If you can’t reproduce an attack chain in a controlled setting, you won’t recognize it in production.

“People also ask”: quick answers for security and IT leaders

Is this risk limited to Gemini Enterprise?

No. Any RAG-based enterprise assistant that retrieves from email/docs/tickets can be vulnerable to indirect prompt injection if it treats retrieved content as trustworthy.

Does DLP solve this?

DLP helps, but it’s not sufficient. Classic DLP is good at known channels and patterns. Assistant-driven exfiltration can happen through unexpected paths (rendering external resources, plugins, connectors).

Should we disable external sharing?

Disabling external sharing reduces risk, but it’s rarely realistic. A better approach is stricter controls on what externally contributed content can influence and stronger monitoring of assistant retrieval behavior.

What’s the fastest win?

Start by enforcing least privilege on assistant connectors and adding logging/alerting for unusual retrieval + outbound request chains. You’ll get immediate visibility without boiling the ocean.

Where AI in cybersecurity goes next

GeminiJack is a useful stress test: it shows that “AI assistant security” isn’t a niche topic. It’s becoming core enterprise security.

The next wave—already visible as we head into 2026 budgets—will be agentic AI that can not only read data, but also take actions across systems. That raises the stakes. The same prompt-injection pattern that exfiltrates a budget today could initiate a vendor payment, change IAM settings, or open a support ticket that triggers downstream workflows tomorrow.

If you’re adopting AI assistants at scale, a good next step is to run a short, focused assessment: map assistant permissions, validate retrieval boundaries, test exfil paths, and decide what should be automated in response. If you do that well, you’ll keep the productivity gains without turning your assistant into an attacker’s favorite employee.

What security control do you trust most right now for AI assistants: connector scoping, retrieval filtering, or behavioral detection—and why?