← Blog

DeepInspect vs Apigee AI Gateway: API Management and the Audit Record Model Armor Does Not Produce

Apigee is Google Cloud API management used as an AI gateway. Model Armor policies filter prompt injection and jailbreaks, semantic caching runs through Vertex embeddings, and LLM token policies handle cost. What Apigee authenticates is the calling app, the developer, or the API product. DeepInspect authenticates the natural person behind the request, classifies prompt content against PII, PHI, and MNPI, and commits a signed per-decision audit record. This piece walks through what each does and how they compose.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Comparisons & Alternativesai-gatewaycomparisonai-securityai-complianceauditeu-ai-act
DeepInspect vs Apigee AI Gateway: API Management and the Audit Record Model Armor Does Not Produce

There is no separately purchasable product called Apigee AI Gateway. Google uses the term (the Agent Development Kit documentation carries it as a page title) but what it names is Apigee API Management positioned as an AI gateway, with AI-specific policies attached to the existing proxy engine. Google's own framing on the solutions page is direct: use Apigee as an AI gateway to govern and secure your AI applications. That matters for a comparison, because Apigee brings twenty years of API management maturity to LLM traffic and brings API management's identity model with it.

I want to walk through what Apigee actually enforces on AI traffic, what DeepInspect enforces, where the responsibilities separate, and how the two compose for a regulated workload on Google Cloud.

TL;DR

Apigee is a full-lifecycle API management platform whose AI policies add token limits, semantic caching through Vertex embeddings, and Model Armor prompt filtering. It authenticates the calling application, developer, or API product. DeepInspect binds policy to the natural person behind the request, classifies prompt content against regulated data taxonomies, and commits a signed per-decision audit record. Teams already running Apigee put DeepInspect in front of it for regulated workloads and keep everything Apigee is good at.

Apigee: what it is and where it sits

You place an Apigee API proxy in front of Vertex AI, Gemini, or third-party model endpoints and attach policies to the proxy flow. The AI behavior comes from policies on the existing runtime rather than a new data plane, which is the source of both its strengths and its limits.

The AI policy set is real. LLM token policies enforce token limits for cost control and report on consumption. Model Armor policies, SanitizeUserPrompt and SanitizeModelResponse, make Apigee the policy enforcement point for Google's Model Armor service, which detects prompt injection, blocks jailbreak attempts, applies responsible-AI filters, screens malicious URLs, and runs Google's sensitive data protection infotypes against prompt content. Semantic caching extracts the prompt, embeds it through the Vertex text embeddings API, and runs similarity search through Vertex Vector Search. Quota and SpikeArrest handle rate limiting. Advanced API Security covers abuse detection and OWASP API and LLM Top 10 mitigation, with Google SecOps integration.

Apigee also handles MCP traffic, supports MCP transcoding, and the Apigee Operator for Kubernetes enforces Apigee auth and AI policies on traffic through the GKE Inference Gateway.

The architectural sweet spot is an organization already standardized on Apigee for its API estate that wants LLM traffic on the same operator surface, the same analytics, and the same monetization plane.

What DeepInspect is and where it sits

DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any HTTP LLM endpoint. It evaluates identity-bound policy per request, classifies prompt content against the regulated data types the organization recognizes, and commits a per-decision audit record with cryptographic integrity. Decisions are deterministic and fail closed.

The primitives are narrow by design. Natural-person identity attribution at the model API call, taken from the application's identity primitive rather than inferred from the API key. Per-route and per-role policy bundles, so the support route, the developer route, and the legal route carry different rules. Prompt-level classification across PII, PHI, MNPI, source code, and jurisdictionally regulated data. A pass, block, or modify decision before the request reaches the model. And an audit record formatted for EU AI Act Article 12 review, HIPAA, DORA, and sector audit.

The sweet spot is the regulated workload, where the organization is the data controller for prompts crossing into a model provider and has to produce evidence rather than telemetry.

