Google Gemini security exposes shared-responsibility governance gaps

At a glance

What this is: This analysis argues that Google Gemini security is a shared-responsibility problem, with the sharpest gaps appearing at runtime, where prompts, tool-connected agents, and unmanaged usage can outrun native controls.

Why it matters: It matters because IAM, NHI, and human identity teams now need to govern AI access, behavior, and data handling together instead of assuming provider controls cover production use.

By the numbers:

• 78% of employees bring their own AI tools to work, and some employees may paste sensitive company data into unapproved AI applications.
• The 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• The 2026 Infrastructure Identity Survey found that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems.

👉 Read WitnessAI's analysis of Google Gemini security and shared responsibility

Context

Google Gemini security is not a single control plane. It is a tiered set of protections that differs across Workspace, Gemini Enterprise, Vertex AI, and consumer access, which means teams cannot assume one governance model covers every deployment.

The primary issue is shared responsibility. Google secures the platform layer, but enterprises own permissions, agent behaviour, data classification, and regulatory compliance. That creates a familiar IAM problem with a new runtime shape, especially when AI systems can act on mail, documents, databases, and internal tools.

For identity teams, the key question is no longer whether Gemini has controls, but whether those controls are sufficient once an AI system becomes a non-human identity embedded in production workflows. The answer, in most environments, is that provider security is only the starting point.

Key questions

Q: How should security teams govern Gemini when it is connected to enterprise tools?

A: Treat each connected Gemini deployment as a governed non-human identity, not just a chat feature. Define the agent’s allowed data sources, tool permissions, logging requirements, and offboarding path. The key is to limit what the agent can do at runtime, then verify that the same scope is actually enforced in production.

Q: Why do AI agents complicate shared-responsibility models?

A: They complicate shared responsibility because the provider can secure the platform, but it cannot own the business decision to let an agent read mail, query systems, or trigger actions. Once behaviour is runtime-driven, the enterprise is accountable for permissions, content handling, monitoring, and regulatory fit.

Q: What breaks when organisations rely only on native AI safety controls?

A: Native controls often address configuration and content screening, but they do not fully govern what happens after an agent starts interacting with live tools and data. That leaves a gap between policy and behaviour, especially when prompt injection, Shadow AI, or unclassified data are involved.

Q: How do security teams reduce risk from Shadow AI in enterprise environments?

A: Start by discovering where employees use personal accounts or unsanctioned AI tools to access company data. Then enforce policy at the network and identity layers so unmanaged usage is visible, governable, and removable from the approved workflow.

Technical breakdown

Shared responsibility across Gemini tiers

Gemini security differs materially across product tiers, and that matters because each tier exposes a different mix of identity, data, and enforcement controls. Workspace editions inherit some enterprise controls such as DLP and audit logging, while Gemini Enterprise adds controls like VPC Service Controls and CMEK. Vertex AI introduces resource-level IAM for developers and ML teams. Consumer usage sits outside enterprise governance in ways that can create blind spots. The architectural problem is that a single organisation may have multiple Gemini entry points with different policy surfaces, logging depth, and data-use commitments.

Practical implication: Map each Gemini entry point to its own control set before assuming enterprise policy applies uniformly.

Agent identity, permissions, and runtime access

Once Gemini is connected to tools, it stops being just a chat surface and starts behaving like a non-human identity. That identity can read mailboxes, query data stores, or trigger downstream actions, which means access scope, credential handling, and lifecycle governance become identity problems, not only AI problems. The failure mode is over-privilege at runtime. If the agent can act more broadly than its actual task requires, prompt injection or manipulated content can redirect legitimate permissions into unintended outcomes.

Practical implication: Treat each tool-connected agent as a governed identity with explicit scope, auditability, and offboarding.

Prompt injection, Shadow AI, and control gaps at runtime

Google’s native controls are strongest at configuration time and weaker when behaviour changes inside a live session. Prompt injection exploits that gap by embedding malicious instructions in content Gemini retrieves from email, documents, or shared files. Shadow AI widens the problem because employees can use personal accounts or unsanctioned tools outside managed visibility. In practice, this means enterprise policy may look complete on paper while the actual AI activity path remains partially or wholly unobserved. Runtime enforcement and discovery are therefore separate requirements, not duplicate controls.

Practical implication: Combine sanctioned-use policies with telemetry that can see unmanaged AI activity and tool usage in real time.

Threat narrative

Attacker objective: The attacker wants to turn legitimate Gemini access into unintended data exposure or harmful downstream action without needing to break the underlying platform.

