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.
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:
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
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
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:
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.
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:
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:
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 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.
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.
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.
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.