Where the two separate

Both products are an HTTP proxy in front of LLM endpoints. Both attach metadata to requests and write records of what passed through. The separation is in what identity means and what a record is for.

Apigee's identity model is the API management model. It authenticates the calling app, the developer, and the API product, and its analytics are keyed to those. It can validate a JWT that happens to carry an end-user subject claim, and you can pass and log that claim yourself, but binding a verified natural person to a specific model call is not a native primitive. This is correct for API management. It is the wrong shape for an Article 12 record, which asks which natural person was involved in a specific AI decision at a specific timestamp.

On data classification, Apigee is genuinely capable and it would be wrong to say otherwise. Model Armor includes Google's sensitive data protection infotypes, which cover PII-class detection well. What it lacks is a PHI or MNPI taxonomy. A healthcare deployment that needs SOAP-note and diagnostic-plan detection, or a financial deployment that needs material non-public information detection, is writing that logic itself.

On audit, Apigee emits analytics and Cloud Logging entries. Google Cloud Audit Logs cover admin activity on the platform. Neither produces a tamper-evident, signed record of an individual inference decision with the identity, the classification outcome, and the policy version bound into it.

Feature comparison

| Capability | Apigee | DeepInspect | |---|---|---| | HTTP proxy for LLM traffic | Yes | Yes | | Multi-provider and multicloud model routing | Yes | Forwards to a configured upstream | | Semantic caching | Yes, via Vertex embeddings and Vector Search | Out of scope | | Token limit and cost policies | Yes | Out of scope | | Prompt injection and jailbreak filtering | Yes, via Model Armor | Yes, as one policy input among several | | Rate limiting | Yes, Quota and SpikeArrest | Per-role and per-route | | Identity on the model call | App, developer, or API product | Natural person from the identity provider | | PII detection | Yes, Google SDP infotypes via Model Armor | Yes | | PHI and MNPI classification | Not offered | Yes | | Per-route policy bundle | Policy attachment on the proxy flow | Yes | | Per-decision signed audit record | Analytics and Cloud Logging | Yes, cryptographically signed | | Article 12 audit format | Operational logs | Yes | | Monetization and API productization | Yes | Out of scope | | Deployment | Apigee X managed, or Apigee hybrid | Self-hosted or managed, any cloud |

Pick Apigee if

Pick Apigee if your API estate already runs on it and putting LLM traffic on the same control plane is worth more than a specialized enforcement layer. Pick it if you are on Google Cloud with Vertex AI and want Model Armor and semantic caching wired in with policy attachments rather than integration work. Pick it if you need to monetize AI APIs, catalog them in API hub, or productize them for external developers, which is a job DeepInspect does not do at all. And pick it if the workload carries no regulatory audit obligation, in which case Apigee's analytics are the right level of record.

Pick DeepInspect if

Pick DeepInspect if the audit record has to name a natural person rather than an application. Pick it if the data classification requirement extends past PII into PHI, MNPI, or jurisdictional categories that Model Armor's infotypes do not cover. Pick it if you have to demonstrate to a reviewer that the record could not have been altered by the application that produced the decision. Pick it if the model estate spans providers outside Google Cloud and the enforcement has to be identical across all of them. And pick it if August 2, 2026 is on your calendar as an EU AI Act transparency deadline.

Composition in production

The topology that works on Google Cloud runs both. The application calls DeepInspect. DeepInspect evaluates the natural-person identity, classifies the prompt content, commits the signed audit record, and forwards the cleared request to the Apigee proxy. Apigee applies its token policies, runs Model Armor, checks semantic cache, and routes to Vertex AI or the configured provider. The response returns through Apigee to DeepInspect, which evaluates the response, records the outcome, and returns to the application.

Model Armor still runs. Semantic caching still saves money. Apigee analytics still feed the platform dashboards. What DeepInspect adds is the identity binding on the front of the chain and the evidence record at the end of it.

Pricing approach

