Your agents: governed on every call. Assured for life.

Anyone can ship an agent. Staying in control of it is the hard part, and that is what Brutor Agent Control is built for. You build the agent the way you like. Brutor takes over at one base URL: every call it makes is enforced against a contract you approved, its normal is learned from its own runs, anything that drifts is named with its likely cause, and the evidence ends up in a report your management and your regulator can read.

Request Demo Download Free Trial

This is one real run of the Brutor Demo System, a loan pre-screening agent that runs around the clock against Brutor and is high risk under the EU AI Act. Nine governed actions, numbered in the order they happened: two MCP tools, a sandboxed skill, a model, a second agent (which made its own model call, 6a), a stronger model, and the write-back. Every one of them went through the gateway, and every one was answered.

Brutor Admin Console, the Composition tab of the Brutor Demo System with a run overlay applied. The run picker shows a completed run of release brutor-demo-screening-agent@0.2.0 with 9 actions. On the left, the agent. In the middle, one Brutor Gateway box holding 2 policies, 17 limits and 2 guardrails over four lanes: LLM Proxy, MCP Proxy, A2A and Skill Executor. Numbered badges sit on the green lines to what the run used: 1 and 8 to the applications MCP server, 2 and 3 to the credit bureau MCP server, 4 to the affordability-check skill, 5 to OpenAI GPT-5.2 Auto-Routing, 6 to the Brutor Demo Fraud Screener agent, with 6a inside it on gpt-5.2, and 7 to OpenAI GPT-5.5. On the right, the sequence of the 9 actions under three steps (gather the application facts, assess risk and fraud, decide and record), each answered, from 18 milliseconds for an MCP call to 6.2 seconds for the drafting model. — One run on the agent’s composition, as the console draws it: what the contract allows (the whole graph), what this run actually used (the numbered badges), and how each call went. The dash-dot line from the agent is its overall health, which reads degraded for a reason step 05 explains.

how it works

You build. Brutor takes over at one base URL.

Seven steps, from your IDE to your regulator’s desk. The first one is yours; everything to the right of the dotted line is what Brutor does, every day the agent runs. The same picture follows you down this page, lit where each step happens.

The AI System assurance lifecycle, with every stage highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

01 Develop 02 Route 03 Contract 04 Learn normal 05 Observe drift 06 Comply 07 Report

01 / develop

Build the agent with whatever you prefer.

LangGraph, CrewAI, AutoGen, the Claude Agent SDK, or plain code: your agent, your framework, your process. Brutor does not ask you to adopt a runtime, an SDK or a wrapper.

The demo agent is a LangGraph graph of eight nodes in Python. Nothing in it is Brutor-specific except where it sends its calls and a handful of headers it adds to them. It could as easily be a CrewAI crew or a hand-written loop; the gateway sees the calls, not the framework.

LangChain / LangGraphCrewAIAutoGenClaude Agent SDKyour own code

The AI System assurance lifecycle, with Develop your agent, the one step outside Brutor highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

Everything developers need: the Developer Corner

02 / route

Point it at Brutor. One base URL, and every call is governed.

Swap the base URL and use a Brutor key. Models, MCP tools, skills and other agents all go through the same gateway, so every call the agent makes is checked, recorded and grouped with the other calls of the same task.

The gateway speaks the dialects your code already uses (OpenAI, Anthropic, Gemini, MCP and A2A), so nothing else in the agent changes. A few optional headers tell Brutor which calls belong to one task and which release of the agent made them. From then on, one task is one run: every action, one outcome, one cost per completed task, and the contract version that governed it.

the demo agent, wired to Brutor

