The infrastructure layer for production AI agents.
The model call is the easy part. Brutor governs the whole agent — its identity, the tools and agents it calls, and the output it streams back — on one control plane.
Bring any agent — LangChain, CrewAI, AutoGen, or your own code — and make it governed, observable, and interoperable, with native A2A and MCP.
/01/Connect
Every surface your agents touch — models, tools (MCP), other agents (A2A), and the skills they run — through one governed ingress.
A2A, first-class — not bolted on.
Most platforms tack agent-to-agent communication on as an afterthought. Brutor implements the A2A v1.0 specification natively in the Gateway, so every A2A call inherits the same governance and observability as a regular LLM call.
Discovery
Your agent advertises its capabilities at /.well-known/agent-card/{tenant}/{name}. Brutor signs and serves the Agent Card with Ed25519 JWS, RBAC-filtered per caller.
Streaming & delegation
SSE token streaming, full task lifecycle (SUBMITTED → WORKING → COMPLETED), push notifications, and HMAC-signed delegation chains across multi-hop calls, with a policy-enforced delegation-depth cap — all per the A2A v1.0 spec, no vendor extensions.
Same governance
A2A traffic is governed identically to LLM traffic: same auth, same cost ceilings, same audit trail. No second control plane to operate.
One config away
Turn any existing agent into an A2A-compliant endpoint other agents can call. The Gateway handles the protocol surface — no SDK rewrite.
Skills are not tools — they’re governed workflows.
An Agent Skill is a packaged, versioned unit of capability — SKILL.md instructions, scripts, resources, and templates — served to any MCP-aware agent through Brutor’s system skill server. A tool is called once and returns a result; a skill is a guided workflow the agent follows step by step, revealed through progressive disclosure and governed at every step.
Progressive disclosure, three layers. Discover costs ~100 tokens per skill; load returns the full SKILL.md plus a manifest of scripts, resources, and templates; act is three verbs — read a resource, run a script, render a template. The agent spends context only on the skill it actually uses.
Versioned and immutable. Skills arrive as an uploaded package or synced from a GitHub repository — new versions tracked as they land — and move through a DRAFT → VALIDATED → PUBLISHED lifecycle. Once published, a version is immutable — changes require a new version, so callers always know exactly what they’re running.
The bundle never leaves Brutor. Scripts execute in a separate sandboxed runner — read-only root filesystem, all capabilities dropped, per-request JWT, hard timeouts — never in the gateway, never on the agent’s machine. The agent receives instructions and script output, never the code.
Governed at every layer. There is no “approved once, trusted after” window: access is checked on discover, load, and act; skill input and output pass guardrails and argument policies; per-skill quotas and approval gates apply; and every step lands as one audit row sharing the workflow’s correlation id. Access itself is resource-groups only — built by IT, scoped per team.
# One system MCP server — five verbs, three layers POST /v1/proxy/mcp/system-agent-skill-server-default Authorization: Bearer sk_brutor_... # L1 — discover what exists (~100 tokens per skill) { "method": "tools/call", "params": { "name": "skills__list" } } # L2 — load instructions + manifest (audited, executes nothing) { "params": { "name": "skills__load", "arguments": { "skill_name": "triage-ticket" } } } # L3 — act: runs in the sandbox, returns only the output { "params": { "name": "skills__run_script", "arguments": { "skill_name": "triage-ticket", "script": "run.py", "args": { "ticket_id": "7421" } } } } # Guardrails, quotas, approval, audit — every layer, independently.
Your agents bring their own tools.
Brutor is MCP-native at the Gateway. Connect any MCP server you trust — once at the resource-group level — and every agent in that group inherits scoped access through RBAC. Tool calls are guardrailed, audited, and rate-limited at the Gateway, so you don’t have to re-implement any of that per agent.
/02/Govern
Govern what agents do — not just what they access. Identity, per-action grants, and runtime enforcement on every call.
Agents are easy to prototype. Governing them in production isn’t.
Four planes, one ingress. Every agent call — to an LLM, an MCP tool, or another A2A agent — runs the same chain, so “an agent did something” is always a decision you made: discovered, authorized, authenticated, enforced, and recorded.
MCP Registry Beta
A governed enterprise subregistry: federate public MCP servers, publish your own, and attach Brutor’s governance posture to each record — so discovery is governed discovery, not a free-for-all.
Registry · Agent RegistryAgent Identity & Policies
Every agent is a principal with per-action grants — actions, not access. Default-deny, tool-risk classes, semantic (LLM-judge) policy, and dry-run before you enforce.
Agent Policies · Semantic PoliciesSecretless brokering
Workload identity via your IdP (OIDC / JWKS), OAuth token brokering, and per-call attribution. Tokens never touch the agent; issuance stays with your IdP.
OAuth broker · Workload identityThe Rust gateway
Guardrails, argument policies, cost ceilings, approvals, and a full audit trail on every LLM, MCP-tool, and A2A call — at runtime, framework-agnostic.
Gateway proxyAn identity is not a card.
An agent has two facets. The card advertises what it exposes to peers; the identity is who it is and what it may do. Brutor governs the identity — A2A publishes the card.
Agent Identity
The security principal Brutor decides, enforces and proves against — defined under Resources → Agents → Identities. Issuance stays with your IdP.
- Owner, source, and IdP subject (e.g. SPIFFE)
- Default-deny baseline + per-action grants
- Enforce / dry-run rollout mode
- Resource-group memberships inherit ACLs & limits
Agent Card (A2A)
What an agent exposes to other agents for discovery and invocation — the A2A interop contract, served and signed.
- Skills & capabilities, version, protocol version
- Ed25519-signed, trust-tiered (unsigned → partner-signed)
- Served at
/.well-known/agent-card/… - RBAC-filtered per resource group
| Agent Identity | Agent Card | |
|---|---|---|
| Answers | “Who is this agent, and what may it do?” | “Can peers find & call me, and at what trust?” |
| Carries | Grants, default-deny, enforcement mode, memberships | Skills, capabilities, signature, trust tier |
| Faces | The gateway — authz & governance | Other agents — interop & discovery |
| Lives in | Resources → Agents → Identities | Resources → Agents → Agent Cards |
Actions, not access.
An agent policy is a set of grants on an identity. Each grant says an action type — LLM call, MCP tool, A2A call, or skill exec — on a target is allowed, denied, or approval-required. Default-deny: anything without a matching grant is refused, and deny always beats allow.
- Per-action grants across LLM, MCP tools, A2A calls and skills — glob targets,
*= any. - Tool-risk classes and constraints on grants — require approval for high-risk, block critical.
- Three-state HITL — allow, deny, or approval-required, with approval chains.
- Dry-run → enforce — roll out an agent’s authz in shadow, logging would-block verdicts, before you flip to enforce.
- Strictest-wins — the agent must satisfy its own grants and its resource-group ACL.
Govern by intent, in plain English.
Where grants and argument policies match structure, a semantic policy governs intent: write a constraint in natural language and an LLM judge evaluates every governed agent request against it at runtime.
“The request must not exfiltrate customer PII to an external destination.”
No regex, no rule trees — just the constraint, in the language you’d use to explain it to a colleague.
Ship in shadow to log would-blocks and measure judge accuracy, then flip to enforce — block or warn. Fail-open: a judge error never blocks live traffic.
Scope to agent surfaces — chat input, MCP tool calls, A2A inbound/outbound, skill input — and bind each policy to resource groups.
/03/Prove
One production agent end to end — every governed hop, and the telemetry behind every decision.
One AI system — every hop governed.
A production Claims Co-Pilot: one LangGraph agent, two models, business systems, a knowledge base, and an external partner agent. Point each connection at Brutor instead of the resource, and every hop is enforced in flight — PII masking, payment approvals, scoped retrieval, signed identity — while Mission Control records all of it.
One ingress. Full governance. Zero lock-in.
Every agent call — to an LLM, to an MCP tool, or to another A2A agent — flows through the same Brutor Gateway. That’s where auth happens, where budgets are enforced, where logs are written. Your agent code never knows which provider it’s talking to.
Change one line. Keep your stack.
Point your code at Brutor’s OpenAI-compatible endpoint — no rewrites. Six entry points: unified LLM API, MCP proxy, Skills, Portal API, your own A2A agent, and the Knowledge Base — each under the same governance, observability, and audit.
Ship your first governed agent this week.
Download the Brutor trial, point your agent at the Gateway, and watch the cost, audit, and RBAC light up — no code changes required.