Google Gemini incident shows the AI identity control gap

At a glance

What this is: This is an analysis of the Google Gemini incident, where indirect prompt injection in a calendar invite caused private data exposure even though the AI operated within granted permissions.

Why it matters: It matters because IAM, PAM, and NHI governance teams now have to account for context and intent, not only who or what is authorized to access a resource.

👉 Read Unosecur's analysis of the Google Gemini AI identity control gap

Context

The Google Gemini incident shows a control gap that traditional IAM models do not cover: an identity can be authorized to read and write data yet still be unsafe to trust with untrusted language context. That breaks the assumption that permissions alone define safe behaviour for AI systems.In this case, the issue sits squarely in AI identity governance. Gemini had legitimate access to calendar data and calendar creation, but malicious instructions embedded in a calendar invite changed how that access was used.

The attack path did not depend on malware, stolen credentials, or a permission escalation event. It depended on hidden instructions inside ordinary content, which the AI later treated as operational input. That makes the incident relevant to organisations governing AI services as identities, especially where those services read from one system and write to another.

Key questions

Q: What breaks when an AI service is authorized but still unsafe to trust?

A: Static authorisation breaks down when the service can interpret untrusted language and chain legitimate actions into an unintended outcome. The identity may remain within permission boundaries while still exposing data or creating side effects that were never explicitly approved. Practitioners need controls for context, provenance, and action sequencing, not only entitlement checks.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What are the signs that prompt injection is affecting identity-controlled workflows?

A: Look for unexpected cross-system writes, summaries that contain attacker-supplied wording, output that reveals data not asked for, and action sequences that do not match the user’s intent. The clearest signal is when a legitimate AI identity behaves normally from an entitlement perspective but produces an unsafe data path.

Q: How should teams govern non-human identities in AI-heavy environments?

A: Teams should govern non-human identities the same way they govern other privileged assets: assign ownership, minimise scope, rotate credentials regularly, and monitor for abnormal use. The key difference is speed. AI-driven workflows can exploit exposed access quickly, so detection and revocation must be automated and tied to lifecycle controls.

Technical breakdown

How indirect prompt injection turns content into instruction

Indirect prompt injection happens when untrusted text is embedded in data the model is expected to process, such as a calendar description, email body, or document. The AI does not need to be tricked into executing code. It only needs to interpret the embedded language as part of its task. That is why the attack is semantic rather than technical in the traditional malware sense. The model receives valid input, but the input contains hidden instructions that alter its reasoning and output. In workflow terms, the dangerous moment is not authentication. It is interpretation.

Practical implication: classify any user-supplied content that an AI reads as untrusted instruction-bearing input, not as benign data.

Why normal IAM authorisation did not stop the exposure

IAM answers whether an identity can perform an action. It does not answer whether the action is appropriate in a given context. In the Gemini case, the AI was allowed to read calendar data and create calendar events, so the security stack saw expected behaviour. The failure emerged because those permissions were chained together under attacker-controlled context. This is a classic governance blind spot for AI services that can transform information from one boundary into another without a human reviewing the intermediate step.

Practical implication: review read-write permission chains for AI services and decide where context checks must sit between those actions.

Why context governance becomes part of identity security

Context governance is the discipline of deciding whether an identity should act now, with this input, in this state. For autonomous or AI-mediated systems, that means the control surface extends beyond static permissions into prompt hygiene, data provenance, and action gating. The Gemini incident shows that an AI can remain within authorised scope and still create an unsafe outcome by combining legitimate capabilities in the wrong sequence. That is why identity security for AI services has to include behavioural oversight, not just entitlement review.

Practical implication: add context-aware approval, filtering, or containment controls around AI actions that can move data across systems.

Threat narrative

Attacker objective: The attacker aimed to make private calendar data surface in a form and location that could be observed outside the intended trust boundary.

