Skip to content

AI Control Plane

Brutor governs AI Systems: the agents, assistants, applications, workflows and services your teams run in production. Each one has an accountable owner, a stated purpose, and a contract of what it may use, spend and reach.

The control plane sits in the request path of routable traffic, where it enforces the policies and limits you set. Recording every call matters just as much: that record is how Brutor learns how each system normally behaves, and how it later proves whether it still does.

Brutor product overview. Three kinds of AI traffic reach Brutor: routable AI systems — agents, assistants, applications, workflows and services — are governed in the request path; non-routable chat clients such as ChatGPT, Claude Desktop and Microsoft Copilot are imported from provider enterprise APIs and observed only; shadow AI is found by discovery agents and adapters sending signed events. Inside the control plane, Assurance and Observe sit side by side, both wrapped by FinOps — one usage ledger with cost per run, team and model. Within the assurance half, Govern enforces compliance, guardrails, policy, limits and routing on every hop. Discover inventories shadow AI, with an arrow back into Govern: converting a discovered system means bringing it under enforcement. The Brutor User Portal enters the plane as a governed chat workspace. Beneath the plane sit the AI resources it fronts: models, MCP servers, agent skills and agents.

Three kinds of AI traffic reach the platform, and the platform is honest about the difference between them:

Traffic How it arrives What Brutor can do with it
Routable AI Systems — agents, assistants, applications, workflows, services Their base URL is the gateway Governed — every call is enforced in the request path
Bought AI — Claude for Work, the OpenAI platform, Azure OpenAI, Microsoft 365 Copilot Usage imported from vendor enterprise APIs Observed — costed and attributed, never enforced
Shadow AI — agents, MCP servers and apps nobody registered Collectors and scanner adapters send signed events Discovered — inventoried, then converted into governed systems

A control plane is a place decisions are made, and for routable traffic that place is the request path itself. An AI System points at one base URL, and from then on every call it makes takes one hop through the gateway, where the same checks run in the same order:

How a call travels through the control plane. Your AI System points at one base URL, so every call enters the Brutor AI Gateway. Five checks run in order on every call, whether it is a model call, a tool call, an agent-to-agent call or a skill: identity, access, limits, policy and guardrails. A call that fails one is refused before it leaves, so it costs nothing. Calls that pass reach models, tool servers, agents and skills, and the response is checked again as it streams back. Every decision is written to the audit and usage ledger: who called, which model answered, what it cost, and which rule fired.

Check What it decides Where it is configured
Identity Who is calling: a person, an application, or an agent with its own name and owner Users and API keys, agent identity
Access Whether that caller may use this model, MCP server, skill or peer agent at all Resource groups
Limits Budgets, token and request quotas, throughput and concurrency caps, per-run ceilings Limits, contracts
Policy What the call would actually do, down to the arguments of a tool call, and what it means Argument and semantic policies, approvals
Guardrails The content itself: PII, secrets, prompt injection, jailbreak attempts, toxic content and your own banned words, on the way in and as the response streams back Guardrails

A call that fails any of them is refused before it leaves your boundary, so a runaway costs nothing. Model calls, MCP tool calls, A2A delegations and skill steps all take the same hop and the same checks: there is no second path where a different set of rules applies. The gate-by-gate walkthrough, with the status code each gate returns, is on the AI Gateway.

Because the decision happens here, the record is a by-product rather than a reporting exercise: who called, which model answered, what it cost, and which rule fired. That ledger is what assurance reads back, and what an audit is answered from.

Governing a request is the easy half. Proving that an AI System still behaves, months after it shipped, is the other one, and it rests on five things that only exist because every call was enforced in the same place:

Assurance in three steps, drawn as a loop. First the contract: what the AI System may do, pinned by a hash. Second the run ledger: every task recorded, which teaches Brutor the normal band for this system; one run steps outside the band and is flagged with its likely cause. Third the assurance report: one verdict, the runs behind it, and what it does not cover. An arrow returns from the report to the contract, marked respond: tighten a limit, require approval, or pause.

  • Contract — a hash-pinned snapshot of every control that applies to the system, generated from resolved live configuration rather than written by hand, so the document cannot disagree with reality. It carries per-run ceilings that the gateway checks before each call.
  • Run ledger — work is recorded as runs, not requests: the steps, the terminal state, the cost. That ledger is also how each system learns its own normal from its own history.
  • Drift — when behaviour moves off that baseline, the finding leads with the likely cause, such as a model update or a changed tool definition. When nothing lines up it reports unexplained, because a guessed cause is worse than none. Liveness covers the failure drift cannot: the system that goes silent.
  • Cost per completed task — read off the same runs and judged against the bound the contract declared, with budgets refusing the call before the spend exists.
  • Assurance Report — one verdict in words, the runs that support it, and a closing section on what it does not cover. Snapshots are immutable, so the report read in December is the one that was captured.

