Google Gemini incident shows the AI identity control gap

At a glance

What this is: This is an analysis of the Google Gemini calendar-invite incident and its finding that AI systems can expose data through legitimate permissions when context and intent are not controlled.

Why it matters: It matters because IAM teams now have to govern autonomous AI behavior, not just access grants, when AI services can read, write, and chain actions across systems.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Unosecur's analysis of the Google Gemini identity security incident

Context

The Google Gemini incident is a good example of why AI identity governance cannot stop at permission checks. An AI service can be fully authorized and still become a data-exposure path when it reads untrusted content, interprets it as instruction, and writes the result into another system.

In this case, the security gap was not classical compromise. It was a failure to control context, intent, and downstream action for an identity that could already read and write across systems. For IAM teams, that is the same structural problem emerging across AI agents, workflow automations, and other non-human identities.

That starting position is becoming more typical, not less, as enterprises embed AI into everyday business workflows.

Key questions

Q: How should security teams govern AI services that can read and write across systems?

A: Treat them as non-human identities with scoped permissions, explicit owners, and reviewable tool access. Do not rely on a single authorization check. Require policy controls for the combination of inputs, actions, and destinations, especially where untrusted content can influence a downstream write or share operation.

Q: What is the difference between access control and intent governance for AI agents?

A: Access control answers whether an identity is allowed to do something. Intent governance asks whether the action makes sense in the current context and whether the input driving that action is trustworthy. For AI agents, both are necessary because legitimate permissions can still be abused through malicious content.

Q: When does AI identity risk become a data-exposure problem?

A: It becomes a data-exposure problem when an AI can combine read access, reasoning, and a write path into another system. At that point, a malicious prompt or poisoned input can move sensitive information across boundaries without credential theft or a classic exploit.

Q: Why do AI agents complicate zero trust architecture?

A: AI agents complicate zero trust because they continuously process content, call tools, and chain permissions rather than making a single access decision. Zero trust still applies, but it must extend to context, content provenance, and the safety of each action the agent takes.

Technical breakdown

Indirect prompt injection in calendar workflows

Indirect prompt injection occurs when an attacker hides instructions inside content that an AI later reads as part of a legitimate task. In this incident, the calendar invite carried malicious text in metadata, not code or malware. When Gemini processed the invite to answer a user query, it treated the hidden language as relevant context and incorporated it into the response path. The key architectural issue is that the model cannot reliably separate trusted instructions from adversarial data once both are mixed in the same context window. Practical implication: treat any externally supplied content that can influence AI output as untrusted input, even when it arrives through normal business systems.

Practical implication: Segment untrusted content from agent instructions and restrict which fields AI services are allowed to parse.

Why IAM authorization was not enough

Traditional IAM answers whether an identity has permission to read data or create records. That is necessary, but insufficient for AI services that can chain those permissions into a multi-step action. In the Gemini case, the AI had legitimate rights to read calendar data and create calendar events, so the access check passed. What IAM did not evaluate was whether combining those rights in that context would expose sensitive information. This is the gap between entitlement and intent. Practical implication: add context-aware policy checks around high-risk AI actions, especially where one read can trigger a write or forward data into another system.

Practical implication: Map AI permissions as action chains, not isolated entitlements, before allowing cross-system workflows.

Context and memory as attack surfaces for AI agents

AI systems expand the attack surface from files and endpoints to context, memory, and orchestration. A prompt can now arrive through a document, calendar event, message thread, or API payload and influence later decisions. That makes the reasoning layer a security boundary, not just the transport layer. For NHI governance, the important point is that AI agents behave like identities with execution authority, so their inputs, tool calls, and outputs all need policy and logging. Practical implication: instrument AI services with behavioral baselines, audit trails, and step-up controls for sensitive tool use.

Practical implication: Monitor tool calls and output destinations so abnormal cross-service behavior is visible early.

Threat narrative

Attacker objective: The attacker’s objective was to use the AI system as a relay for sensitive calendar data without stealing credentials or triggering a conventional security alert.

1. Entry occurred when the attacker embedded hidden instructions inside a legitimate-looking calendar invite.
2. Escalation happened when Gemini ingested the malicious text while processing a normal scheduling query and turned it into action.
3. Impact followed when the AI wrote private schedule information into a new calendar event that could be exposed to the attacker in some configurations.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity governance for AI now has a context problem, not just an authorization problem. The Gemini incident shows that an AI identity can remain fully permitted while still producing unsafe outcomes. That changes the security question from who can act to when and under what context action is acceptable. Practitioners should treat intent governance as part of IAM design, not as an optional layer.

