Change one URL. Everything else is someone else's job now.
Point your OpenAI, Anthropic or MCP client at the Brutor AI Gateway and keep coding. Access control, guardrails, budgets, caching and audit apply on the way through — without a line of it living in your codebase.
# Before client = OpenAI(api_key="sk-...") # After — same code, now governed client = OpenAI( api_key="sk_brutor_api_...", base_url="http://localhost:8100/v1/proxy/llm", )
A base URL and a key. No SDK, no wrapper, no rewrite.
The gateway is wire-compatible with the client you already use. Whatever dialect your code speaks — OpenAI, Anthropic native, Gemini native, MCP or A2A — you swap the base URL and authenticate with a Brutor key. Streaming, tool calls and embeddings behave exactly as before.
BRUTOR="http://localhost:8100" export OPENAI_BASE_URL="$BRUTOR/v1/proxy/llm" export OPENAI_API_KEY="sk_brutor_api_..." curl -s $OPENAI_BASE_URL/models \ -H "Authorization: Bearer $OPENAI_API_KEY" # → the model list is YOUR governed list, # not the provider's full catalog
Two environment variables convert any OpenAI-compatible tool, script or framework — nothing else to install.
export ANTHROPIC_BASE_URL="http://localhost:8100" export ANTHROPIC_API_KEY="sk_brutor_api_..." # a Brutor key, not an Anthropic key claude # every model call now goes through the gateway
Anthropic-native clients keep their own dialect — the gateway serves /v1/messages directly, no /proxy/ prefix.
What you get for that one change: your calls carry a real identity instead of a shared vendor key, guardrails and budgets are enforced before the provider is reached, responses can be cached, and every call lands in an audit trail — with none of it implemented in your application.
Six kinds of building. Governance comes with all of them.
Each lane has a written guide that ends with working code, and most have a video series showing the governed result from the operator's side — useful for knowing what happens when your call is blocked, throttled or held for approval.
“I'm building an AI application”
Chat, streaming, embeddings, images and audio through one OpenAI-compatible API. Model routing, fallbacks and caching are configuration, not code you maintain.
“I'm building an MCP server”
Register it once and it becomes a governed tool surface: per-tool access, argument policies, OAuth handled by the gateway rather than by every client separately.
“I'm building an agent”
Every URL in the agent's config points at the gateway — LLM, tools and agent-to-agent alike. One governed loop, and the run ledger groups all of it into tasks you can reason about.
“I'm authoring Agent Skills”
Versioned, sandboxed capabilities with progressive disclosure — models see a preamble first and load the full skill on demand. Only what SKILL.md declares can run.
“I'm building a chat client or portal”
The Portal API is the same one Brutor's own User Portal runs on: end-user auth, conversations, models, knowledgebases and approvals — build your own front end on a governed back end.
“I'm grounding AI in our own data”
Knowledgebases with 8 connectors — Confluence, Jira, SharePoint, Slack, Notion, GitHub, Google Drive, web crawl — and hybrid retrieval, all behind the same access model as everything else.
If it takes a base URL, it's already compatible.
Coding agents, IDE assistants, chat UIs and frameworks don't need plugins or adapters. They need the gateway's URL where the provider's used to be.
Claude Code
Set ANTHROPIC_BASE_URL and a Brutor key. Model calls are governed; MCP servers added via the gateway URL bring tool governance too.
Cursor · Continue · any OpenAI CLI
Set OPENAI_BASE_URL to the proxy path. The models the tool can see become exactly the models you're allowed to use.
Goose & Claude Desktop
Add an MCP endpoint of the form /v1/proxy/mcp/{server_id} and tools arrive pre-filtered by your per-tool grants.
LangChain & LangGraph
The stock OpenAI integration works unmodified — pass the gateway base URL to the client constructor and chains inherit routing, budgets and audit.
Open WebUI
Point its OpenAI connection at the gateway to give a whole team a familiar chat UI on governed rails.
Your own service
Anything that can speak HTTPS to OpenAI, Anthropic, Gemini, MCP or A2A can speak it to the gateway. That is the point.
One host, every runtime surface.
Everything below is served by the same gateway process on port 8100, under one authentication scheme: Authorization: Bearer sk_brutor_api_... (or X-API-Key, or a portal JWT for end-user surfaces).
| Surface | Endpoint | Notes |
|---|---|---|
| Chat & completions | POST /v1/proxy/llm/chat/completions |
OpenAI-compatible; SSE streaming with "stream": true |
| Responses API | POST /v1/proxy/llm/responses |
The newer OpenAI shape, same governance |
| Embeddings | POST /v1/proxy/llm/embeddings |
Governed and budgeted like chat |
| Models | GET /v1/proxy/llm/models |
Returns your governed list, not the provider catalog |
| Images · audio · video | /v1/proxy/llm/images/generations · audio/speech · audio/transcriptions · video/generations |
Media modes carry their own governance settings |
| Anthropic native | POST /v1/messages |
No /proxy/ prefix — vendor dialect preserved |
| Gemini native | /v1beta/* |
Google's URL convention, unchanged |
| MCP tools | /v1/proxy/mcp/{server_id} |
Streamable HTTP; MCP 2026-07-28 with dual-version bridging |
| Virtual MCP | /v1/proxy/vmcp |
Many servers behind one connection for single-connection clients |
| Agent-to-agent | /a2a |
A2A v1.0 — signed cards, SSE streaming |
| Skills | /v1/proxy/skills |
Progressive disclosure — load on demand |
| Portal API | /v1/portal/* |
End-user surfaces — auth, conversations, KBs, approvals |
The full contract is machine-readable: Swagger UI at /docs, OpenAPI 3.1 at /api-docs/openapi.json — generate a client instead of reading prose.
A CLI for the loop, a workbench for the wire.
$ brutor login # Gateway URL [https://gateway.acme.com]: # Tenant ID [default]: # Username [ada]: Password: ******** # Logged in — session stored in the OS keychain. $ brutor whoami # CI-friendly, no prompt: $ printf '%s' "$BRUTOR_PASSWORD" | brutor login \ --gateway gateway.acme.com --tenant default \ --username ci --password-stdin
The Brutor CLI logs in, discovers the models and MCP servers you can use, and connects them to local tools — the discovery step you'd otherwise do by asking a colleague.
MCP Workbench
Test, debug and inspect any MCP server — yours or a catalog one — before and after it goes behind governance. See exactly which tools survive your grants.
Setup scripts
Provision tenants, keys, models and policies from a re-runnable script instead of console clicks — the same pattern Brutor's own demo environments are built with. Safe to run twice; existing rows are never stomped.
When governance says no, it says why.
A gateway that returns an opaque 400 turns every blocked call into a support ticket. Brutor's refusals are structured: which guardrail, which check, which direction — in the error shape your SDK already parses.
{
"type": "error",
"error": {
"type": "invalid_request_error",
"code": "guardrail_blocked",
"message":
"Secrets detected in input: aws_access_key",
"guardrail": "Engineering Baseline",
"check": "secrets",
"direction": "input"
}
}
A blocked call names the policy that blocked it — your error handler can tell users something true instead of “something went wrong”.
| Status | Meaning |
|---|---|
400 | Guardrail or policy refused the content — structured envelope says which |
401 / 403 | No valid principal, or the key's groups don't grant this resource |
429 | A budget, rate or concurrency cap — retry-after included |
5xx | Upstream provider fault — the gateway has already tried fallbacks first |
Worth knowing before you're paged: streaming responses can be interrupted mid-stream by an output guardrail, and a suspended AI System is refused even if the governance database is unreachable. Design retries accordingly — a 400 with guardrail_blocked will not succeed on retry.
Docs to build from, videos to see it run, a course to master it.
Documentation
Guides for every lane on this page, plus references generated from the same OpenAPI contract the gateway serves.
Video series
Short, real-console walkthroughs — see what the operator sees when your code runs, including the parts where it gets blocked.
MCP Developer Bootcamp
A hands-on Udemy course on building MCP servers properly — from first tool to OAuth, testing and registration behind a gateway.
Free to run. One URL to adopt.
Download the full stack, point your existing code at it, and watch your own traffic arrive governed — on your machine, this afternoon.