BRUTOR="https://brutor.borealis.example" # models: any OpenAI-compatible SDK, one base URL OpenAI(base_url=f"{BRUTOR}/v1/proxy/llm", api_key=BRUTOR_KEY) # tools and other agents: the same gateway POST {BRUTOR}/v1/proxy/mcp/{server} POST {BRUTOR}/v1/proxy/a2a/outbound # what ties the calls of one task together X-Brutor-Run-Id bds-APP-10442 X-Brutor-Agent-Name brutor-demo-screening-agent X-Brutor-Agent-Version 0.2.0

Brutor Admin Console, Runs tab of the Brutor Demo System: a list of runs, each with its run id, start and finish time, how long it was active, the actor (agent), the release brutor-demo-screening-agent@0.2.0 via python-httpx, and the outcome Completed. The list shows 50 of 671 runs in the last 24 hours. — What arrives: one row per task, with the release that ran it and an honest outcome. Six hundred and seventy-one runs in a day, none of them reconstructed after the fact.

The one change, for every client What happens to a request inside the gateway

03 / contract

Mint a contract: what the agent may do, written down.

Everything the agent is allowed to touch and every rule it must live within, frozen into one version, hashed, and approved by a named person. From then on, that contract is stamped on every run, so “what was it allowed to do in March?” has an exact answer.

What goes in. Its identity (issued through your IdP, default-deny, and the only thing that decides access). The models, MCP servers, skills and knowledge bases it may use, and the other agents it depends on, each with a role and a criticality. The policies it passes on every call: guardrails in both directions, argument policies that read what a call would actually do, and per-action grants. The limits: budgets, rate and concurrency caps, and per-run ceilings on calls, tokens, cost, duration and delegation depth. And the releases of the agent you have approved.

A person, exactly where the arguments say so. The demo agent may record any recommendation, but a decline, or a loan over 25,000 EUR, waits for an underwriter before it is written back. The run ends escalated instead of pretending it finished.

Generated, never authored. The contract is the resolved configuration, inheritance merged and the strictest value winning. Change the configuration and the contract drifts until someone approves a new version; the diff says exactly what widened and what tightened.

The AI System assurance lifecycle, with the contract highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

Brutor Admin Console, Contract tab of the Brutor Demo System, version v5 with hash ee1475edfd53, active, minted, approved and promoted by admin. What this version covers: ownership and purpose (owner Anna Berg, Head of Credit Risk; intended use pre-screening consumer loan applications, with declines and loans over 25,000 EUR held for a human underwriter; system kind agent; EU AI Act role provider and deployer, risk tier high; autonomy autonomous, inherited through 2 groups). Resources it may use: two OpenAI models, the applications and credit bureau MCP servers, Agent Skills, the affordability-check skill, and the agent identity brutor-demo-screening-worker. Policies in force: Borealis Baseline Guardrails (inherited), Brutor Demo Screening Guardrails, and the argument policy Adverse or large decisions need an underwriter. Agent implementation: the worker must declare implementation brutor-demo-screening-agent, approved release 0.2.0. What it depends on: Brutor Demo Fraud Screener, shared service, critical, contributes to decisions, following its contract v4. Automatic responses armed: drift downgrades autonomy to approval_required. — The demo agent’s contract, version 5: its owner and purpose, what it may use, the policies in force, the one release it may run, the agent it depends on, and the response armed if it drifts. The version before it approved release 0.2.0 and withdrew 0.1.0, and the diff says so.

Agent identity & A2A Governance policies Usage limits & resource groups

04 / learn normal

Brutor learns how this agent normally works.

There is no universal normal for an agent. So Brutor learns each one from its own runs: how many actions a task takes, which tools and models it uses, what a completed task costs, how often it runs, and how its runs end. Until it has about fifty runs to learn from, the verdict reads learning, never a green light it has not earned.

For the demo agent, normal is nine actions per run: the eight steps of the graph plus the fraud screener’s own model call. A run that suddenly takes fifteen, or skips the fraud screen, is not normal, and Brutor can say so because it knows what normal is.

Bad days do not poison the baseline. When something outside the agent goes wrong (a provider outage, planned maintenance), you declare an incident window: its runs are kept as evidence but excluded from judgement, and the shaded band on every chart says so.

