Gemini Enterprise Security: What VPC-SC, CMEK, and IAM Leave Open

Three Google Cloud controls get folded into one "is Gemini Enterprise secure" conversation more often than they should. VPC Service Controls draws a network perimeter around Gemini Enterprise and Vertex AI resources. Customer-managed encryption keys put the enterprise, not Google, in control of the encryption material that protects data at rest. IAM roles decide which principal can call which Gemini Enterprise API. Each does its job. None of the three asks whether this specific authenticated user, sending this specific prompt, right now, should be allowed to reach this specific model.

I want to walk through what each control actually secures, then the request-level question that sits underneath all three.

TL;DR

• VPC Service Controls creates a network and API perimeter around Gemini Enterprise and Vertex AI, blocking data exfiltration paths outside the boundary.
• CMEK gives the enterprise control over the encryption material protecting stored data, including the ability to revoke it.
• IAM roles gate which principal can call which Gemini Enterprise API operation, but a shared service account authorizes every request it makes on behalf of every user behind it.
• None of the three evaluates a live prompt against the specific authenticated caller's role and the classification of the data in that prompt.

VPC Service Controls draws a perimeter, not a per-request decision

VPC Service Controls lets an organization define a service perimeter around Gemini Enterprise, Vertex AI, and other Google Cloud APIs, then block API calls and data movement that would cross that boundary from an unauthorized network or project. Traffic inside the perimeter can reach the Gemini Enterprise API. Traffic outside it, or an attempt to copy data to a project outside the perimeter, gets denied at the network layer.

That is a real defense against exfiltration through an unapproved path, and it operates below the level of any individual prompt. A perimeter evaluates where a request originates and where data would land. It does not evaluate who is behind the request once that request is already inside the perimeter, what role that person holds, or whether the specific text in that prompt should be permitted to reach the model at all. Every caller inside the perimeter gets the same answer: allowed to cross the boundary. VPC Service Controls, like any network perimeter, secures the edge. It has nothing to say about what happens once a request is already standing inside it.

CMEK controls encryption material, not the caller

Customer-managed encryption keys let an enterprise generate and manage the encryption material that Google Cloud uses to encrypt data at rest for Gemini Enterprise and related services, through Cloud KMS. The enterprise can rotate the material, restrict who can use it through IAM bindings on the material itself, and revoke it, which renders the encrypted data unreadable even to Google.

CMEK answers a specific and important question: who controls the cryptographic material protecting stored data. It does not answer a different question entirely, which is who should be permitted to send a given prompt to the model in the first place. A user with legitimate access to an application that calls Gemini Enterprise can submit a prompt containing data they were never authorized to share, and CMEK will encrypt that prompt's stored artifacts correctly regardless. Encryption control and request authorization operate at different layers of the stack, and CMEK only ever touches the first.

IAM authorizes the role, not the person acting through it

IAM roles and permissions determine which principal can call the Gemini Enterprise or Vertex AI API, invoke a specific model, or manage a specific resource. This is the correct mechanism for coarse-grained access: which team's service account can reach which endpoint, which project can provision which model.

It is also, by construction, role-level rather than person-level. Most enterprise applications built on Gemini Enterprise call the API through one shared service account that serves every end user of that application. IAM's authorization decision happens once, when the service account is granted the role, not once per request for the specific employee the application is currently acting on behalf of. That gap is the same one I described in the post-authentication gap: the credential is authenticated, but the specific request made with that credential, on behalf of a specific person, was never separately evaluated. A compliance reviewer who asks "which employee authorized this exact AI decision" gets an IAM audit trail naming a service account, not a name.

The request-level gap underneath all three

Stack VPC Service Controls, CMEK, and IAM together and the result is a network perimeter, enterprise-controlled encryption material, and coarse authorization on which service account can call the API. None of the three evaluates the combination that actually determines whether a given AI interaction is safe: this authenticated user, this data classification, this model, this policy, right now. I think that gap gets missed in vendor security reviews more often than any other, mostly because each control looks complete when you read its documentation in isolation and nobody draws the request path across all three at once. Why AI security must be inline covers the broader version of this: a decision made after a log review can only explain a request, not stop it.

The same gap shows up on the audit side. Native Gemini Enterprise logging records API calls, but reconstructing which specific person triggered a specific model response, under which policy, is a separate exercise. I cover what that logging captures and where it stops in Gemini Enterprise audit logs.

What request-level authorization actually requires

Closing this gap means evaluating four things before a prompt reaches the model, not after: the authenticated identity behind the call, not just the service account making it; the role and entitlements attached to that identity; the data classification of the specific prompt; and a policy decision, permit, redact, or deny, made against all three in real time. Zero-trust architecture for LLM traffic applies the same "never trust, always verify" principle Google's own BeyondCorp model popularized for internal networks to AI requests specifically. An identity-aware AI gateway is the architectural pattern that sits inline and makes that per-request decision instead of a perimeter, encryption material, or a role grant making it by proxy.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline in front of Gemini Enterprise, Vertex AI, or any other HTTP-based LLM endpoint the same organization uses, as a stateless proxy. Every request is evaluated against the identity context the calling application supplies, the role behind that identity, and the classification of the prompt, before the request reaches Google's model. The decision is recorded in a signed, tamper-evident audit entry tied to the actual authenticated person, not the shared service account that made the underlying API call.

VPC Service Controls, CMEK, and IAM stay exactly as useful as they are today, and none of that work gets thrown away. DeepInspect adds the layer none of them were built to provide: a per-request, identity-bound policy decision, made independently of how the Google Cloud project itself happens to be configured that week.

Book a demo today.