Google Gemini security exposes shared-responsibility governance gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WitnessAI's blog post: Google Gemini security across product tiers has the hardest risks in shared-responsibility gaps around permissions, agent behaviour, Shadow AI, and runtime enforcement.

Why it matters: IAM, PAM, and AI governance teams need to verify where provider controls stop so they can govern non-human identities, tool access, and data exposure consistently across deployments.

Context

Google Gemini security is a shared-responsibility problem, not a single product setting. Gemini now spans Workspace, Vertex AI, and enterprise agent platforms, which means the same AI brand can sit behind very different access models, data handling commitments, and control boundaries.

The governance gap appears when teams assume provider controls cover prompts, tools, and runtime behaviour. In practice, enterprises remain responsible for permissions, agent actions, Shadow AI usage, and whether deployments satisfy internal and regulatory requirements across each tier.

For identity and access teams, the key question is not whether Gemini has security features. It is which controls stay with the vendor, which controls sit with the enterprise, and how much behavioural risk is left outside traditional IAM, DLP, and logging models.

Key questions

Q: What breaks when organisations assume Gemini’s native controls cover all AI security risks?

A: The failure is a boundary mistake. Provider controls may cover parts of the platform layer, but they do not automatically govern prompt injection, tool-connected agent behaviour, unmanaged accounts, or deployment-specific compliance obligations. Enterprises still need their own configuration, monitoring, and decision controls for runtime AI activity.

Q: Why do Gemini deployments increase governance risk in enterprise IAM programmes?

A: Because the same AI brand can sit behind different tiers, different data commitments, and different access patterns. IAM teams must treat each deployment as a separate governance surface and verify who can access it, which tools it can call, and whether the configuration matches policy and regulatory requirements.

Q: What signs indicate that Gemini agents are operating outside intended control boundaries?

A: Look for unexpected tool calls, sensitive data appearing in prompts or outputs, unmanaged personal logins, and agent actions that were not explicitly approved by the enterprise. Those signals suggest the control model is too narrow for the way Gemini is being used in production.

Q: What should teams do when AI behaviour is changing faster than their access reviews?

A: Move the control point earlier. Access reviews are too slow if an agent can request, use, and discard access inside a live workflow. Teams should govern issued permissions, runtime actions, and telemetry together so behaviour is visible while it is still actionable.

Technical breakdown

Why Gemini tiering creates uneven security control coverage

Gemini is not one uniform control plane. Workspace, Business, Enterprise, consumer, and Vertex AI deployments each carry different security promises, which changes how data residency, DLP, logging, VPC perimeters, and training commitments apply. That matters because security posture is not inherited automatically from the brand name. It has to be validated per edition, per contract tier, and per workload. In identity terms, the enterprise must know which permissions are enforced centrally and which are only expressed in local configuration or policy documents. The practical risk is that teams treat a product family as one governance domain when it is really several.

Practical implication: Map every Gemini deployment to its exact tier and contract before assuming any control, training, or compliance commitment applies.

How agentic Gemini turns access into an identity problem

Once Gemini can read mail, query databases, create calendar entries, or trigger downstream actions, it stops behaving like a passive application and starts acting through delegated identity. That means the security question shifts from user access alone to scoped non-human identity, auditable credentials, and lifecycle oversight for agents. If an agent can act on content it retrieves, prompt injection and malicious instructions become access problems as much as content problems. The failure mode is not merely data exposure. It is uncontrolled action taken under legitimate authorization paths that were never designed for autonomous or semi-autonomous behaviour.

Practical implication: Treat tool-connected Gemini agents like governed non-human identities, not like ordinary application features.

Why prompt injection exposes a runtime governance gap

Prompt injection matters because it targets the decision layer rather than the perimeter. When malicious instructions arrive inside emails, documents, calendar invites, or shared files, the model may process them as if they were legitimate context. If the connected system then allows tool use, the injected instruction can cascade into real actions. Native screening helps only when it is actually enabled and tuned for the environment, and even then it usually does not provide complete visibility into behavioural intent. The technical gap is that traditional security controls were built to inspect data and access, not to continuously arbitrate model behaviour while the session is in motion.

Practical implication: Add runtime inspection and policy enforcement where prompts, tool calls, and outputs interact.

Breaches seen in the wild

• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.
• 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 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared-responsibility AI security creates a governance gap, not just a control gap. Google secures the infrastructure and some platform functions, but the enterprise still owns permissions, agent behaviour, and regulatory fit. That division matters because AI risk emerges at runtime, where prompts, tools, and content interpretation meet business data. The implication is that AI security programmes must be designed around responsibility boundaries, not just feature checklists.

Gemini agents should be governed as non-human identities. Once a Gemini deployment can act on mailboxes, databases, calendars, or internal systems, it behaves like a delegated executor rather than a static application. That makes identity scope, lifecycle, and auditability central to the control model. Enterprises that keep treating agentic access as ordinary application configuration will miss the governance burden created by runtime action.

Runtime governance gap: the core failure is assuming provider controls extend into behaviour. That assumption works for infrastructure security, but it fails when prompts can redirect tool use, data can be transformed at runtime, and Shadow AI sits outside managed policy boundaries. The practical consequence is that the enterprise needs a separate control layer for observation, decisioning, and enforcement across AI activity.

Shadow AI turns an AI governance issue into an identity inventory problem. The article’s risk picture is not limited to managed Gemini tenants. Unapproved accounts, unmanaged usage, and personal-logins create blind spots that security teams cannot cover with enterprise-only policy. The implication is that discovery and policy enforcement must extend beyond sanctioned apps to the actual AI usage surface.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.

What this signals

Runtime control has become the deciding layer for enterprise AI. When prompts, tools, and data all meet inside a live session, the question is no longer whether a platform is secured in principle. The question is whether the enterprise can observe and constrain what the system actually does with trusted access.

AI governance now depends on identity discipline as much as model safety. If a Gemini deployment can reach mail, calendars, or databases, it should be governed like a delegated non-human executor with scoped permissions, lifecycle review, and behavioural monitoring. That shift is already underway across enterprise AI programmes.

Security teams should expect more pressure to prove where the vendor’s responsibility ends and the enterprise’s control begins. In practice, that means mapping AI usage, validating contract tiers, and extending policy enforcement beyond sanctioned tools to the actual runtime surface.

For practitioners

• Verify the Gemini contract tier Confirm whether each deployment sits under Workspace Business, Enterprise, consumer terms, or Vertex AI rules before assuming training restrictions, data handling commitments, or logging expectations apply.
• Map agent permissions explicitly Document every mailbox, database, calendar, and downstream tool that a Gemini agent can touch, then review those permissions as a non-human identity scope rather than a simple app setting.
• Test for prompt injection at runtime Use malicious content scenarios in emails, documents, and shared files to verify whether Gemini can be pushed into unintended tool calls or data disclosure during live workflows.
• Extend discovery to Shadow AI Identify personal accounts, unsanctioned agent use, and unmanaged AI applications that sit outside enterprise controls so policy coverage reflects actual usage rather than approved inventory.
• Add runtime monitoring for AI actions Instrument prompt, response, and tool-call telemetry so security teams can see when AI behaviour changes inside a session and intervene before sensitive data or privileged actions move further.

Key takeaways

• Gemini security is fragmented across product tiers, which makes shared responsibility a governance problem rather than a simple feature question.
• The highest-risk issues are not platform hardening alone but prompt injection, tool-connected agent behaviour, and Shadow AI outside managed visibility.
• Enterprises need runtime monitoring, scoped identity controls, and verified contract terms if they want AI usage to stay inside policy and regulatory boundaries.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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.