The Obot Platform v0.28.0 release is out. The headline change is a new LLM gateway: one gateway that serves every configured model in the OpenAI and Anthropic API formats, with profiles that control who can use which models, budgets that cap spend, and guardrails that block, redact, or log model traffic. This release also publishes vMCPs through the MCP Registry API, adds Keycloak and OneLogin as authentication providers, brings SCIM provisioning to Microsoft Entra ID and OneLogin, and lets MCP servers receive trusted headers that identify the caller.
If you already use Obot’s LLM gateway or model providers, wait before upgrading. v0.28.0 does not migrate existing provider credentials, models, or model access policies to the new gateway. That migration is planned for v0.28.1. The Upgrade Notes below have the details.
Unified LLM Gateway with Profiles, Budgets, and Guardrails
Before v0.28.0, Obot reached models through a separate model provider for each vendor, each with its own proxy route. A client pointed at the Anthropic route could only reach Anthropic models, and limits were a daily token cap per user. Content controls for model traffic were limited to message policies.
We built a more complete gateway now for a few reasons. The first is simple: it is what our customers are asking for. With AI, you have to exert control at every level: the LLM calls, the tool calls, and the network and file system calls an agent makes. Organizations need visibility and control at all of these levels, and Obot already covered MCP tool calls, network egress, and activity on developer machines. The LLM gateway brings model traffic under the same controls.
One gateway for every model
In v0.28.0, every model is available in the OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages formats, regardless of which provider serves it. Clients use the base URL for the format they speak:
Anthropic clients such as Claude Code add /v1 themselves, so their base URL leaves it off. Claude Code can use GPT models, and an application written against the OpenAI SDK can use Claude. Models are named provider/model, such as openai/gpt-5.5 or anthropic/claude-opus-4-8, and clients authenticate with an Obot API key instead of a provider key. Supported providers include OpenAI, Anthropic, Amazon Bedrock, Google Vertex AI and Gemini, Azure, Mistral, Groq, xAI, DeepSeek, OpenRouter, Cohere, vLLM, and Ollama. Bedrock and Azure support each of their authentication methods.
Pointing Claude Code at the gateway takes two environment variables:
Administrators manage everything from the new LLM Gateway page. The Providers tab holds upstream providers and their keys. The Routing tab holds rules that match requests by model, provider, or header and send them to other models, split traffic by weight, or define fallback chains. A routing target can also have a time-to-first-token timeout, so a streaming request that stalls moves to the next fallback instead of hanging. Routing never widens access: every model the gateway tries, including fallbacks, is checked against what the caller is allowed to use. The Connect tab gives every user ready-to-copy setup for Claude Code, Codex, OpenCode, Goose, Cline, Open WebUI, and the common SDKs, filled in with your Obot URL and the model they pick.
Profiles and budgets
Model access policies are now profiles, the same idea vMCPs introduced in v0.26.0. Each profile names users and groups, the models they can use, the budgets that apply to them, and the guardrails applied to their traffic, all edited in one form.
Budgets cap spend in US dollars, tokens, or requests over a rolling window, such as the last six hours, or a calendar window, such as this month. A budget can give each user their own allowance or be one pool the whole profile shares, can cover all of the profile’s models or only some of them, and can exempt administrators. For example, a profile for a contractor team could grant two Claude models with a shared $500 monthly budget, while a profile for the platform team grants every model with a per-user daily token cap. A request that would exceed a budget gets an HTTP 429 that names the budget and says when more becomes available. Obot prices each request at the rates of the model that actually served it, including fallbacks, and enforces budgets from its own usage records, so they are counted correctly across replicas.
Guardrails
Guardrails check content as it flows through the gateway. A guardrail can block a request or response, redact the offending text and pass the rest through, or only log what it found, and it works on streamed responses as well as complete ones. Built-in checks cover secrets such as API keys, private keys, and database URLs, custom regular expressions with ready-made patterns for PII such as email addresses, phone numbers, US SSNs, and credit card numbers, and LLM judge policies written in plain language, such as “Do not help book travel above economy class.”
Obot also integrates with Microsoft Presidio, Azure AI Language and Content Safety, AWS Bedrock Guardrails, Google Cloud Model Armor, Lakera Guard (Check Point), Patronus AI, and CrowdStrike Falcon AIDR, so organizations that already run one of these services can apply the same detection to model traffic through Obot. Guardrails are shared across Obot: the same guardrail can be applied to a profile’s model traffic and used in a guardrail filter on MCP tool calls, resources, and prompts. Every finding is recorded in the audit logs.
Claude subscriptions
Claude’s Team plan and individual Pro and Max plans are by far the most economical way to get Claude tokens. On those plans, each developer signs in to Claude Code with their own account instead of using a shared API key. We didn’t want the gateway’s controls to be available only to organizations paying full per-token API prices, so v0.28.0 supports subscription logins directly. Administrators turn on Allow Claude subscriptions for the Anthropic provider, and a developer signed in to Claude Code with a Claude subscription keeps that login and adds their Obot API key as a header:
Their Claude requests are billed to their subscription instead of a provider key in Obot, and Obot still authenticates the user, enforces model access and guardrails, and records each request in the audit log and usage reports. The subscription token is only ever sent to Anthropic.
What’s next
The gateway also sets up our next phase, which is to turn Obot into an AI-driven, self-improving AI control plane. Obot now sees model traffic, MCP tool calls, network egress, and activity on developer machines. The next step is linking those events together across every source we collect from, so the platform can drive itself. Closer in, migration for existing gateway and model provider users is planned for v0.28.1, and a later release will restore the per-provider routes for Bedrock, Azure, and Generic Responses clients.
Obot implements the MCP Registry API, which MCP clients such as VS Code use to discover servers. Since vMCPs became the way users connect to MCP servers in v0.26.0, the registry is now built on them: each vMCP a user can access appears once, with its name, description, icon, and connection URL. What each user sees follows vMCP ownership and profile access, so an authenticated request returns that user’s own list, including their personal vMCPs.
Some clients, including VS Code, don’t authenticate registry requests. Administrators can turn on anonymous discovery under Platform > Settings > MCP Registry API. Anonymous requests see only shared vMCPs whose profiles grant access to All Obot Users, and connecting to a vMCP still requires the user to sign in and have access. Anonymous discovery is off by default, because anyone who can reach the endpoint can read those vMCPs’ names, descriptions, and URLs, and the settings page warns about this before you turn it on.
Keycloak, OneLogin, and SCIM for Entra and OneLogin
Keycloak and OneLogin are now available as authentication providers, joining Okta, Entra, Google, GitHub, and the others Obot already supports. Keycloak 24 or later is supported, which gives self-hosted deployments an open source identity provider option.
Our v0.27.0 post said SCIM provisioning for Microsoft Entra ID was planned. It ships in this release, along with SCIM for OneLogin. With SCIM, the identity provider sends Obot users and groups as they change, and administrators decide there exactly which users and groups Obot can see. OneLogin sends roles, which become groups in Obot. For Entra, this means Obot no longer needs Microsoft Graph application permissions that can read the entire directory. For OneLogin, Obot doesn’t need an API credential for the OneLogin account at all. When a user is unassigned or blocked in the identity provider, they are deactivated in Obot: signed out, with their API keys and other credentials disabled. Their account and data are kept, and restoring their access reactivates the same account.
Many MCP servers behind Obot use a shared service credential to reach the system they wrap. That works, but the backend sees every call as coming from the same account and can’t record who actually acted or apply per-user rules. In v0.28.0, remote and containerized MCP servers can receive trusted headers that identify the caller: the Obot user ID, username, and email, the identity provider user ID and groups, and the ID and name of the API key used. Each header is turned on individually under Advanced Configuration > Inject Obot headers, so a server receives only what it needs. For example:
X-Obot-IDP-Groups: okta:admins,okta:engineering
Obot removes any incoming copies of these headers before forwarding a request, and the header names are reserved so they can’t be set manually in a server’s configuration. A backend that only accepts traffic from Obot can therefore trust them to attribute actions or enforce per-caller policy without trusting the client. Git-managed catalogs support the same setting as injectObotHeaders.
The Devices tab lists enrolled devices with their latest scan, and administrators can remove devices to free seats.
Local auth users are now managed from the Users page.
The Users page stays responsive with thousands of users.
Claude Environments sessions send model requests through the LLM gateway, and audit logs can be opened directly from a session.
MCP client sessions recover after an MCP server restarts.
The vMCPs page remembers whether you chose the card or table view.
Upgrade Notes
Existing LLM gateway and model provider users should wait for v0.28.1, where migration support is planned. The per-provider routes for Bedrock, Azure, and Generic Responses return HTTP 410 until they are restored in a later release.
Message policies are converted into LLM judge guardrails, and every converted rule starts disabled. Review and enable them under LLM Gateway > Profiles.
Anonymous MCP Registry API discovery is now opt-in and configured in the app. OBOT_SERVER_ENABLE_REGISTRY_AUTH no longer has any effect.
The X-Obot-* attribution headers are reserved. Remove any manually configured copies before upgrading.
OBOT_SERVER_AUTH_OWNER_EMAILS and OBOT_SERVER_AUTH_ADMIN_EMAILS are removed. Users keep the roles they were granted.
During a rolling upgrade, v0.27 pods can return errors until the rollout finishes.
Embedded PostgreSQL moves from 17 to 18 and requires a dump and restore before upgrading. Installations using external PostgreSQL are not affected.
That’s v0.28.0: one gateway for every model with budgets and guardrails, vMCPs your clients can discover, more identity providers in charge of who gets in, and MCP servers that know who is calling.