1. Entry occurs when a user or agent ingests malicious content through email, documents, calendar items, or other retrieved sources that Gemini processes as part of normal workflow.
2. Credential access or abuse happens when the connected agent uses its legitimate permissions to read data, query systems, or take actions that were never intended for the triggering content.
3. Impact follows when the redirected agent exposes sensitive information, performs unintended actions, or propagates the injected instruction through connected enterprise workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Google Gemini security is really a governance boundary problem, not a model-security problem. The platform can secure infrastructure, encryption, and some access controls, but it cannot decide how an enterprise wants to govern agent behaviour once tools, mail, and data sources are connected. That boundary sits with the organisation, not the provider. Practitioners should treat Gemini as a governed identity surface, not a self-contained security product.

Agent identity now belongs in the same control conversation as service accounts and privileged users. When Gemini can read, write, and trigger actions, it is operating as a non-human identity with real blast radius. The control failure is not simply excessive access. It is that many programmes still do not model AI agents as durable identities requiring lifecycle control, audit trails, and role boundaries. The implication is that AI governance and NHI governance are converging faster than most operating models.

Runtime enforcement is the named gap: prompt-side filtering alone does not govern behaviour after a tool call begins. Native screening can help, but it does not continuously inspect whether an agent is moving from approved intent to unintended action in-session. That gap is why shared responsibility becomes operationally thin in production. Practitioners should rethink whether configuration-time controls are being mistaken for runtime governance.

Shadow AI creates a second identity governance problem outside the managed tenancy. Even strong enterprise controls do little when users access Gemini through personal accounts or unsanctioned tools. That leaves security teams with two parallel policy worlds: one visible, one opaque. The practitioner consequence is that identity governance must extend beyond approved tenants and into discovery of unmanaged AI usage.

Prompt-side trust assumptions: they were designed for content that could be screened before execution. That assumption fails when the actor is an AI system that retrieves external content, interprets it dynamically, and can trigger actions across connected tools. The implication is that security review models built for static requests no longer match the timing and agency of AI workflows.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• A separate finding in the same survey shows that 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
• For a broader view of how fast this category is shifting, see Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Prompt-side trust assumptions: many enterprise AI programmes still behave as if content can be screened before it becomes action. That model is already under strain, and the programme implication is clear: governance has to move from static approval to runtime observation, especially where agents can reach mail, documents, and connected systems.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the access model itself is becoming the risk. Identity teams should expect pressure to justify why AI permissions are broader than human equivalents.

The practical signal for security teams is that Gemini governance will increasingly be judged on observable behaviour, not contract language. If you cannot see which tools an AI system used, which data it touched, and which account it used to act, your control story is incomplete.

For practitioners

• Map Gemini tiers to control ownership Inventory Workspace, Gemini Enterprise, Vertex AI, and any consumer entry points separately. Assign control owners for IAM, DLP, logging, and data-use terms so no deployment inherits policy by assumption.
• Classify connected agents as non-human identities Give each tool-connected agent a defined identity, least-privilege scope, and offboarding path. Include service ownership, token handling, and review cadences in the same inventory used for other machine identities.
• Add runtime monitoring for prompt and tool behaviour Use telemetry that can detect prompt injection, abnormal tool calls, and sensitive data movement during live sessions. Configuration reviews alone will not catch behaviour that emerges after a model receives new context.
• Control Shadow AI outside managed accounts Discover personal-account use, unsanctioned agents, and external AI tools that interact with corporate data. Pair discovery with policy enforcement so users cannot bypass enterprise controls simply by switching identity surface.

Key takeaways

• Google Gemini security exposes a shared-responsibility gap because platform protections do not govern agent behaviour once tools and data sources are connected.
• The main risks are prompt injection, Shadow AI, and over-privileged AI identities that can reach sensitive data or trigger unintended actions.
• Enterprises need runtime monitoring, scoped agent identities, and tier-by-tier control validation to make Gemini governable in production.

Key terms

• Shared responsibility model: A shared responsibility model divides security obligations between the platform provider and the enterprise customer. For AI systems, the provider may secure infrastructure and baseline services, while the organisation remains responsible for access scope, data handling, runtime behaviour, and compliance in its own deployment.
• Shadow AI: Shadow AI is the use of AI tools, models, or agents outside approved enterprise governance. It includes personal accounts, unsanctioned applications, and hidden integrations that can expose sensitive data and bypass logging, policy enforcement, and lifecycle controls.
• Agent identity: Agent identity is the set of permissions, credentials, and governance controls assigned to an AI system that can take actions on behalf of a business process. Unlike a simple application account, it must be managed as a non-human identity with scope, review, and offboarding discipline.
• Runtime governance: Runtime governance is the control of AI behaviour while a model or agent is actively processing prompts, data, and tool calls. It matters because configuration-time controls cannot fully predict live decisions, so security teams need enforcement and monitoring that operates during execution.

Deepen your knowledge

Google Gemini security and AI agent governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already supporting AI-connected workflows, it is a practical next step.

This post draws on content published by WitnessAI: Google Gemini security and the enterprise shared-responsibility model. Read the original.