Health is worst-of, never an average, and learning is never rounded up to green. When a signal does fire, the response is graduated through the system’s autonomy level rather than a single kill switch, and a single misbehaving run can be stopped on its own.

Start with AI Systems if the term is new, then how assurance works.

A vendor app talks to the vendor’s own service, so nothing can stand in the path of those calls. What the platform does instead is count them, cost them, and give people a governed place to work:

How commercial chat client traffic is imported. Three vendor apps that cannot be routed, Claude for Work, the OpenAI platform and Microsoft, send usage through a read-only import into one usage ledger, where imported spend sits beside the traffic you route. What you get from it: who used it by person and team, what it cost in one total, budget alerts that advise, and a register row marked Observed. Nothing here can block, redact or route a call.

  • Traffic Data Import pulls usage from each vendor’s enterprise analytics API. Coverage differs by vendor: tokens and cost for Claude for Work and the OpenAI platform, cost only for Azure OpenAI, activity counts only for Microsoft 365 Copilot.
  • Imported spend lands in the same ledger as routed spend, attributed to people and teams, inside the same budgets and alerts. Every row says which it is, because imported traffic already happened: its alerts advise, they never refuse a call.
  • For the conversations you do want governed, the User Portal gives employees approved models, tools and company knowledge on your policies and your audit trail.

You cannot govern an estate you have not finished counting, so Brutor counts first and asks you to decide second. Nothing in this plane intercepts a call or reads a payload:

Discovery in three steps. Count: collectors and adapters you already run report the AI clients and tool setups on a laptop, what scanners in your CI find, and what egress logs show, as signed read-only events. Place: each finding is matched against live gateway configuration, so coverage becomes a bar showing how much of what was counted is governed. Onboard: a discovered asset arrives with an owner and its configuration pre-filled, and pointing it at the gateway is what makes it governed. Metadata only: no payload is read and no call is intercepted.

  • Shadow AI Discovery takes signed, read-only events from collectors and from adapters on the scanners you already run. Brutor Scout inventories the AI clients installed on a workstation and reads each one’s MCP server configuration, so the tools a developer wired up locally surface as assets.
  • Findings are reconciled against live gateway configuration, so coverage becomes a number you can report rather than a feeling about how much AI is out there.
  • The Asset Register holds one row per asset across all three states, with an owner, an intended use, a risk tier and a lifecycle stage. Each asset carries a fact sheet whose snapshots are append-only: the point-in-time evidence an auditor asks for, and what ISO 42001 counts as design documentation.
  • Onboarding a discovered asset is a routing decision, not a migration project: it arrives with its configuration pre-filled, and pointing the workload at the gateway is what makes it governed.

The AI Asset Register with a fact sheet beside it. The register lists one row per asset with its kind, owner and state: a model and a tool server, both governed; an AI System owned by Underwriting, governed; a vendor chat client owned by Marketing, observed; and a tool server found on a laptop with no owner yet, discovered. A counter reads 137 counted and 96 governed. The fact sheet for the discovered row shows how the asset was found, when it was first seen, that no owner or intended use is set yet, and two actions: onboard with the configuration pre-filled, and take a snapshot. The rows are illustrative.

The MCP Registry is your own subregistry on the official specification: it federates upstream registries, carries the servers your teams publish, and stamps every served record with its gateway-governance posture, so a developer browsing for a tool sees at a glance whether using it is sanctioned. The registry reports that status; the gateway is what grants it. Versions are immutable, and deprecating a server carries a status note back to every consumer.

The Brutor MCP Registry as a developer sees it. A list of servers with where each came from, its version and its status: two internal servers marked governed, meaning the gateway fronts them; one federated from an upstream registry, not governed; and a deprecated internal server carrying the note superseded by billing2, migrate by the end of Q4. Beside the first row, connected to it, a versions card shows v1.4.0 current and immutable above v1.3.0 and v1.2.0, with the rule that a change is a new version because republishing one is refused. The rows are illustrative.

No. It is a base URL and a key:

  • Your framework stays, whether that is LangGraph, CrewAI, AutoGen, the Claude Agent SDK or plain code. Point an existing OpenAI or Anthropic SDK at the gateway and every request is authenticated, policy-checked, metered and logged (LLM API).
  • MCP and A2A clients connect to the real protocols, not a Brutor dialect (MCP clients, A2A agents), and the CLI repoints the tools on a developer’s own machine.
  • The one optional addition is a run id on the request: pass x-brutor-run-id and a task’s calls group into a single run. Leave it out and every call is still enforced, costed and logged.
  • Nothing here is one-way: the governance posture exports as policy-as-code, and the register and audit evidence export in standard formats.

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.

Developer overview →

Platform & governance teams

You install and operate the gateway, decide which models and tools each team may use, set budgets and guardrails, and answer “what did we spend?”, “who did what?” — and “can we prove it?” — from Mission Control, the audit logs and the assurance reports.

Install with Docker Compose →