Does Apigee inspect Gemini prompt content on its own?

Apigee terminates TLS and can read the request body, and its native GenAI policies count tokens and enforce quotas keyed to the calling app. Content inspection comes from calling Model Armor through the SanitizeUserPrompt and SanitizeModelResponse operations. So Apigee alone governs the request envelope, and the payload screen is a separate Model Armor integration you wire into the proxy flow. Whether that screen covers a given call depends on the Model Armor template being attached to that path.

What is Model Armor and where does it run?

Model Armor is Google Cloud's screening service for prompt injection, jailbreak attempts, malicious URLs, and sensitive data through Sensitive Data Protection infoTypes. It runs as a Google Cloud service with templates scoped to a project, and Apigee or the application calls it before and after the model. Its detection categories are Google-defined, and its coverage follows the paths where you attach its templates, which in practice means Gemini and other traffic routed through that Google Cloud configuration.

How do I keep Vertex AI prompts in one region?

Pin the call to a regional endpoint, such as europe-west4-aiplatform.googleapis.com, and enforce that selection at the gateway so a caller cannot reach a different region by changing the URL. Apigee can resolve the target region from a residency tag on the request and reject calls whose tag and region disagree. This holds the prompt in-jurisdiction for processing, and it is a separate control from classifying what the prompt contains.

Can one policy layer cover Vertex AI and non-Google models?

Model Armor and Apigee GenAI policies are written for the Vertex AI request and token shape, so covering a second provider means rebuilding the integration on that path. A model-agnostic policy layer evaluates identity, data classification, and organizational policy the same way regardless of whether the backend is Vertex AI, Azure OpenAI, Bedrock, or a self-hosted model. In a mixed estate that consistency is what keeps a caller from routing around the screen by choosing a different model.

Vertex AI Gateway Patterns: Governing Gemini Traffic on Google Cloud

A Vertex AI call to Gemini lands at a regional endpoint, https://{region}-aiplatform.googleapis.com/v1/projects/{project}/locations/{region}/publishers/google/models/{model}:generateContent, and it authenticates with a Google Cloud OAuth token tied to a service account holding aiplatform.endpoints.predict. As soon as a second application wants that model, a team puts a gateway in front of it, and on Google Cloud that gateway is usually Apigee. Apigee does real work here: it meters token spend, attributes cost per app, routes across regions, and calls Model Armor to screen prompts. I want to walk the three patterns teams run in front of Gemini, show where Model Armor fits, and be precise about what Apigee governs at the request envelope versus what governing the payload across providers requires.

Why the service account token is the wrong sharing primitive

A Vertex AI service account token grants whatever the account's IAM roles allow, and handing the same account to three applications erases per-caller attribution and per-caller quotas. Google's own guidance points to per-workload service accounts with narrowly scoped roles rather than one shared identity. The gateway pattern formalizes this. Consumers authenticate to Apigee with their own API key or OAuth credential, and Apigee authenticates outbound to Vertex AI with a single service account the consumers never hold. That gives you one place to revoke a consumer, attribute its spend, and cap its rate without rotating credentials for everyone else on the model.

Pattern one: token quotas and cost attribution

The first job is spend control. Vertex AI bills on input and output tokens, and one unbounded caller can burn a project's budget for the month. Apigee ships model-aware policies for this through its GenAI capabilities, reading the token counts Gemini returns and enforcing a quota keyed to the calling app:

Binding the identifier to client_id means one application hitting its ceiling never starves another, and the same dimension flows to Cloud Monitoring for per-app cost attribution without parsing a consolidated billing export. This is governance of the request envelope: how many tokens, from which app, at what rate.

Pattern two: regional routing and data residency

The second job is placement. Vertex AI is regional, and where a Gemini call runs determines which jurisdiction processes the prompt. A European workload that must keep data in the EU has to pin traffic to europe-west4 or another EU region, and a global service wants fallback when one region returns a 429 or a 503. Apigee routes by target server and can select the backend from a variable resolved on the caller's residency tag:

The gateway is routing on metadata about the request, the residency tag and the response status, and it reads nothing inside the model's answer to make that decision. Residency enforcement at this layer keeps a prompt in-region, and it says nothing about what the prompt contains.

Pattern three: Model Armor and the scope of its screen

The third job is content screening, and Google's answer is Model Armor. Apigee calls it through the SanitizeUserPrompt and SanitizeModelResponse operations, and Model Armor screens for prompt injection, jailbreak patterns, malicious URLs, and sensitive data through Sensitive Data Protection infoTypes. This is genuine payload inspection, and its scope is Google Cloud. Model Armor's data detection runs on Google-defined infoTypes and its templates live in a Google Cloud project, so the screen covers Gemini traffic that transits that project. A caller reaching Anthropic, an Azure OpenAI deployment, or a self-hosted model in the same estate falls outside the Model Armor template unless you rebuild the integration on each path, and the identity Model Armor sees is the gateway service account rather than the enterprise principal who made the request.

What governing the payload across providers requires

Governing the prompt payload means reading the decrypted request body on every call, classifying it against the organization's own data categories, binding the decision to the enterprise identity the application supplied, applying a pass, block, or modify outcome before the request reaches any provider endpoint, and committing a tamper-evident record of that decision. Apigee terminates TLS and sits on the decrypted path where this is possible, and Model Armor supplies a Google-scoped screen against Google-defined categories. The attack tempo makes the timing strict. Google Mandiant's M-Trends 2026 report put the median handoff from initial access to a secondary actor at 22 seconds, so a screen that reviews traffic on one provider path leaves the other paths reviewed after the fact, which is forensic value and no prevention. The provider-agnostic version of this control is the subject of why AI security must be inline.

DeepInspect

This is the gap DeepInspect closes across a Google Cloud estate and beyond it. Apigee keeps doing what it does well: token quotas per app, cost metrics to Cloud Monitoring, and regional routing that holds data in-jurisdiction. DeepInspect adds the identity-bound payload governance that reads the same across every model your teams call.

DeepInspect is a stateless proxy on the AI request path in front of Vertex AI and any other endpoint in the estate. It terminates the AI request, reads the decrypted body rather than the encrypted tunnel, binds the call to the enterprise identity your application forwards from Google Cloud IAM or your IdP, classifies prompt content across PII, PHI, MNPI, source code, and jurisdictional categories, and applies a deterministic pass, block, or modify decision before the request reaches Gemini or a second provider. It commits a per-decision audit record for every call, inline and fail-closed. The same policy covers Vertex AI, Azure OpenAI, Bedrock, and a self-hosted model, which is the coverage a single-cloud screen cannot give a mixed estate. This mirrors the Azure OpenAI gateway patterns and Bedrock gateway patterns on their own clouds. Book a demo today.