The AI System assurance lifecycle, with the run ledger and the baselines learned from it highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

Brutor Admin Console, Signals tab of the Brutor Demo System, Trajectory length, observed. Median actions 9, p95 actions 9, max actions 11, exhausted 0.0 percent. A chart of average actions per run over the last 24 hours rises from the left edge and settles near 8, with a grey shaded band at the start labeled as a declared incident window whose runs are kept as evidence but not judged: a platform incident on 28 September 2026. A histogram below: 159 runs of 1 to 2 actions, 32 of 3 to 5, 550 of 6 to 10, 18 of 11 to 20, none longer. — What normal looks like for the demo agent: nine actions per run, almost every run inside six to ten, nothing exhausted. The grey band is a declared incident: kept, not judged.

AI Systems Assurance, in depth

05 / observe drift

Watched every day it runs, and told why when it moves.

Seven signals score the agent continuously: liveness, behavior, reliability, cost, conformance, oversight and review. Health is always the worst of them, never the average, because an agent that is cheap, fast and ignored by its approvers is not 80% healthy.

The humans are measured too. The demo agent is a good example. Every machine signal is within its floor and the fraud screener it depends on is healthy, and the verdict is still degraded: most of the decisions it held for an underwriter expired with nobody deciding. A human control nobody exercises is not a control, and Brutor will not draw it green.

Drift arrives with a cause. “Something changed” is an alert nobody can act on. Brutor names the likely reason: a new model version, a changed tool, a release nobody approved, a failing dependency, different inputs. Closing a finding takes a kind and a note, and each kind has one effect: an accepted change re-learns the baseline, a fixed cause declares an incident window, a false positive is detector feedback. Windows excuse performance, never facts: an outage can explain a slow week, not a tool outside the contract.

And the response fits the problem. Tighten a permission, drop the agent to approvals-only, pause it, or stop one run without stopping the agent. Previewed first, recorded always, and in effect before the next request lands. Every finding lands in one Assurance Inbox, goes to Slack or a signed webhook, and is closed by a person with a disposition and a note.

The AI System assurance lifecycle, with the seven signals, the health verdict, the fleet board and drift findings with their response highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

Brutor Admin Console, Signals tab of the Brutor Demo System, Overview. The header reads Degraded 16 percent, Alive, Drift 1 open, Coverage 100 percent. The overall verdict panel says Degraded: oversight drives the verdict, it is the weakest enforced signal at 16 percent, below the 80 percent floor, and 250 of 299 approval requests expired without a human decision. The signal table: Liveness 100 percent, Behaviour 100 percent, Reliability 97 percent, Cost 100 percent, Conformance 90 percent and Review 100 percent, all within floor; Oversight 16 percent, below floor, drives the verdict. Below, one dependency: Brutor Demo Fraud Screener, shared service, critical, tested, healthy. — The demo agent on a real morning: every machine signal within its floor, its dependency healthy, and the verdict degraded, because oversight scores the people, not just the software.

Brutor Admin Console, Drift tab of the Brutor Demo System. A panel headed Baselines reset by a resolution lists two metrics re-learning since an accepted change by admin: actions per run, ready with 1563 samples since, and caller mix, ready with 201 samples since. Below, a medium finding Caller mix shifted, times two, with no cause identified, closed as an accepted change with the note that a platform measurement change, not agent behavior, moved the client label. Below that, an open high finding Unapproved release for brutor-demo-screening-worker, cause: the agent shipped a new release; it ran brutor-demo-screening-agent@0.1.0, declared, which is not among its approved versions (0.2.0), with Investigating and Close buttons. On the right, the automatic response policy Drift downgrades autonomy to approval_required, human restore, cooldown 60 minutes, and a list of recent responses. — Drift on the demo agent: two baselines re-learning after a person accepted the change, with their note on the record, and a finding for a release that was not on the approved list, with the release named as the cause.

