Vertex AI Security: Five Native Controls and the Request Gap

Google now calls Vertex AI Platform Gemini Enterprise Agent Platform. The official name-change page also renames the Vertex AI API and Vertex AI Studio, though the old search term will persist in architecture diagrams and procurement records. The security mechanism is layered: IAM authorizes access to Google Cloud resources, VPC Service Controls constrains service perimeters, encryption protects stored data, and provider settings govern supported locations plus retention behavior. I want to separate those controls from the authorization decision on one AI HTTP request.

TL;DR

• Vertex AI security is now documented under Gemini Enterprise Agent Platform, previously Vertex AI Platform.
• Google lists data residency and customer-managed encryption keys, plus VPC Service Controls and Access Transparency, as separate control dimensions with model-specific support.
• Zero data retention depends on feature configuration, including logging and grounding, plus abuse monitoring and session behavior.
• Caller-aware request policy is on the routed HTTP path when a shared workload identity hides the originating user or agent.

The product name changed while the control layers remained

Google's terminology change deserves immediate treatment because a reviewer can otherwise compare a legacy contract against the wrong current documentation. Vertex AI Platform is now Gemini Enterprise Agent Platform. Generative AI on Vertex AI is now Generative AI on Gemini Enterprise Agent Platform, and Vertex AI Studio is now Agent Studio on that platform. The renamed pages are the current source of truth for control support.

That change affects evidence collection more than architecture. An inventory should preserve the old service label found in Terraform or invoices, as well as risk registers, while adding the current product name and documentation URL. Put both labels on the same row. A diagram with "Vertex AI" printed in a gray box is understandable, provided the control owner records the current API and model, plus the project and location that are in the box.

The opinion I would defend in review is blunt: a product-family name should never be a security boundary. Control support is tied to the exact model and operation, backed by current documentation and a live configuration check.

Google publishes a model-specific control matrix

Google's generative AI security controls page separates data residency at rest and customer-managed encryption keys from VPC Service Controls and Access Transparency. The table is granular. Support can differ for a model or tuning operation, as well as a batch job or cached content. It can also differ for a search operation. Google also states that the controls listed on that page are unavailable for preview models.

That structure should shape the review worksheet. Record the model identifier and lifecycle state. Add the operation and project, plus the location and service perimeter. Also add the encryption-key assignment and provider-access evidence. Then test the deployed combination. A platform-level statement such as "CMEK enabled" lacks enough resolution when one operation uses a different storage path or a preview model is outside the documented matrix.

VPC Service Controls and IAM are valuable. The perimeter restricts access to supported Google services and helps control data movement around the project boundary. IAM grants principals permissions on resources. Access Transparency can provide visibility into supported provider access. Each artifact proves its own control rather than a universal approval for prompt content.

Retention depends on configuration

Google states in its zero data retention documentation that customer data is not used to train or fine-tune AI or ML models without prior permission or instruction. The same page makes retention a configuration exercise. Abuse monitoring and grounding, plus request-response logging and caching, can create distinct data-handling paths. The same is true for specific API capabilities.

Request-response logging is described as disabled by default. When a customer enables it for a model and project, requests and responses are written to the designated BigQuery table. Google advises leaving request-response logging disabled where zero data retention is required. Gemini Live API session resumption supplies another concrete case: explicitly enabling it stores cached session data for up to 24 hours.

A defensible review therefore traces the actual feature path. Start with one request and mark every storage point in red on the architecture diagram. Include provider-side behavior and customer-configured BigQuery logging, plus grounding sources and caches. Include the application's own telemetry as well. "Zero retention" should appear only after those paths have been checked against the deployed operation.

Project access and request authorization answer different questions

A backend may call the Gemini Enterprise Agent Platform API with a Google Cloud service account shared across an internal application. IAM can correctly authorize that service account. The project can also be inside a VPC Service Controls perimeter and use a customer-managed key. An employee then asks the application to summarize a document containing acquisition terms intended for a smaller deal team.

The request needs context beyond project access: the initiating employee or agent and their current role, plus the prompt's data classification and selected model route. It also needs the business purpose supplied by the application and the policy version in force. This is the post-authentication gap. A valid workload identity establishes access to the Google resource. A per-request decision establishes that this caller may send this content to this endpoint now.

Put that decision on the HTTP path before inference. The application must propagate the originating identity because a gateway can evaluate only the context it receives. Missing identity should be subject to an explicit exception policy or fail closed. Preserve the decision and a correlation ID beside Google Cloud logs so an investigator can join resource access to request authorization.

A five-record production test

Run a synthetic request through the exact production pattern under a named test identity. Use a labeled fictional value in the prompt and capture five records:

• the Google Cloud principal and IAM permission used for the API operation
• the VPC Service Controls result and selected project plus location
• the model-specific encryption and residency, plus the Access Transparency configuration
• every enabled retention path, including BigQuery request-response logging or session settings
• the caller-aware policy result for the routed HTTP request

The fifth record should identify the originating principal and role, plus the classification and route. It should also identify the policy version and outcome, plus the timestamp and correlation value. AI gateway architecture explains where that request decision is. The other four records are under Google Cloud ownership and prove the resource and provider controls.

Repeat the test with a preview model and with request-response logging enabled in a non-production project. The expected evidence should change. That exercise catches platform-wide assumptions before they become production exceptions.

DeepInspect

This is the gap DeepInspect closes on routed model requests. DeepInspect is a stateless proxy between authenticated users or agents and HTTP LLM endpoints. For a Gemini Enterprise Agent Platform route, it evaluates application-supplied identity and role alongside prompt classification and purpose, plus destination and versioned policy, before forwarding permitted traffic.

Google Cloud owns IAM and VPC Service Controls, plus encryption and residency support. It also owns Access Transparency and provider-side retention behavior. DeepInspect adds a signed, tamper-evident decision record for the request path it inspects, giving investigators an independent link between the originating caller and the allow, block, or redact outcome. Book a technical deep dive at deepinspect.ai.