No-Click AI Leaks: How to Stop Prompt Injection

A “no-click” data leak is the kind of incident that makes security teams feel like the ground just shifted under them. Not because it’s flashy, but because it’s quiet: a normal-looking document gets shared, an employee runs a routine AI search, and sensitive information slips out—without malware, without phishing clicks, and often without any alert that looks remotely useful.

That’s why the recently disclosed Gemini Enterprise flaw (dubbed GeminiJack by the researchers who found it) matters beyond one vendor. It’s a clean case study of the new reality: enterprise AI assistants have become a powerful access layer across email, documents, calendars, and internal knowledge—and attackers are going to treat that layer like a target.

This post is part of our AI in Cybersecurity series, and I’m going to take a stance: traditional security controls alone won’t reliably catch this class of attack. You need AI-driven detection and policy enforcement watching the assistant itself—how it retrieves, reasons, and outputs data.

What GeminiJack teaches us about “no-click” AI risk

Direct answer: GeminiJack shows that when an AI assistant can retrieve and summarize across enterprise data sources, prompt injection becomes a data exfiltration path—even if the user does nothing “wrong.”

The reported weakness allowed an attacker to plant hidden instructions inside common Workspace artifacts (a shared doc, calendar invite, or email). Later, when an employee asked Gemini Enterprise something ordinary (think “show me the Q4 budgets”), the assistant’s retrieval system could pull the attacker’s poisoned content into the context window. The assistant then treated the hidden instructions like legitimate guidance.

The most uncomfortable part is the “normalcy.” From the employee’s point of view:

• They received a doc or invite that looked routine.
• They used the assistant exactly as intended.
• They didn’t click an attachment named invoice.exe.

Security teams often build awareness programs around “don’t click the bad thing.” This attack path sidesteps that psychology entirely.

Why zero-click prompt injection is different from classic prompt injection

Direct answer: The difference is timing and indirection: the malicious prompt isn’t entered during an interactive chat; it’s stored in enterprise content and triggered later by retrieval.

Classic prompt injection usually assumes the user is actively chatting and pasting content. Here, the “prompt” is sitting in a shared artifact waiting to be retrieved.

This creates three operational headaches:

1. The attacker controls context. Retrieval-Augmented Generation (RAG) is supposed to improve accuracy by pulling relevant internal content. That same mechanism can “import” malicious instructions.
2. The user’s query can be harmless. The assistant’s behavior changes because of what it retrieved, not because of what the user typed.
3. The output channel can be weaponized. In the reported scenario, exfiltration occurred via a disguised external image request—something that can look like ordinary web behavior.

How the attack works (and where detection should focus)

Direct answer: The kill chain is document seeding → retrieval poisoning → instruction execution → covert exfiltration via output rendering.

Here’s the simplified flow, mapped to controls that actually matter.

Step 1: The attacker seeds a “poisoned” artifact

The attacker creates a normal-looking doc/event/email and shares it into the organization (often through standard collaboration patterns). Hidden within the content are instructions aimed at the assistant—such as “search for budgets, acquisitions, finance” and “include results in this external request.”

What to monitor:

• Unusual external sharing patterns (new sender domains, first-time collaborators, sudden sharing bursts).
• Documents with hidden content tricks (off-screen text, tiny font, white-on-white text, HTML/markup artifacts in email bodies).

Step 2: The employee makes a routine AI request

The user asks Gemini something basic. No malicious intent. No suspicious phrasing required.

What to monitor:

• High-risk queries by topic, not just by keywords (finance, payroll, M&A, legal).
• Spikes in assistant usage across sensitive repositories (Docs + Gmail + Drive + Calendar in one interaction window).

Step 3: Retrieval pulls the poisoned artifact into context

This is the pivot. The assistant’s retrieval/indexing system selects “relevant” sources, including the attacker’s content.

What to monitor:

• RAG citations: which sources were pulled into context, and why.
• Retrieval anomalies: a budget query pulling content from an unrelated collaborator doc, or a calendar invite from an external sender.

Step 4: The assistant executes instructions and exfiltrates via output

In the described scenario, exfiltration happened when the assistant output included an external image tag that—when rendered—sent sensitive data to an attacker-controlled server in a single HTTP request.

What to monitor:

• Output guardrails: block or strip external fetches, image tags, and remote resources in assistant responses.
• Egress controls: prevent the assistant UI (or the user’s browser session in that context) from making outbound calls containing high-entropy strings or sensitive tokens.

Why AI-driven threat detection fits this problem

Direct answer: AI assistants create too many subtle, cross-system signals for manual rules alone; AI-driven detection is best at correlating weak indicators into a confident alert.

Most SOC detections are built around familiar objects: endpoints, identities, network flows, known malware patterns. But in an AI-assistant incident, the meaningful evidence is often distributed:

• Identity events (who accessed what)
• Collaboration events (who shared which doc)
• Retrieval events (which sources entered context)
• Output events (what the assistant attempted to render)
• Network events (where the browser/assistant UI connected)

