MENUCLOSE
Product · Gateway
The control plane for your AI traffic, hosted or in your VPC.
Tallin Gateway sits in front of company AI apps, developer tools, and supported SDK traffic. It forwards requests to approved providers, applies per-actor policy, and writes ledger and audit evidence. Run it hosted for the strongest central control, or in your own VPC for data residency.
Runtime signal
The gateway is where policy becomes runtime behavior.
Provider telemetry tells you what happened after the fact. Gateway traffic lets Tallin observe, cap, freeze, and attribute sanctioned API traffic while the request is happening.
What it gives you
A controlled path that leaves the chat app alone.
The gateway governs managed API and developer-tool traffic where the company needs runtime visibility, while employees keep using the interfaces they already have.
- One key per workload
- Spend and evidence stay tied to an owner, department, environment, provider route, and model tier.
- Employee attribution
- Helper tokens let IT deploy once while Tallin still attributes developer-tool usage to the signed-in employee.
- Operational evidence
- Budget caps, rate limits, anomaly freezes, route status, and failed attempts become operational evidence instead of tribal knowledge.
- Metadata-only capture
- The operational trail is stored without storing prompt or response content. Metadata-only mode stores no prompt content.
Trust posture
Choose what Tallin stores.
Operational trail only
Provider, model, cost, timing, user, route, and policy result. No stored prompt or response body.
Deeper evidence
Content audit can support deeper review, bounded by capture limits and tenant encryption.
Capture
Privacy mode is a product choice, not a footnote.
New gateway rollouts can use metadata-only capture when the customer only wants who, what, when, how much, route, and policy outcome stored. Full audit capture remains an explicit option for teams that need deeper review evidence.
SaaS gateway traffic is still processed in memory so Tallin can route it. Only self-hosted/VPC deployment fully removes Tallin-hosted data-plane visibility.
Deployment
Hosted for the strongest control. Or run it in your own VPC.
The same gateway, two ways to deploy, so data-residency requirements never force you to choose between control and compliance.
Tallin-hosted
Strongest immediate control
- Disable an actor's Tallin-mediated model access, cap spend with an automatic cutoff, block models, and rate-limit, central and immediate, in the live request path.
- Fastest setup: mint a gateway key and you are routing.
- Tallin sees routed metadata and any capture content you configure.
In your VPC
Data residency + local enforcement
- The gateway runs inside your environment; traffic and content stay local.
- Tallin syncs policy down and the gateway enforces it locally.
- Only agreed, content-free metadata crosses the boundary: provider, model, cost, policy result, never prompts or responses. The gateway fails closed on stale config.
Built for banks, hospitals, and other regulated teams. Talk to us about VPC deployment
Both deployments govern the AI routed through Tallin. Neither stops direct provider calls or tool side effects that happen outside Tallin. Those are reported as uncovered, never silenced.
Compatible routes
Built for the SDKs teams already use.
| Route | Format | Use case |
|---|---|---|
/v1/messages | Anthropic Messages | Claude Code and Anthropic SDK calls |
/v1/messages/count_tokens | Token count | Audit evidence without spend |
/v1/responses | OpenAI Responses | Codex and OpenAI SDK-compatible apps |
/v1/chat/completions | Chat Completions | Existing OpenAI-compatible app traffic |
Put runtime evidence behind your AI policy.
Start with one sanctioned workload, route it through Tallin, and confirm the Spend Ledger row before expanding.