What is Opsta AI Gateway

Opsta AI Gateway is an enterprise control point for all of your organization's AI traffic. Every large language model (LLM) request and every AI-agent (MCP) tool call passes through one governed gateway that runs entirely in your own environment — so you control the cost, the access, and the risk, and your data never leaves your infrastructure.

Why a gateway

As teams adopt AI, two problems appear at once:

• AI becomes a budget line. Every team calls LLMs directly, with no caps and no attribution. The monthly bill is a surprise, and no one owns it.
• AI becomes a risk surface. There's no control over who uses which model, no masking of sensitive data, no guardrails against prompt injection, and no audit trail of what was sent — often through a third-party cloud you don't control.

Opsta AI Gateway puts a single, governed control point in front of all of it.

What it gives you

• Control the cost — hierarchical USD budgets (organization → project → group → user), per-minute token limits, semantic caching that cuts spend, and FinOps chargeback + forecast (exportable per-tenant cost statements priced from the same rates you enforce, plus month-end budget projection). See Budgets & limits and FinOps.
• Govern access & safety — API-key authentication, role-based access control, PII masking, prompt-injection guardrails with review & approval (versioned, 4-eyes, revertible), an emergency AI kill-switch that halts all traffic for a project/org/platform in one click, and a full audit log.
• Govern the prompt — enforce a project-wide system prompt that clients can't strip (prompt management), and publish reusable, versioned prompt templates apps invoke by name.
• Audit what was asked — optionally capture the prompt and model output per project for debugging and abuse investigation, with opt-in-per-project, bounded retention, and admin-only access (prompt logging).
• Connect any provider — OpenAI-compatible endpoints and native providers (AWS Bedrock, Google Vertex, Anthropic Claude, Google Gemini) via automatic protocol translation, with per-provider key failover — your apps keep speaking one OpenAI-style API.
• Roll out models safely — split a model's traffic across two providers by weight to A/B test or canary a new model, ramping with no client changes (rollouts).
• Route automatically — let clients send the model auto and have the gateway pick the right model from the prompt, so casual traffic avoids premium rates (automated routing).
• Compare models side by side — send one prompt to several models at once and read their answers in parallel columns to pick the best (or cheapest) for a task (Arena).
• Cut model spend — route easy prompts to a cheap model and only the hard ones to a strong model, at a quality you set, with the savings measured before you enable it (cost routing).
• Shrink tool-heavy traffic — deterministically compress verbose tool_result content before it reaches the model, with realized savings and a dry-run token preview (tool-result compression).
• See what you saved — a live realized-savings figure (semantic cache + compression, priced) with the % off your would-be spend, right on the FinOps dashboard (FinOps).
• Govern AI agents — give each autonomous agent a trusted, first-class identity (AI Agents): a verifiable, revocable credential carried through every LLM and tool call, so spend, access, and audit attribute to the agent. Register and govern remote MCP servers, or turn an existing REST API into a governed MCP server from its OpenAPI spec, so your agents' tool traffic is authenticated, isolated per project, and observed — the same controls as your LLM traffic. One Agent & Tool catalog shows every agent and tool across the org with its owner and risk tier, and you can restrict which tools each agent may call (a per-agent tool allow-list, enforced at the gateway).
• Scaffold platforms in chat — a project-scoped platform-engineering chat where a member describes what to scaffold and an AI agent proposes it, with an approval gate (review the diff, approve or reject) before anything is opened on GitHub; the conversation and its resulting pull request persist across reloads.
• Keep it yours — self-hosted and air-gap installable. The data plane runs in your cluster; sensitive prompts and data never leave your environment. See Data sovereignty.
• Back up & recover — self-hosted backup & disaster recovery: point-in-time PostgreSQL recovery plus Kubernetes-resource backups to an in-cluster object store, with a single-sign-on web console (gated to admin groups) to run and restore them — no external cloud dependency.
• Run the platform itself — the self-hosted services the gateway depends on come with web consoles: an object-store Admin UI (SeaweedFS — browse buckets and cluster topology) and a secrets backend on OpenBao (open-source, MPL-2.0) with a UI and Keycloak single sign-on. No cloud object store, no proprietary secrets service.
• Built for many teams — true multi-tenancy: one platform serves many organizations, projects, groups, and users, each with isolated config, budgets, and dashboards.

Who it's for

• Developers consume the gateway like any OpenAI-compatible endpoint — see the User Guide.
• Organization & platform administrators configure providers, budgets, guardrails, MCP, and SSO from the web console — see the Administrator Guide.
• Platform engineers install, secure, scale, and operate it on Kubernetes — see Deploy & Operate.

It fits internal AI platforms, multi–business-unit enterprises, and organizations with strict data-sovereignty or regulatory requirements.

Self-managed or fully managed

Run Opsta AI Gateway yourself, or have Opsta deploy, run, and support it for you as a managed service with 24×7 monitoring and a banking-grade SLA.

Next steps

• Key concepts & glossary — the vocabulary used throughout these docs.
• Architecture — how the pieces fit together.
• Request lifecycle — what happens to a request as it passes through.
• Reference architecture — deployment topologies, component diagrams, sizing, security, and compliance for your architecture-review board.