Context-aware control is the missing control plane for agentic systems. When an AI can read untrusted text, reason over it, and write to another service, the boundary between data and instruction disappears. That creates an identity blast radius problem where one hidden prompt can influence multiple downstream systems. Security teams should define which inputs, tools, and outputs are allowed to interact before agent autonomy expands.

AI services should be governed as non-human identities with execution risk. The failure mode here is not limited to chat assistants. Any workflow automation, summarizer, or agent that can chain permissions across systems inherits the same exposure. That makes identity visibility, action logging, and least privilege mandatory baseline controls. Teams that still treat AI as a feature rather than an identity class will miss the real risk.

Blast-radius control is the decisive control objective for AI identity security. Once an AI service can transform benign access into unintended disclosure, the priority shifts to limiting where data can go, not just whether it can be touched. That means tighter scopes, output filtering, and step-up approval for sensitive cross-system actions. Practitioners should measure control maturity by how much damage one compromised workflow can cause.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to our research.
• For a broader view of real compromise patterns, see 52 NHI Breaches Analysis, which shows how identity abuse repeatedly turns routine access into incident scope.

What this signals

Identity blast radius: AI-driven workflows widen the damage from a single identity because read permissions can be converted into unintended disclosure through downstream writes. For programme owners, the control objective shifts to limiting where data can flow after it is processed, not just whether it can be accessed. That is where NHI governance becomes operational rather than theoretical.

With 92% of organisations exposing NHIs to third parties, the enterprise problem is no longer isolated internal automation. External data sources, shared calendars, and connected collaboration tools can all become part of the same trust chain, so teams need to map data provenance as carefully as privilege.

Security teams should now expect AI systems to behave like high-privilege NHIs with unusual input sensitivity, and they should plan monitoring accordingly. Context-aware detection, approval gates for sensitive tool calls, and strict output controls are becoming baseline requirements for any agent that can cross application boundaries.

For practitioners

• Classify AI services as governed identities Inventory every AI workflow that can read, write, or forward data across systems, then assign ownership, scope, and review cadence for each identity.
• Restrict cross-system write paths Limit AI services so a read action cannot automatically trigger a write into another system unless the destination, data class, and approval path are explicitly allowed.
• Add context-aware policy checks Require policy evaluation for sensitive tool use, especially when untrusted content can influence output, and log the exact input source behind each decision.
• Build behavioral baselines for agent activity Track normal patterns for query types, tool calls, and output destinations so deviations such as unusual cross-service actions can be reviewed quickly.
• Tighten access reviews around AI-connected data paths Review calendar, inbox, document, and API integrations together because the risk often emerges from combinations of legitimate permissions rather than a single exposed secret.

Key takeaways

• AI identity risk is no longer confined to stolen credentials because legitimate permissions can still produce unintended disclosure.
• The scale of NHI exposure remains high, with 96% of organisations storing secrets outside protected managers and 71% failing to rotate many NHIs on time.
• Practical defence now means governing context, tool chaining, and blast radius, not only checking whether an identity is authorised.

Key terms

• Indirect Prompt Injection: A form of attack where malicious instructions are hidden inside ordinary content that an AI later reads and treats as relevant guidance. The content can appear in emails, calendar events, documents, or chat messages, and the risk emerges when the model cannot separate user data from system intent.
• AI Identity: An AI identity is a non-human identity assigned to an autonomous software entity with execution authority and tool access. It may read data, call APIs, write records, or trigger workflows, which means it must be governed like any other privileged machine actor, not treated as a feature toggle.
• Context Governance: Context governance is the practice of controlling which inputs, prompts, and data sources an AI system can interpret as decision material. It focuses on preventing untrusted content from shaping privileged actions, especially when an AI can chain permissions across multiple applications.

What's in the full article

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

• How the vendor maps AI services to identity visibility, monitoring, and response workflows.
• The checklist used to assess AI and automation identities across access paths and audit trails.
• The operational framing for context-aware oversight when permissions are technically valid but behavior is risky.
• Practical remediation examples for reducing blast radius in identity-connected AI workflows.

👉 Unosecur's full post covers the identity checklist, behavior monitoring approach, and remediation framing.

Deepen your knowledge

AI identity governance and context-aware access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to govern AI services as identities, it is worth exploring.