Brutor Admin Console Inbox. The Assurance Inbox shows 8 critical, 33 open and 2 acknowledged findings, filtered to open plus acknowledged, warning plus critical, all categories. Rows carry a severity, a category such as Liveness or Check breach, a title such as AI System Customer Service Chatbot has gone silent or Check rate breached: Claims triage error rate, a recurrence counter like x6 or x71, the status open and a timestamp. Below, a Continuous checks panel lists 6 enabled of 7 defined tier A checks, each versioned, approved by admin and enabled. — The Assurance Inbox, across a whole estate: every finding in one queue with its severity and recurrence counter, and the continuous checks that raise them, each versioned and approved.

Drift, health and response, in depth Analytics & observability

06 / comply

Compliant with the rules where it operates, with the evidence.

Declare where the agent operates and what it does, and Brutor works out which obligations apply, from when, and whether the evidence is there. The EU AI Act first, with ISO/IEC 42001, SOC 2, GDPR, HIPAA, DORA, NIS2 and others read from the same evidence.

Obligations are derived, not ticked. The risk tier, your role (provider, deployer or both), the models the agent uses and the agents that depend on it decide which articles apply. Risk travels along the dependencies: the demo’s fraud screener is declared minimal risk, but it contributes to a credit decision, so it is evaluated at high. Every obligation carries its date, so “what changes in December, and for which systems?” has an answer.

High risk tightens the gate. A high-risk agent cannot move toward production without a named approver on every step and an unexpired impact assessment attached as evidence. It could not have gone live without it.

Evidence an auditor can check without trusting us. Every decision the gateway reaches is sealed as a signed record, refusals included, because a log that only keeps successes cannot prove its gates ever fired. The records go into an append-only log per tenant whose checkpoints can be countersigned by an independent witness.

The AI System assurance lifecycle, with the evidence compliance is read from: governed calls, the run ledger and the contract highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

The demo agent under the EU AI Act: its sealed declaration, which obligations apply today and which arrive when, and more than twenty thousand sealed records behind them.

Brutor Admin Console, Lifecycle tab of the Coding Agent Fleet. A stage strip reads proposed, approved, active, deprecated, retired with this system at approved. The gate approved to active is open with four checks passed: a contract minted for the current configuration, an approver recorded on the contract, a liveness expectation set, and the bound replay suite passed against the current contract. A panel headed High-risk (EU AI Act) states that a named approver is required on every transition plus an unexpired impact assessment at proposed to approved. On the right, the replay suite pre-v2 with 30 cases and a 90 percent pass threshold reports Last replay passed with 30 matched and a 100 percent pass rate. — The gate on another system: the conditions for going live, the high-risk floor no tenant policy can lower, and a replay suite that proves a change against recorded runs before it ships.

How the evidence becomes compliance Audit & compliance in the gateway

07 / report

One report for management and the regulator.

Everything the loop produced rolls up into one assurance report per agent: its status, what Brutor knows, what prevents full assurance, the verdict, its dependencies and their health, and the releases it ran. Download it as JSON or print it to PDF from the console.

The report is honest in the one place most reports are not: it ends by stating what it does not cover. The demo agent’s report reads assured with exceptions. It stayed inside the bounds its approvers signed, but its runs carry no signed execution chains yet and no independent evidence is attached, and the report says so in plain words rather than rounding up.

The AI System assurance lifecycle, with the health verdict and the assurance report highlighted. On the left, outside Brutor, you develop your agent with any framework and point it at Brutor with one base URL; a dotted line marks where Brutor takes over. Inside Brutor, governed calls become a run ledger, baselines learn what normal looks like, and a version-hashed contract records what was approved. Seven signals (liveness, behavior, reliability, cost, conformance, oversight and review) combine worst-of into one health verdict, which drives the fleet board, drift findings and response, and the assurance report. Recorded runs can be replayed.

