What do organisations get wrong about zero-click AI data leaks?

They assume the absence of a phishing click or malware means the event is low risk. In reality, if a model can act on untrusted retrieved content and reach sensitive systems through normal search behaviour, the leak can be silent, fast, and hard to detect.

Why This Matters for Security Teams

Zero-click AI data leaks are dangerous because the trigger is not a user mistake, it is the model’s own ability to consume content, retain context, and reach connected systems through normal workflow. That means the old comfort signals, no phishing click, no malware alert, no unusual login, can all be present while sensitive data still leaves the environment. Security teams often underestimate how quickly exposed credentials and agent-driven access can be abused, as seen in LLMjacking: How Attackers Hijack AI Using Compromised NHIs and Gemini AI Breach — Google Calendar Prompt Injection.

The mistake is treating AI data exposure like a conventional endpoint or email problem. In practice, the leak path is often retrieval, tool use, or orchestration, which means the data moves through approved systems and is harder to distinguish from legitimate behaviour. That is why NHI governance matters here, especially when secrets, tokens, and backend APIs are available to the model. Current guidance suggests teams should study patterns described in Guide to the Secret Sprawl Challenge alongside external warning signs from Anthropic’s report on AI-orchestrated cyber espionage. In practice, many security teams encounter zero-click leakage only after a model has already retrieved, summarized, or forwarded sensitive content through trusted tooling.

How It Works in Practice

Organisations usually get this wrong in three ways. First, they assume the model is safe if the prompt came from a trusted user, even though the dangerous input may arrive later through retrieval, browser content, shared documents, or tool output. Second, they focus on content filtering and miss the identity layer: if the agent has valid access to mail, files, tickets, or APIs, it can move data without ever “breaking in.” Third, they log prompts but not the full chain of actions, so the leak is invisible once the model acts inside approved workflows.

The practical control model is to reduce standing access, issue short-lived credentials, and constrain what the model can do at request time. That means treating the agent as a workload identity, not as a human user. Cryptographic identity, runtime policy checks, and just-in-time authorisation are more useful than static RBAC alone when behaviour is dynamic. Teams should evaluate whether the model can read, transform, or exfiltrate data across search, retrieval, and tool calls, then apply policy-as-code to block unsafe combinations before the action completes. NHI research consistently shows that secret sprawl and weak visibility amplify this problem, including findings in The State of Secrets in AppSec and 52 NHI Breaches Analysis.

• Use per-task credentials with short TTLs, not reusable long-lived tokens.
• Bind model actions to workload identity and evaluate policy on every sensitive request.
• Separate retrieval, summarisation, and write-back privileges so one prompt cannot cascade into broad access.
• Log tool calls, secret access, and downstream data movement, not just the user prompt.

These controls tend to break down when the agent is allowed to chain multiple tools across loosely governed SaaS and internal APIs because the permission boundary becomes fragmented faster than monitoring can follow.

Common Variations and Edge Cases

Tighter controls often increase latency and operational overhead, requiring organisations to balance leak prevention against workflow friction. That tradeoff becomes visible in environments where agents must search internal knowledge bases, call customer systems, and generate outputs in one session. Current guidance suggests there is no universal standard for this yet, so the safest pattern is to classify which actions are read-only, which can transform data, and which can write to external systems.

Edge cases also matter. A zero-click leak can occur even when no external attacker is present, for example when a model reproduces sensitive content from indexed documents or cached context. It can also appear as a compliant-looking action, such as a summary sent to an approved channel that still contains regulated data. Organisations should combine runtime controls with content classification and secret detection, but they should not assume classification alone will stop a model that already has access. That is why the breach patterns discussed in DeepSeek breach and broader secret hygiene research in The State of Secrets in AppSec remain relevant. The hardest cases are multi-agent systems with delegated tool use and weak auditability, because one model can leak data another model was never meant to see.

Related resources from NHI Mgmt Group

• What do organisations get wrong about data governance for AI?
• What do organisations get wrong about AI data retention?
• What do organisations get wrong about automated data classification?
• What do organisations get wrong about zero trust in hybrid work?