Apigee is a Google Cloud subscription with tiered plans plus pay-as-you-go, and the AI features carry downstream cost: Model Armor bills separately, and semantic caching bills Vertex embeddings and Vector Search on every lookup. Budget for that, because the caching feature that saves model spend is not free. DeepInspect is priced through sales conversation and deploys self-hosted or managed. Neither company publishes a per-seat list price for enterprise deployments.

DeepInspect

This is the gap DeepInspect closes. Apigee governs the API. DeepInspect governs the decision. Every request that reaches the model carries a natural-person identity, a data classification outcome, and a policy version, and the record of all three is committed before the response returns to the application, on a write path the application never touches.

For a regulated deployment on Google Cloud, that is the difference between showing a reviewer an analytics dashboard and handing them a signed record that answers who authorized this, under which policy, at what moment, with what outcome. The enforcement overhead runs under 50 ms in internal testing, against model inference that takes 500 ms to 5 seconds, so the cost of the record is invisible next to the call it describes.

If you are running Apigee in front of Vertex AI and facing the August 2, 2026 deadline, let's talk today.

Frequently asked questions

Is there an official Apigee AI Gateway product?

No separate SKU. Google uses the phrase, including as a page title in the Agent Development Kit documentation, but what it refers to is Apigee API Management with AI-specific policies attached: LLM token policies, Model Armor SanitizeUserPrompt and SanitizeModelResponse, semantic caching through Vertex embeddings and Vector Search, and the existing Quota, SpikeArrest, and OAuth policy set. You buy Apigee and configure it as an AI gateway.

Does Model Armor detect PII in prompts?

Yes. Model Armor includes Google's sensitive data protection infotypes, which handle PII-class detection well, along with prompt injection detection, jailbreak prevention, responsible-AI filters, and malicious URL screening. What it does not include is a PHI taxonomy or an MNPI taxonomy. A healthcare workload that needs clinical-content detection, or a financial workload that needs material non-public information detection, has to build that classification itself or run a layer that already has it.

Can Apigee produce an EU AI Act Article 12 audit record?

Apigee produces analytics and Cloud Logging entries, and Google Cloud Audit Logs cover administrative activity on the platform. Article 12 asks for automatic recording of events over the system's lifetime sufficient to ensure traceability, including timestamps, input data, and identification of the natural persons involved. The gap is the last clause. Apigee's identity model keys to apps, developers, and API products, so the natural-person identification has to be supplied and recorded by a layer that has it. A reviewer asking which person sent which prompt under which policy is asking a question Apigee's record shape was never built to answer.

How is DeepInspect different from Apigee?

Apigee is API management, and AI is one class of API it manages: routing, quotas, caching, monetization, developer portals, analytics, with Model Armor bolted on for content safety. DeepInspect does none of that. It does one thing: evaluate identity-bound policy on AI request and response content and commit a signed per-decision audit record. The overlap is that both sit in the HTTP path. The difference is that Apigee's record answers which application called, and DeepInspect's record answers which person, under which policy, with what data, and what the enforcement layer decided.

Do I have to replace Apigee to use DeepInspect?

No, and for most Google Cloud deployments that would be the wrong move. The production pattern runs DeepInspect in front of the Apigee proxy. The application calls DeepInspect, which binds identity, classifies the prompt, commits the record, and forwards to Apigee. Apigee then does token policies, Model Armor, semantic cache lookup, and routing to Vertex AI. Everything Apigee is good at keeps working, and the layer in front adds the identity binding and the evidence record that the API management model does not produce.

What is the latency cost of running both?

DeepInspect's enforcement overhead measures under 50 ms in internal testing. Apigee's proxy overhead and Model Armor's inspection add their own. Set against LLM inference in the 500 ms to 5 second range, the combined proxy overhead sits inside the noise of the model call. Semantic caching, on the other hand, changes the latency profile in the other direction when it hits, since a cache hit skips inference entirely.