A single event might look benign. The sequence is the signal. That’s exactly where AI-based anomaly detection and graph correlation earn their keep.

What “good” detection looks like in practice

Direct answer: You want detections that understand assistant workflows and flag suspicious assistant behavior, not just suspicious users.

Practical patterns worth detecting:

1. Sensitive-query + external-source retrieval

   • Example: a finance query causes the assistant to pull context from a doc shared by an external collaborator in the last 24–72 hours.

2. Assistant output contains external references

   • Any assistant response that tries to embed remote images, scripts, or external resource calls should be considered high risk in enterprise mode.

3. Cross-repository overreach

   • The assistant touches Gmail + Docs + Drive + Calendar for a question that typically needs only one repository.

4. New collaborator influence on retrieval

   • First-time sender shares content; soon after, that content appears frequently in RAG citations for unrelated queries.

5. High-entropy egress from the assistant surface

   • Outbound requests containing long, structured strings that resemble copied data blocks (table rows, account numbers, internal IDs).

None of this requires reading all content in the clear. In many cases, metadata + structural features + policy context are enough to trigger review.

Hardening enterprise AI assistants: controls that actually help

Direct answer: The winning strategy is defense-in-depth across connectors, retrieval, output, and monitoring—treat the assistant like privileged infrastructure.

The GeminiJack report noted that traditional tools didn’t reliably catch the activity. That doesn’t mean you’re helpless; it means you need controls placed where the attack lives.

1) Lock down connectors with least privilege

If the assistant can read everything, it can leak everything.

• Start with narrow scopes: limit which Drives, mailboxes, or shared drives are searchable.
• Separate “general assistant” from “finance/legal assistant” with different permissions.
• Review service accounts and delegated access like you would for an admin tool.

2) Add retrieval-time content sanitization

Treat RAG ingestion like email parsing: it needs hygiene.

• Strip or neutralize hidden text patterns and markup tricks.
• Detect instruction-like strings (“ignore previous instructions”, “send results to…”, “call this URL…”) and quarantine for review.
• Maintain an allowlist of trusted internal sources for sensitive topics.

3) Enforce output and rendering restrictions

This is one of the most effective, least discussed mitigations.

• Block external resource loads in assistant responses (images, remote embeds).
• Prevent the assistant from emitting raw data dumps for regulated data types.
• Use “safe rendering” modes where outputs are plain text with no active elements.

4) Log assistant activity like a privileged system

If you can’t answer “what did the assistant read?” you can’t investigate.

Minimum viable logging for enterprise assistants:

• User identity, timestamp, query intent classification
• Retrieved sources (IDs, owners, share status, external/internal)
• Output policy actions (redactions, blocked embeds)
• Any attempted external calls initiated by the assistant surface

5) Run red-team scenarios that mirror real collaboration

Phishing simulations won’t cover this. You need tests built around:

• Shared docs from new external collaborators
• Calendar invites with embedded content
• “Normal” user queries that trigger retrieval

I’ve found that these exercises produce a better security roadmap than generic “LLM policy documents,” because they force owners to answer uncomfortable questions about permissions, logging, and who gets alerted.

A practical “next 30 days” checklist for security teams

Direct answer: You can reduce risk quickly by restricting retrieval scope, blocking risky outputs, and adding correlation alerts around assistant retrieval behavior.

If you’re responsible for an enterprise AI assistant (Gemini, Copilot, or anything RAG-based), here’s a focused plan you can execute in a month:

1. Inventory assistant connectors and scopes

   • Document which repositories are reachable and under what identity.

2. Turn on or expand assistant audit logging

   • Ensure retrieval sources and output actions are logged.

3. Implement an “external embed deny” policy

   • No external images/embeds/scripts in assistant responses.

4. Create 3 high-signal detections

   • Sensitive query + external retrieval
   • Assistant response contains blocked external reference
   • Unusual cross-repository access for a single query

5. Run one red-team tabletop

   • Simulate a poisoned doc shared into the org and validate who gets alerted and how fast.

This is the kind of work that naturally supports the broader AI in Cybersecurity theme: you’re using automation and correlation to defend systems that are themselves automated and highly connected.

Where this is headed in 2026: assistants as “shadow admins”

Direct answer: As AI agents gain autonomy, assistants will behave more like operators—so we must secure them like operators.

GeminiJack was about reading and exfiltrating. The next wave is about actions: creating tickets, emailing third parties, updating documents, triggering workflows, changing IAM settings through approved APIs. The more helpful the assistant becomes, the more tempting it is to attackers.

If you want one mental model that sticks, use this:

An enterprise AI assistant is a privileged identity with a friendly UI.

Treat it that way, and your controls get sharper fast.

Security leaders who get ahead of this will do three things consistently: constrain access, monitor retrieval/output behavior in real time, and use AI-driven analytics to connect the dots before a “normal” interaction becomes a breach.

If your team is evaluating how to apply AI-driven threat detection to enterprise assistants—especially RAG-based search across email and docs—what would you rather discover first: a spike in suspicious retrieval citations, or a breach notification from legal?