DeepInspect vs F5 AI Gateway: Processors, Records, and What Gets Signed
F5 AI Gateway, announced November 2024, is a containerized Kubernetes proxy with a pluggable processor model. Processors modify, reject, or annotate traffic, and F5 ships prompt injection detection, data security matchers, and language identification. Its core stores an auditable record of every request and exports it to S3. That record carries no signature and no natural-person binding. This piece separates F5 AI Gateway from F5 AI Guardrails, then walks through the composition pattern.

F5 AI Gateway was announced on November 12, 2024 and ships as a containerized service on Kubernetes with an architecture worth studying: a core proxy plus a set of processors that run separately from it. Each processor can do exactly one of three things to the traffic passing through. It can modify it, rewriting content such as redacting a credit card number. It can reject it, halting processing. Or it can annotate it, attaching tags and metadata that the core then uses to select which LLM backend to route to.
That is a clean design, and it is the thing F5 got right. Routing decisions driven by content annotations are a genuinely useful primitive that most AI gateways do not have.
I want to walk through what F5 AI Gateway enforces, clear up a naming confusion that trips up most comparisons, and describe how the two layers compose.
First, disambiguate: Gateway is not Guardrails
F5 ships two overlapping AI security products and conflating them produces wrong conclusions.
F5 AI Gateway is the November 2024 containerized proxy described above. Core plus processors, deployed with Helm on Kubernetes.
F5 AI Guardrails came from the CalypsoAI acquisition, which closed on September 26, 2025. It is a separate product with overlapping scope: prompt injection defense, semantic data security, content moderation, natural-language policy creation, and compliance controls for PII leakage, PCI, and PHI, deployable in public cloud, private cloud, on-premises, and air-gapped. F5 packaged both under an AI Security Platform launched on June 22, 2026.
Anything you read comparing "F5 AI Gateway" to another product, including this article, has to be clear which one is in scope. Below, F5 AI Gateway means the gateway.
TL;DR
F5 AI Gateway is a Kubernetes proxy with a processor pipeline that inspects and filters AI requests and responses, and routes based on content annotations. It stores an auditable record of every request, every response, and every processor's activity, and exports it to S3. That record is unsigned and keyed to the request rather than to a verified person. DeepInspect binds the natural person, classifies against regulated data taxonomies, and signs the per-decision record. The two compose.
F5 AI Gateway: what it enforces
The core does authentication and authorization checks (JWT validation, header inspection), parses and validates the client request, applies request processors, selects and routes to an LLM backend while transforming the request and response to match the backend's or the client's schema, applies response processors, optionally stores the auditable record, and exports telemetry over OpenTelemetry.
The shipped processors:
- Prompt injection. F5's own documentation states the limitation plainly: it is English-only, and attacks in other languages are not detected. I respect that they wrote that down.
- Data security, with a matcher structure covering matcher types, group matchers, and default matchers.
- Language identification.
- Repetition detect.
- System prompt handling.
Lab processors include Prompt guard, Topic detect, and Content Guard. GPU support is available for processors, and a Python SDK lets you write custom ones, which is the extensibility story.
F5 recommends NGINX Ingress Controller in front of AI Gateway to expose it to clients, and it integrates natively with the NGINX and BIG-IP estate. It is not a BIG-IP module. It is a separate containerized product that plugs into F5's platform.
What DeepInspect is and where it sits
DeepInspect is a stateless proxy at the AI request boundary 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. Deterministic, fail-closed, model-agnostic.
Where the two separate
The gap is narrower here than with the routing gateways, because F5 built a security product. Three specific differences remain.
Identity. The F5 core validates JWTs and inspects headers, so a user claim can be present and a processor can turn it into a tag. That claim is a routing and filtering input. There is no primitive that binds a verified natural person to the model call as the unit of attribution, and the stored record is keyed to the request.
Classification depth. The Data security processor does matcher-based detection and redaction, which handles PII-shaped patterns such as credit card numbers well. It carries no PHI taxonomy and no MNPI taxonomy. F5's answer to that is the separate AI Guardrails product, which does market PII, PCI, and PHI controls. Inside AI Gateway itself, the classification is pattern matching.
What gets signed. This is the one that matters most and it is subtle. F5 AI Gateway does store an auditable record of every request, every response, and each processor's activity, and it exports that record to S3 or S3-compatible storage. That is more than most gateways do, and F5 deserves credit for building it. The record carries no cryptographic signature. Its integrity depends on external controls such as S3 Object Lock. And it is written by the system that made the decision, which means it is self-attestation: the application and gateway that took the action are also the source of truth about what they did.
An auditor who asks whether the record could have been altered by the system that produced it gets an answer that points at bucket policy rather than at cryptography.
Feature comparison
| Capability | F5 AI Gateway | DeepInspect | |---|---|---| | HTTP proxy for AI traffic | Yes | Yes | | Content-based backend routing | Yes, driven by processor annotations | Forwards to a configured upstream | | Prompt injection detection | Yes, English only per F5 docs | Yes, as one policy input | | Pluggable processor model | Yes, plus a Python SDK for custom processors | Policy engine, not a plugin pipeline | | Modify, reject, annotate | Yes, the three processor verbs | Pass, block, modify | | JWT validation | Yes | Yes | | Identity on the model call | JWT claim, no binding primitive | Natural person from the identity provider | | PII pattern detection | Yes, Data security matchers | Yes | | PHI and MNPI classification | Not in AI Gateway; sits in F5 AI Guardrails | Yes | | Audit record stored | Yes, request, response, and processor activity, to S3 | Yes | | Audit record signed | No; integrity via S3 Object Lock or similar | Yes, cryptographically signed | | Write-path independence from the application | Record written by the gateway | Decoupled write path | | OpenTelemetry export | Yes | Yes | | Deployment | Kubernetes, Helm, any cloud or data center | Self-hosted or managed, any environment | | License | Commercial, license enforcement and usage reporting | Commercial |
Pick F5 AI Gateway if
Pick F5 AI Gateway if you already run BIG-IP or NGINX and want AI traffic on the same platform with the same support relationship, which is a legitimate procurement argument on its own. Pick it if the processor model fits how you want to build, because writing custom processors in Python against a defined modify, reject, annotate contract is a good developer experience and content-driven backend routing is a real capability. Pick it if English-language prompt injection filtering plus pattern-based data redaction plus a stored request record meets the requirement, which for many workloads it does.
Pick DeepInspect if
Pick DeepInspect if the audit record has to name a natural person and be signed, so that its integrity does not depend on a storage bucket's configuration. Pick it if the classification requirement covers PHI or MNPI and you would rather not buy a second F5 product to get it. Pick it if the deployment is multilingual, given that F5's prompt injection processor is English-only by its own documentation. And pick it if the workload falls under the EU AI Act, HIPAA, or DORA and the evidence has to be independent of the system it describes.
Composition in production
Both are Kubernetes proxies, so they chain cleanly.
DeepInspect resolves the person, classifies the prompt, applies the per-route policy, and commits the signed record. F5's processors then run their inspection and the core routes on the resulting annotations. Every F5 capability keeps working. What changes is that the identity binding happens before the processor pipeline and the evidence record exists independently of it.
Pricing approach
F5 AI Gateway is commercial licensed software with license enforcement and usage reporting built into the product, sold through F5 subscription or Flex Consumption. F5 does not publish pricing. DeepInspect is likewise priced through sales conversation. Neither is a self-serve purchase, and both are evaluated in the same procurement motion, which is worth knowing when you are budgeting.
DeepInspect
This is the gap DeepInspect closes. F5 AI Gateway inspects the content and routes on what it finds. DeepInspect decides whether this specific authenticated person, on this route, carrying this class of data, is permitted to make this call, and then produces evidence of the decision that the system making the decision cannot alter.
The distinction is in the record. F5 writes a thorough operational record and puts it in a bucket. DeepInspect commits a cryptographically signed, identity-bound record on a write path decoupled from the application, before the response returns. That property, write-path independence, is what makes the record independent evidence rather than self-attestation, and it is what an EU AI Act Article 12 reviewer, a HIPAA auditor, or a DORA examiner is actually testing when they ask how you know the log is complete.
If you are running F5 in front of AI traffic and facing the August 2, 2026 deadline, let's talk today.
Frequently asked questions
- What is the difference between F5 AI Gateway and F5 AI Guardrails?
They are two products. F5 AI Gateway, announced November 2024, is a containerized Kubernetes proxy with a core and a pluggable processor pipeline that inspects, filters, and routes AI traffic. F5 AI Guardrails came from the CalypsoAI acquisition, which closed September 26, 2025, and covers prompt injection defense, semantic data security, content moderation, and compliance controls for PII, PCI, and PHI, with air-gapped deployment support. F5 packaged both under an AI Security Platform launched June 22, 2026. Most comparison articles blur them, which produces wrong conclusions about what the gateway alone actually does.
- Does F5 AI Gateway produce an audit trail?
Yes, and a fairly thorough one. The core optionally stores an auditable record of every request, every response, and the specific activity of each processor, exportable to S3 or S3-compatible storage. Two properties are absent. The record carries no cryptographic signature, so its integrity rests on external controls such as S3 Object Lock rather than on the record itself. And it is written by the system that made the decision, which is the self-attestation problem: the party under audit is the source of the audit record.
- Is F5's prompt injection detection multilingual?
No, and F5 says so in its own documentation. The prompt injection processor is English-only, and attacks in other languages are not detected. That is an honest disclosure and worth respecting, and it is also a hard constraint for any deployment serving users outside English. A multilingual workload needs the detection layer to handle the languages actually in the traffic, which means either a different processor or a different layer.
- How is DeepInspect different from F5 AI Gateway?
F5 inspects content and routes on it. Its processors modify, reject, or annotate, and the core selects a backend based on the annotations. DeepInspect evaluates authorization: whether this authenticated person, on this route, carrying this data classification, is permitted to make this call, and it commits a signed record of that decision on a write path independent of the application. Both sit inline in the HTTP AI path. The difference is between content inspection with an operational log and identity-bound authorization with independent evidence.
- Can I run DeepInspect and F5 AI Gateway together?
Yes, and on Kubernetes it is straightforward, since both are proxies in the same path. NGINX Ingress fronts the chain. DeepInspect binds identity, classifies, applies policy, and commits the signed record. It forwards the cleared request to F5 AI Gateway, whose processors run their inspection and whose core routes to the selected LLM backend. Nothing in the F5 pipeline is displaced. The identity binding happens in front of it and the evidence record exists outside it.
- Does F5 AI Gateway classify PHI?
Not in the gateway. The Data security processor does matcher-based detection with matcher types, group matchers, and default matchers, which handles structured PII patterns such as credit card numbers. There is no PHI taxonomy and no MNPI taxonomy in AI Gateway. F5's PII, PCI, and PHI compliance controls live in the separate AI Guardrails product, so a healthcare workload that needs clinical content classification is either buying the second product or running a layer that already carries the taxonomy.