The AI Control Plane
At the centre of the platform sits the Brutor AI Gateway: a single entry point that your AI systems, MCP/IDE clients and the User Portal all call, and that fronts every AI resource you allow — models, MCP servers, agent skills, knowledge bases and peer agents.
Read the picture in two halves. The enforcement half runs in the request path on every call — it can block, redact or refuse, and there is no opt-out path around it. The evidence half is what every call leaves behind: the run ledger, the signed call chain, and the signals that feed assurance. Governance you can switch off is advice; this is neither optional nor after-the-fact.
Clients don’t change to get this: point an existing OpenAI or Anthropic SDK at the gateway’s base URL and every request is authenticated, policy-checked, metered and logged. The client sees a normal response — governance is invisible until a policy fires.
Governance: guardrails and policies
Section titled “Governance: guardrails and policies”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. |
| Argument & semantic policies | Tool calls are checked against argument rules and semantic intent policies — refused, or held for human approval. |
| 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, model — and run. |
| 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 same gates apply to every governed surface — LLM completions, MCP tool calls, A2A delegations and agent-skill executions — so an agent’s whole loop is governed, not just its model calls.
The request path
Section titled “The request path”What actually happens to one call, gate by gate:
Two properties are worth pausing on:
- Blocked requests short-circuit. A guardrail violation or exceeded budget stops the call at its gate — the provider is never called, no tokens are spent, and the refusal is recorded with the same fidelity as a success.
- Every outcome is evidence. Allowed, cached, redacted, denied, held for approval — each lands in the run ledger, the usage record and the audit log. This is what makes assurance possible without instrumenting your application.
For the deployment view behind this picture — the Rust data plane, the Python config plane, the shared database — see Architecture.
Observing bought AI
Section titled “Observing bought AI”Not all AI traffic can route through a gateway, and Brutor does not pretend otherwise. Two mechanisms bring the rest into the same picture — observed, costed and attributed, but never enforced:
- Traffic Data Import calls provider enterprise APIs — usage and spend exports for the ChatGPT, Claude and Copilot seats you buy — and lands them in the same usage ledger as routed traffic. FinOps sees one number per team and provider, whether the tokens went through the gateway or not.
- Shadow AI Discovery collects the non-routable and unregistered traffic: discovery agents and adapters send signed events about AI usage found on the network, in repositories or in expense data — agents nobody registered, MCP servers nobody governs.