Comparison / 12 capabilities
YTT Secunet vs Generic API Gateways
NGINX, Envoy, cloud API gateways and API management platforms are excellent at authentication, quotas, TLS termination and request transformation, and most organisations already run one.
Matrix tally
- YTT Secunet edge7
- Parity1
- Generic API gateways edge4
Rows where Generic API gateways is stronger are marked as such. Filter the matrix below to read them first.
None of them knows what a legal jurisdiction is. To keep LLM traffic inside the EEA, the UK or Switzerland, teams end up writing custom filters, maintaining hand-curated upstream lists and exporting access logs that an auditor has to take on trust. YTT Secunet is built for that one job: it resolves the jurisdiction of each inference request, restricts routing and failover to endpoints inside it, pseudonymizes identities before the prompt leaves, and returns a signed receipt per response. Most customers keep their existing gateway at the edge and put YTT Secunet behind it for AI calls only.
| Capability | YTT Secunet | Generic API gateways | Edge |
|---|---|---|---|
| General API management (keys, quotas, developer portal, versioning) | Scoped to inference traffic. Tenant and policy headers, SAML SSO and SCIM for the console on Enterprise. Not a developer portal or API product catalogue. | Mature and broad. Consumer keys, OAuth flows, quotas, developer portals and lifecycle tooling for hundreds of APIs. | Alternative edge |
| Protocol coverage | OpenAI-compatible and Anthropic-compatible inference APIs, including streamed responses. | Any HTTP, gRPC, WebSocket or GraphQL backend, which is the right tool for the rest of your estate. | Alternative edge |
| Routing decision inputs | Tenant domicile, user geo-IP and locale, and data sensitivity class, evaluated by a policy pack on every request before an endpoint is chosen. | Host, path, headers and weights. Jurisdiction logic has to be written by hand as custom filters, scripts or WASM modules and kept in sync with legal advice. | YTT Secunet edge |
| Failover semantics | Failover candidates are filtered by jurisdiction first. Frankfurt fails to Dublin or Amsterdam, never to Virginia, and the request is refused if no compliant endpoint is healthy. | Health checks and retries send traffic to any healthy upstream in the pool. If the pool contains an out-of-region target, a failover is also a cross-border transfer. | YTT Secunet edge |
| Policy language | Open Policy Agent and Rego embedded in the data path. The policy selects the destination set, not only allow or deny, with under 3 ms median evaluation (YTT Secunet figure). | Gateway configuration DSLs. Several gateways can call OPA through an external authorization hook, which returns allow or deny but does not choose the upstream. | YTT Secunet edge |
| Pre-built legal policy content | Maintained packs: eu-gdpr-strict, uk-gdpr-idta, swiss-fadp-compliant, eu-ai-act-high-risk, saudi-pdpl-sovereign, uae-pdpl-local, us-hipaa-only, us-itar-fedramp. | None. Your team writes and maintains every rule. | YTT Secunet edge |
| PII handling in prompts | In-path detection of names, passport numbers, IBANs and national IDs (German Steuer-ID, French NIR, UK NHS number, US SSN, Saudi national ID), with reversible pseudonymization in a vault inside the origin jurisdiction. | Request bodies are usually opaque. Regex transforms are possible with plugins, but restoring originals in the response is custom work. | YTT Secunet edge |
| Evidence of where each request ran | Ed25519-signed JWS receipt on every response, anchored in an hourly SHA-256 Merkle tree and checkable offline with ytt-verify. | Access logs written and stored by the operator. Useful for debugging, but an auditor has to trust whoever holds them. | YTT Secunet edge |
| Added latency | Under 8 ms p99 including policy evaluation and receipt minting (YTT Secunet production figure). | A well-tuned reverse proxy adds very little. If you only need path routing, it is the lighter hop. | Alternative edge |
| Compliance documentation | Exports for transfer impact assessment evidence, Article 30 records of processing and EU AI Act Annex IV technical documentation evidence. | Not in scope. Evidence is assembled by hand from configs and logs. | YTT Secunet edge |
| Deployment options | Multi-tenant SaaS with regional data planes, or Sovereign Dedicated in your VPC, on-prem or air-gapped. | Runs anywhere you can run a container or a managed service. | Parity |
| Team familiarity and cost | A new component with its own subscription, from $799 per month on Growth. | Already deployed, already paid for, and already understood by your SRE rota. | Alternative edge |
- Every user, every tenant and every model endpoint sit in the same jurisdiction, so a static upstream is all the routing you need.
- Your priority is full lifecycle management for many non-AI APIs: developer onboarding, monetisation, schema governance.
- You have a platform team with spare capacity to build jurisdiction filters, an endpoint inventory and an evidence pipeline, and to keep all three current as providers add regions.
- Your auditors and enterprise customers accept operator-held access logs as proof of processing location.
- You serve tenants under more than one legal regime and the destination must change per request, not per deployment.
- Failover must never become an unplanned Chapter V transfer.
- Your DPO needs evidence a supervisory authority or customer can verify without trusting your logs.
- You want names, IBANs and national IDs pseudonymized before the prompt reaches any model provider.
- Legal reviewers need to read and approve routing rules without learning gateway configuration syntax.
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 your existing gateway at the edge for authentication, quotas and WAF rules. Add one route for inference paths that forwards to the YTT Secunet regional base URL, for example https://eu.yttsecunet.com/v1.
- 02
Set the X-YTT-Tenant header from the authenticated identity your gateway already resolves, and the X-YTT-Policy header to a pre-built pack such as eu-gdpr-strict.
- 03
Register your provider deployments in the Sovereign Endpoints registry with their region and facility, and define the in-jurisdiction failover set for each.
- 04
Run a staging tenant for a week and compare the resolved endpoints in the receipts with the routing you expected. Fix any surprises in Rego, not in gateway config.
- 05
Retire the custom jurisdiction filters and upstream lists in the gateway once receipts confirm the routing, and send receipts to your SIEM.
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");Do we have to replace our API gateway?
No. YTT Secunet sits behind it and only handles inference calls. Your gateway keeps authentication, rate limits and the rest of your API estate. The only change on the gateway side is a route that forwards AI traffic with two extra headers.
Could we get the same result with Envoy and an OPA external authorization filter?
You can block requests that should not leave a region that way. What you would still have to build is destination selection by jurisdiction, failover that stays inside it, PII pseudonymization with a local vault, and a signed record of each decision that a third party can verify. Those four pieces are what YTT Secunet provides.
Does a second hop hurt latency?
YTT Secunet's own production telemetry shows under 8 ms p99 added per request. For EU users the bigger effect is usually the opposite: routing to an EU endpoint instead of US East avoids the 80 to 100 ms Frankfurt to Northern Virginia round trip before any model compute starts.
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.