How does gateway auth work when Vertex uses OAuth tokens?

Vertex authenticates with short-lived Google OAuth access tokens, typically from a service account. The gateway pattern splits that into two steps: the client presents a token from your own identity provider that names the natural person, which the gateway validates, and the gateway separately mints the Google token for the upstream call using a service account it holds. The person is authenticated at the gateway, and the service account is what Vertex sees. The gateway carries the binding between them, which is the piece Google's own logs do not record.

Can a gateway front both generateContent and the OpenAI-compatible endpoint?

Yes. Vertex exposes the native generateContent and streamGenerateContent methods and an OpenAI-compatible chat/completions route. A gateway can terminate either shape, apply the same identity binding, classification, and per-model policy, and forward to the matching upstream path. Decide which shape your clients standardize on so the gateway terminates one canonical form, and keep the per-model policy keyed to the model in the path regardless of which route carried the request.

How does the gateway help with Vertex data residency?

Vertex endpoints are regional, and the region is in the host name. The gateway's egress allow-list names the specific regional hosts that policy permits, so a call that targets a region outside your data-residency boundary is blocked before it leaves. The audit record captures the region on every decision, which gives a data-residency review durable evidence that traffic stayed within the allowed regions rather than an assumption that it did.

Does the gateway replace Vertex safety filters?

No. Vertex applies model-layer safety filtering that Google defines, scoped to the Vertex endpoint. The gateway adds a different layer: per-request authorization bound to a natural-person identity, classification of regulated data types like PHI and MNPI, region-aware egress, and a signed audit record independent of Google Cloud logging. The safety filter screens content at the model. The gateway authorizes the caller and produces the identity-bound evidence, and the two sit at different points in the path.

Vertex AI Gateway Setup: A Governed Proxy in Front of generateContent

Vertex AI addresses a model by a resource path, not a short name, on a regional host: https://{region}-aiplatform.googleapis.com/v1/projects/{project}/locations/{region}/publishers/google/models/{model}:generateContent. It authenticates with a short-lived Google OAuth bearer token, usually minted from a service account or gcloud auth, rather than a static API key. Setting up a gateway in front of Vertex means terminating that path shape, validating a Google identity, and forwarding the call unchanged to the regional endpoint.

This is the setup walk-through. For the topology decisions behind it, regional routing, model selection across Gemini and third-party publishers, and where the model-layer safety filters sit, see Vertex AI gateway patterns. The goal here is a working, identity-bound gateway in front of generateContent.

Step one: terminate the resource-path request

The gateway exposes an endpoint the client targets in place of the regional host, preserving the Vertex path shape so client code changes only its base URL:

The {model} segment and the :generateContent or :streamGenerateContent suffix are the parts policy turns on. Carry the full path and the method suffix through unchanged. Vertex also exposes an OpenAI-compatible route at .../endpoints/openapi/chat/completions, and a gateway can front either shape, so decide which one your clients use and terminate that.

Step two: validate the Google identity and bind the person

Vertex tokens are short-lived OAuth access tokens, which is better than a static key but still identifies a service account, not a person. Require the caller to present an identity from your identity provider, validate it, and resolve the natural-person identity, then have the gateway mint the Google token for the upstream call itself:

The client never holds the Google credential, so it cannot reach aiplatform.googleapis.com directly. The gateway carries the binding between the service account Vertex sees and the natural person who actually made the request, which closes the post-authentication gap.

Step three: apply per-model policy

The model is named in the path, so policy attaches to it. Gemini models, tuned models, and third-party publisher models each carry their own approvals:

The gateway classifies the prompt content and evaluates the rule for the targeted model. A model approved for a sensitive data class is reachable only by the role permitted to send it, and everything else fails closed.

Step four: constrain egress to the regional host

Vertex endpoints are regional, so the egress allow-list names the specific {region}-aiplatform.googleapis.com hosts in use, and the application tier is blocked from reaching them directly:

A service that can still mint its own Google token and call the regional host bypasses the gateway entirely, so egress control is part of the setup. Naming regions also keeps a call from silently crossing into a region your data-residency policy does not allow.

Step five: commit an audit record for every decision

Each decision writes a record naming the person, the model, the region, the data class, the outcome, and the policy version, committed before the response returns on a write path the application cannot alter:

Google Cloud audit logs record that the service account called Vertex. They do not record which natural person the application was acting for, because Vertex only saw the service account. The identity-to-decision binding lives in the gateway's record, and that is what a regulator asks to see.

DeepInspect

This is the problem DeepInspect was built to solve. Vertex gives you resource-path endpoints, regional hosts, and short-lived service-account tokens. DeepInspect sits in front of them as the governed proxy this guide describes.

DeepInspect terminates the generateContent request, validates the caller's identity-provider token, binds the call to the natural person, classifies the prompt against regulated data types, and applies per-model and per-region policy before forwarding to the regional Vertex host with a Google credential it mints itself. The decision is deterministic and fail-closed, under 50 ms in internal testing, and every decision commits a signed, identity-bound audit record before the response returns, on a write path the application never controls. If you are standing up Vertex AI for a regulated workload and need identity-bound authorization and data-residency-aware evidence, book a demo today.