Comparison / 13 capabilities
YTT Secunet vs Kong AI Gateway
Kong AI Gateway extends Kong Gateway with a broad set of AI plugins: AI Proxy and AI Proxy Advanced for multi-provider routing with load balancing and failover, semantic caching, token and cost based rate limiting, prompt and response guards, integrations with AWS, Azure and Google Cloud guardrail services, MCP and agent-to-agent traffic handling, and an AI Sanitizer that redacts PII before the provider and can restore it in the response. It runs self-hosted, in hybrid mode with Konnect, or as Kong-hosted Dedicated Cloud Gateways, and its plugin ecosystem is one of the deepest in the API world. If you already run Kong as your API platform, extending it to LLM traffic is a natural step. YTT Secunet is narrower and goes deeper on one question: which jurisdiction a request belongs to, which certified endpoints inside that jurisdiction may serve it, and how to prove afterwards that they did.
Matrix tally
- YTT Secunet edge5
- Parity3
- Kong AI Gateway edge5
Rows where Kong AI Gateway is stronger are marked as such. Filter the matrix below to read them first.
| Capability | YTT Secunet | Kong AI Gateway | Edge |
|---|---|---|---|
| Plugin ecosystem and extensibility | Extensible through Rego policies and the endpoint registry. Not a general plugin platform. | A large plugin hub for authentication, traffic control, transformation and logging, plus custom plugins in Lua, Go, Python or JavaScript. | Alternative edge |
| Multi-provider LLM proxying | OpenAI-compatible and Anthropic-compatible interface in front of hosted providers, sovereign clouds and self-hosted runtimes. | AI Proxy and AI Proxy Advanced normalise requests across many providers and self-hosted models. | Parity |
| Load balancing algorithms | Latency-aware selection among the healthy endpoints inside the resolved jurisdiction. | Round-robin with weights, lowest latency, lowest usage, consistent hashing and semantic routing that picks a model by prompt content. | Alternative edge |
| Semantic caching | None. Zero data retention means nothing from a prompt is stored, including embeddings. | AI Semantic Cache serves near-duplicate prompts from cache, with Redis or Postgres and pgvector as the store. | Alternative edge |
| PII redaction and restoration | In-path pseudonymization with detectors for IBANs, passport numbers and national IDs such as Steuer-ID, NIR, NHS and Saudi national ID, and a vault pinned to the origin jurisdiction. | AI Sanitizer, part of the AI Gateway Enterprise offering, redacts PII before the upstream provider and can restore the original values in responses. | Parity |
| Prompt security guardrails | Not a prompt injection or content moderation product. | AI Prompt Guard, AI Semantic Prompt Guard and AI Semantic Response Guard, plus plugins for Amazon Bedrock Guardrails, Azure AI Content Safety and Google Cloud Model Armor. | Alternative edge |
| Open Policy Agent | OPA is embedded in the data path. The policy chooses the destination set and failover candidates, and its id and version are written into the signed receipt. | The OPA plugin sends request details to an OPA server and allows or rejects the request based on its decision. | YTT Secunet edge |
| Pre-built jurisdiction policy content | Maintained packs for EU GDPR, UK GDPR with the IDTA, Swiss revFADP, EU AI Act high-risk, Saudi PDPL, UAE PDPL, HIPAA and ITAR or FedRAMP boundaries. | None. You write the rules, decide what each regime requires and keep them current. | YTT Secunet edge |
| Failover semantics | Failover never leaves the jurisdiction. If no compliant endpoint is healthy, the request is refused with a policy reason. | Fails over to the next configured target or provider. Staying in-jurisdiction depends on how carefully each target list is curated. | YTT Secunet edge |
| Residency evidence | Ed25519-signed JWS receipt per response, hourly SHA-256 Merkle root and the open-source ytt-verify tool for offline inclusion proofs. | Logging plugins and OpenTelemetry spans with Gen AI attributes, stored and secured by you. | YTT Secunet edge |
| Deployment flexibility | SaaS with regional data planes, Sovereign Dedicated in your VPC or on-prem, and air-gapped with offline licensing and HSM-held signing keys. | Self-hosted, hybrid with a Konnect control plane and your own data planes, or Kong-hosted Dedicated Cloud Gateways. | Parity |
| Agent and MCP traffic | Focused on inference requests to model endpoints. | MCP server and proxy capabilities, OAuth scoping for agent tool calls and agent-to-agent traffic handling. | Alternative edge |
| Compliance documentation | Exports for transfer impact assessment evidence, Article 30 records of processing and Annex IV technical documentation evidence. | Not a product goal. Assembled from configuration and logs. | YTT Secunet edge |
- Kong is already your API platform and the team knows its configuration model, plugin lifecycle and upgrade path.
- You need semantic caching, semantic routing by prompt content or cost-aware load balancing more than jurisdiction controls.
- Prompt injection defence and content guardrails through AWS, Azure or Google Cloud services are a priority.
- You are governing MCP servers and agent tool calls alongside model traffic.
- Your residency needs are simple enough that a curated target list per route is easy to keep correct.
- Your legal team wants maintained policy packs for GDPR Chapter V, the UK IDTA, revFADP or the Saudi PDPL rather than rules written from scratch.
- Failover must provably stay inside a jurisdiction across several providers.
- Customers or regulators ask for per-request proof of processing location that they can verify offline.
- You need compliance exports for TIAs, records of processing and Annex IV evidence from the same system that enforces the routing.
Most teams run both for a while. These steps keep your current setup serving traffic until the receipts show the new route is doing what policy says.
- 01
Keep Kong as your API platform. Point the AI route's OpenAI-compatible upstream at the YTT Secunet regional base URL instead of directly at providers.
- 02
Set the X-YTT-Tenant header from the authenticated Kong consumer or token claim, and choose a policy pack per route or per consumer group.
- 03
Move jurisdiction rules out of your OPA server and into a YTT Secunet pack. Keep Kong's OPA plugin for API authorization decisions that have nothing to do with residency.
- 04
Run one PII layer on AI routes to avoid double tokenization. If you choose YTT Secunet's vault, disable the sanitizer on those routes.
- 05
Send receipts to your SIEM next to Kong's logs, and run ytt-verify against a week of Merkle roots before moving the rest of your traffic.
Whatever sits in front of your providers today, the integration point for YTT Secunet is the inference client. The base URL moves to the regional entry point for the tenant's zone, and two headers name the tenant and the policy pack.
Request and response bodies keep the OpenAI or Anthropic schema, so streaming, tool calls and JSON mode work as before. The model name becomes a logical alias that the endpoint registry maps to an in-zone deployment.
- A denied request returns HTTP 451 with a decision id, never a silent reroute
- Every response carries a signed residency receipt header
- Receipts export to your SIEM alongside your current gateway logs
import OpenAI from "openai";
// Before: provider default endpoint, region decided by the provider.
// After: YTT Secunet regional entry point, zone decided by policy.
const client = new OpenAI({
baseURL: "https://eu.yttsecunet.com/v1",
apiKey: process.env.YTT_SECUNET_API_KEY,
defaultHeaders: {
"X-YTT-Policy": "eu-gdpr-strict@4.2.0",
"X-YTT-Tenant": tenant.id,
},
});
const res = await client.chat.completions
.create({ model: "gpt-4o", messages })
.withResponse();
const receipt = res.response.headers.get("x-ytt-proof-signature");Can YTT Secunet sit behind Kong?
Yes. Kong handles consumers, keys, quotas and the rest of your API estate, and forwards AI routes to YTT Secunet as an OpenAI-compatible upstream with two extra headers. Receipts still record the provider endpoint that finally served each call.
Kong's AI Sanitizer also restores PII. What is different about YTT Secunet's vault?
The approach is similar and both are reasonable choices. YTT Secunet pins the vault to the origin jurisdiction, ships detectors for national identifiers across the jurisdictions it serves, and records in the signed receipt that pseudonymization ran under a named policy version, so the masking step itself becomes part of the audit evidence.
We already run OPA with Kong. Why add another policy engine?
It is the same engine. The difference is what the policy decides. Kong's OPA plugin returns allow or deny for a request. A YTT Secunet pack returns the jurisdiction, the permitted endpoint set and the failover order, and that decision is signed into the receipt. Many teams keep both: OPA for who may call an API, YTT Secunet for where the inference may run.
Sovereign route ready
Put both on the same traffic and compare the evidence.
Start a 14-day trial, route one tenant through YTT Secunet, and check every receipt with the open-source verifier.