The first page of the AI System Assurance Report for the Brutor Demo System, printed to PDF: spec 1.9, period 720 hours. Assurance status: assured with exceptions, operating envelope. What we know: it operated within its approved operating envelope during the reporting period. What prevents full assurance: 100 percent of runs lack cryptographically signed execution chains, and no independent evidence is attached. Recommended action: remain under monitored operation. Evidence maturity Controlled: operational evidence ok (1817 runs fully observed), behavioral stability ok, contract assurance ok, execution evidence missing, independent evidence partial. Verdict: assured with exceptions, 35 governed refusals or responses on record. System: owner Anna Berg, kind agent, lifecycle active, risk tier high, health degraded because oversight is the weakest component at 17 percent. Dependencies: Brutor Demo Fraud Screener, shared service, critical, tested and healthy. — The demo agent’s assurance report, printed from the console: what is known, what is missing, and what to do about it, on one page a board or a supervisor can read.

The method behind it: the AI Systems Assurance white paper Assurance on docs.brutor.ai

one agent, end to end

The whole demo is open source.

The Brutor Demo System pre-screens consumer loan applications for a fictional Stockholm lender, Borealis Consumer Finance AB. Eight governed actions per run, each under a rule you can point to. Point it at a free trial and watch Brutor learn it, judge it, and seal the evidence.

Step	What the agent does	Through Brutor	The rule that applies
1 · Intake	Loads the application	MCP · loan applications	An agent grant for that one tool; nothing ungranted is reachable
2 · Verify identity	Checks the applicant	MCP · credit bureau	Agent grant; an unverified applicant is always referred
3 · Credit report	Pulls the report	MCP · credit bureau	A sensitive read, sealed as evidence
4 · Affordability	Runs the lender’s own policy	Skill · sandboxed	The recipe never leaves Brutor; per-skill limits
5 · Classify	Scores the risk	LLM · classifier model	Budgets, run caps and guardrails
6 · Fraud screen	Asks a second agent	A2A · fraud screener	A declared critical dependency; delegation depth capped
7 · Decide	Drafts the recommendation and the customer letter	LLM · drafter model	The letter carries the AI disclosure
8 · Record	Writes the recommendation back	MCP · loan applications	A decline or a loan over 25,000 EUR is held for an underwriter

Get the demo system Download Free Trial

who controls what

Clear lines, on purpose.

Nobody should need a meeting to work out whose job something is. Here is the split, step by step: what Brutor handles, and what stays yours.

Step	Brutor handles	You decide
Develop	Nothing: your framework, your process.	What the agent is for, its code and prompts.
Route	Every call checked and recorded; one run per task.	Which calls belong to one task, and how the agent names its release.
Contract	The resolved contract (grants, dependencies, releases, policies, limits), versioned and hashed.	What the agent may use, which tools and agents to trust, and who approves.
Learn normal	Baselines from the agent’s own runs; incident windows kept out of judgement.	When a change is the new normal.
Observe drift	Seven signals, drift with a cause, the Inbox, alerts and measured responses.	The response policy, and the disposition on every finding.
Comply	Obligations derived and dated; every decision sealed as evidence.	The risk tier, your role, and the documents only you can write.
Report	One report per agent, saying what it does not cover.	Whether the risk is acceptable, and who signs.

A fully working lifecycle needs a fully working platform underneath it, and Brutor was purpose-built as one: gateway, identity, policies, discovery and evidence in a single system. See the whole platform

see it on the real product

The whole story, on video.

Deep dives into every capability on this page, recorded on the live platform, a few minutes per episode.

Agent Governance with Brutor

Five episodes: AI Systems, identity & authorization, the agent network (A2A), and observability.

Watch the series

AI Systems Assurance with Brutor

Seven episodes: the run ledger, liveness, drift with a cause, contracts & the gate, replay, and the health report.