Busbar Puts a Governed Boundary Between Your Agents and Everything They Can Reach

The interesting thing is not the routing. It is where the credentials live and what gets recorded before an agent acts.

Most AI gateways describe themselves by what they route. Busbar describes itself by what it refuses to let through. The one-line pitch on its README is "the self-hosted execution boundary for AI systems," and the verbs that follow are the tell: control where AI can go, what it may use, what authority it receives, what it may cost, and what evidence is retained, before it acts. That last clause is doing the work. A proxy moves bytes. A boundary decides whether the bytes should move at all, and keeps a record either way. Whether that distinction is marketing or architecture is the whole question, and it is worth answering carefully, because the category Busbar is reaching for is exactly the one this month's agent-safety news keeps pointing at.

The problem it is built for

The pattern across the last several weeks of agent incidents is not that models got more malicious. It is that agents got more reach. An agent that can call a model, invoke an MCP tool, and delegate to another agent has three separate ways to touch the outside world, and in most stacks each of those paths carries its own credentials, its own network egress, and its own blind spot. When Anthropic's cyber-evaluation models drifted onto the open internet in incidents disclosed this summer and September, the root causes included a misconfiguration that left network access open when the prompt said it was closed. The lesson that keeps repeating is that scope and authority cannot live inside the agent's own beliefs. They have to live somewhere the agent cannot argue with.

Busbar's answer is to make that somewhere a single binary the agent's traffic has to pass through. Its own diagram is blunt about the shape: applications and agents flow into Busbar, and Busbar flows out to models, MCP tools, and A2A agents. Everything the agent can reach, it reaches through the boundary, and the boundary holds the provider credentials rather than the application. The credentials stay at the enforcement point, in your infrastructure, and nothing phones home.

What it actually does today, and what is still roadmap

Being honest about maturity is the difference between a useful review and an ad, so here is the split the README itself draws.

The part that ships and works today is the model execution plane. Busbar speaks six model wire protocols on both sides, OpenAI, OpenAI Responses, Anthropic, Gemini, Cohere, and Bedrock Converse, and same-protocol routes forward the original request bytes rather than re-serializing them, so calling a provider through Busbar is byte-for-byte identical to calling it directly. On top of that it does weighted routing across pools, per-lane concurrency caps, fault-attributed circuit breaking, in-flight failover before the first token, virtual keys, group budgets and spend tracking, TLS and mTLS, Prometheus and OTLP telemetry, and per-request audit webhooks. You change a base URL and a key in your existing SDK, and the enforcement point is in the path.

The part that is stated as the broader model, not a shipped feature, is the two planes that make the "boundary for agents" claim more than a routing story. Tool governance for MCP, described as caller grants, approved schemas, budget enforcement, and drift quarantine, and agent trust for A2A, described as verification, pinning, re-verification, egress control, and target-bound credentials. The README is careful to say these "use the same execution-boundary model," which is honest wording for "designed, not yet demonstrated here." If you are evaluating Busbar specifically for MCP tool governance today, that gap is the thing to test before you believe it.

The benchmark, and why it cannot be your reason to adopt

Busbar's README leads with performance numbers that are genuinely striking: 73 microseconds of added p50 latency, a 7.3 MiB idle memory footprint, 67,837 requests per second with zero failures, and a comparison table where it serves all 36 wire-protocol pairs against LiteLLM's 8, Kong's 4, and Portkey's 8, at a fraction of the latency and memory. If those hold, they are a real argument.

Here is the caution, and it is the point of this section. That benchmark is self-run. The figures are measured by the project, on the project's chosen hardware, published on the project's own site. To Busbar's credit, it does three things most self-benchmarks do not: it publishes a verdict and reason per cell, it open-sources the harness so you can disagree in public, and it states three things against itself in the README, including that LiteLLM's provider catalogue is far larger and is a real reason to pick LiteLLM instead. That is a more honest posture than the norm. It still is not independent verification. A vendor benchmark with an open harness is an invitation to check, not a substitute for checking.

So the rule for a gateway is the same rule you would apply to the agents it governs: do not trust the headline number, reproduce the one cell you care about. If your traffic is single-protocol OpenAI at moderate concurrency, run that exact shape through Busbar and through whatever you use now, on your hardware, and read your own latency and memory. The harness being open is what makes that possible. Use it.

Put this into practice

The lowest-friction way to see whether a boundary belongs in your stack is to put one in front of a single, low-stakes path and watch what it records.

Start with model traffic only, because that is the mature plane. Install the binary, write a config with one provider and one pool, and point one service's base URL at it. The README's own starter is three commands and a short YAML file, and a useful detail is that the config takes the name of the environment variable holding your key, never the key itself, so the secret stays in your secret manager and out of the config artifact. Run busbar --validate in CI so a broken config fails the build instead of the deploy.

Then turn on the two things that make it a boundary rather than a router. Enable virtual keys before you expose it to anything, because the README is explicit that the data plane has no auth chain on its own and a cluster-internal service without virtual keys is an open relay to your provider credentials. And wire the per-request audit webhook to wherever you keep logs, because the entire premise, evidence retained before the agent acts, is worthless if nothing is listening on the other end of it.

Only after model traffic is boring and observable should you test the tool-governance and agent-trust claims, and test them as claims. Put a real MCP tool behind it, try to exceed the granted schema or budget, and confirm the boundary actually refuses. If it does what the README describes, you have a single place to reason about everything your agents can touch. If it does not yet, you have learned that before you depended on it.

Honest limitations

Beyond the self-run benchmark, three things deserve to be named plainly.

The project is early. It sits around 150 stars, and the latest release is v1.5.5 from late August 2026. That is not a knock on the code, but it is a real statement about how much production mileage exists outside the maintainers, and a boundary that fails open or fails confusingly is worse than no boundary. Read the reliability and failover behavior before you route anything critical through it.

The LICENSE file carries the unfilled Apache-2.0 template, with the copyright line still reading the bracketed [name of copyright owner] placeholder rather than a real entity. The license is Apache-2.0 in intent and the README states it, so this is almost certainly an oversight rather than a trap, but it is the kind of detail that matters if your legal review needs a named copyright holder, and it is worth raising with the maintainers rather than assuming.

And the strongest claims are the least proven. The features that would make Busbar uniquely valuable for agent safety, MCP tool governance and A2A trust, are the ones described as the model rather than demonstrated in the README. The model-routing plane is a good AI gateway. Whether it becomes the agent execution boundary it wants to be depends on plumbing that is not yet in front of you to test.

The takeaway

The reason to look at Busbar now is not that it is finished. It is that it names the right problem out loud. The supervision this month's news keeps asking for, a place outside the agent where scope, authority, cost, and evidence are enforced before the agent acts, is a real architectural need, and a single self-hosted binary that holds the credentials and records the calls is a credible shape for it. Try it on model traffic, reproduce the one benchmark cell you care about instead of trusting the table, and hold the tool-governance promises to the same standard you would hold an agent's. If it passes your own check, you have consolidated a blind spot. If it does not yet, you found out on a path that did not matter.

Sources: GetBusbar/busbar README and config, GitHub; Busbar benchmark harness and per-cell verdicts, onthebench.ai; Anthropic, An alignment assessment of recent cybersecurity incidents, Sep 9 2026. Star count, license file, and release tag verified against cache-busted shields.io, raw LICENSE, and releases.atom on 2026-09-15.

Medium metadata

Tags: AI Agents, MCP, DevOps, Open Source, AI Security
Suggested subtitle: The interesting thing is not the routing. It is where the credentials live and what gets recorded before an agent acts.
Canonical: publish on fervorai.dev first, then import to Medium with canonical URL.