Brutor is a multi-tenant AI control plane. It sits between your applications and your AI providers as a single gateway: agents, chat clients, internal apps and scripts point at Brutor instead of calling OpenAI, Anthropic, Bedrock or your self-hosted models directly. Every request that flows through the gateway is authenticated, policy-checked, metered and logged — without any change to your application code beyond a base URL.
Without a gateway, AI adoption in an organization looks like this: every team creates its own provider accounts, API keys live in .env files and CI secrets, nobody can say what the company spends on tokens this month, prompts containing customer PII go straight to third-party APIs, and when an agent calls a destructive tool there is no record of who authorized it.
Brutor solves this by making the gateway the only path to AI resources:
When a request hits the gateway, Brutor transparently applies:
| Control | What happens |
|---|---|
| Authentication & tenancy | The API key or JWT resolves to a tenant, user and resource group. No anonymous traffic reaches a provider. |
| Guardrails | Input and output checks — PII, prompt injection, jailbreak, secrets, banned words, toxicity — run inline. A blocked request returns 403 with a guardrail_blocked error; the provider never sees it. |
| Budgets & limits | Daily/monthly token and dollar budgets, requests-per-minute and concurrency caps per resource group and per model. Exceeded limits return 429 with a Retry-After header. |
| Usage metering | Tokens, cost, latency and cache hits are written to the usage ledger and attributed to the user, group and model. |
| Audit | Every decision — allowed, blocked, redacted, approved — lands in the proxy and audit logs with a correlation ID, and optionally carries compliance tags (SOC 2, EU AI Act, HIPAA, GDPR). |
The client sees a normal OpenAI-compatible (or native Anthropic) response. Governance is invisible until a policy fires.
Brutor is split into two planes plus the UIs and a knowledge-base pipeline:
brutor-gateway-core, Rust, :8100) — the runtime data plane. All LLM, MCP, A2A, OAuth and Agent Skills traffic flows through it, and it also serves the end-user Portal API (/v1/portal/*, including portal login). This is the component your applications talk to.brutor-gateway-control, Python/FastAPI, :5050) — the configuration plane. All configuration writes — tenants, users, API keys, models, MCP servers, guardrails, budgets — go through its admin API. It owns the database schema and migrations.brutor-gateway-admin, React, :3002) — the management UI for platform teams. Talks only to the Control Plane.brutor-gateway-portal, React, :3001) — a ready-made governed chat client for end users, with workspaces, model discovery, MCP tool use and knowledge bases. Talks only to the Core Proxy.Supporting the platform is the knowledge-base pipeline: the KB Uploader extracts, chunks and embeds uploaded documents into Qdrant, and the KB Connector Sync service pulls content from external sources such as Confluence, Notion, Google Drive, Slack, GitHub, Jira and SharePoint so it can be used for retrieval-augmented chat in the portal.
Both planes share one PostgreSQL database: the Control Plane writes configuration, the Core Proxy reads it (the proxy never writes config or touches the schema). That split keeps the hot path in Rust and the admin surface in Python — see Architecture for the full picture.
Developers
You build agents, chat clients and internal apps. You point your existing OpenAI or Anthropic SDK at the gateway, call MCP tools through one governed endpoint, or build a full custom portal on the Portal API. Guardrails, budgets and audit come for free — you never handle provider keys.
Platform & governance teams
You install and operate the gateway, decide which models and tools each team may use, set budgets and guardrails, and answer the questions “what did we spend?” and “who did what?” from Mission Control and the audit logs.