1. Entry occurred through a legitimate-looking calendar invite that contained hidden instructions inside the event description.
2. The AI later processed that untrusted text while responding to a normal schedule query, which let the hidden prompt influence the output.
3. Gemini wrote the summarised private information into a new calendar event, creating an exposure path that could be visible to an attacker in some configurations.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context, not entitlement, is now part of identity governance for AI services: This incident shows that a system can be fully authorised and still unsafe if it processes attacker-controlled context. Traditional IAM proves access, but not intent, data provenance, or safe sequencing. The practitioner conclusion is that AI identity governance has to treat context as a control boundary, not a commentary layer.

Language has become an execution surface: The important shift is not that the model misbehaved, but that ordinary text changed the effective action path of a legitimate identity. That makes prompt injection an identity-security problem as much as an AI-safety problem. The practitioner conclusion is that untrusted language must be governed wherever AI reads and reuses it.

AI services expose an identity control gap when they can chain read and write permissions: The Google Gemini case shows how an identity can stay inside its granted scope while still producing an unsafe result. That is why entitlement review alone is incomplete for AI services that can transform input into output across systems. The practitioner conclusion is to govern the chain, not just the permission.

Access review processes do not capture unsafe contextual behaviour: Identity review tells you what an AI service can do, not how it will combine those privileges when prompted by hostile content. That is a structural limitation, not an implementation bug. The practitioner conclusion is that review cadences must be complemented by runtime controls over AI-mediated actions.

Context-driven privilege drift: The incident illustrates a new failure mode in which a static permission set remains unchanged while the meaning of those permissions changes at runtime because of attacker-supplied language. That is a distinct governance problem, and practitioners should treat it as such when designing AI identity controls.

What this signals

AI identity governance now has to include contextual trust decisions: If an AI service can read untrusted text and write to another system, the security question is no longer only whether the action is permitted. It is whether the action should be allowed in that context, with that input, and at that moment. That is a programme design issue, not a model-tuning issue.

Prompt injection exposes the limits of entitlement-centric thinking: The incident shows that permission sets can remain technically correct while the resulting behaviour is still unsafe. Teams that govern non-human identities need runtime guardrails around content provenance, action chaining, and downstream data release.

Identity blast radius is now a practical AI control concept: The value of limiting an AI service is not just least privilege in theory. It is reducing how far a single unsafe prompt can propagate across systems before anyone notices.

For practitioners

• Govern AI services as first-class identities Inventory AI systems alongside service accounts, APIs, and other non-human identities, then document exactly which systems they can read from and write to.
• Separate read and write paths for AI workflows Where possible, prevent the same AI service from both consuming untrusted content and creating externally visible records without an intermediate control point.
• Treat untrusted prompts as hostile input Apply content filtering, provenance checks, or isolation steps to calendar invites, emails, documents, and other text that an AI may parse as instructions.
• Add context checks before data is re-emitted Require an approval, policy evaluation, or containment step before AI-generated summaries or extracted data are written into shared systems.
• Expand audit trails for AI-mediated actions Record source content, prompting context, downstream writes, and identity path so investigators can reconstruct how legitimate permissions produced an unsafe outcome.

Key takeaways

• The Gemini incident shows that AI systems can expose data while remaining inside granted permissions, which makes context a governance issue rather than a pure access-control issue.
• The attack worked through hidden instructions in ordinary calendar content, proving that untrusted language can become an effective execution path for AI-mediated workflows.
• Practitioners should govern AI services as identities with constrained read-write chains, runtime context checks, and audit trails that capture how legitimate access becomes unsafe behaviour.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Session Governance: The practice of binding access to a specific task, time window, and execution context, then revoking it when the work is done. For non-human identities, session governance matters because tokens and delegated permissions often persist longer than the action they were created to support.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• AI Identity Scope: The set of resources, tools, and credentials an AI system can access in order to complete a task. Proper scope is narrower than generic user access because autonomous systems can chain actions quickly, making overbroad permissions far more damaging than in human-only workflows.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of how the malicious calendar invite influenced Gemini's reasoning path
• Unosecur's recommended visibility and behavioural monitoring approach for AI services
• Examples of context-aware oversight and audit logging for identity actions in AI workflows
• Practical guidance on reducing blast radius when AI systems can read and write across services

👉 The full Unosecur post covers the attack path, governance gap, and identity monitoring implications in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.