A year ago, Brutor AI was an MCP gateway. Today, Brutor AI is an AI control plane that helps organizations govern, understand, and assure the AI systems in production.
Ours is a story of evolution rather than a set roadmap. We set out to offer customers the most comprehensive and user-friendly tools to make the most of their AI, and every release has been a step toward that goal, often a step before the market asked for the capability.
August 2025: we started with an MCP problem
I first started thinking about Brutor AI in August 2025. At the time, the Model Context Protocol (MCP) was the talk of the industry, and for good reason: give AI models access to up-to-date information and capabilities from inside an organization, and they give your business more useful answers.
I had just published a Udemy course on building MCP servers, Mastering GenAI: MCP Developer Bootcamp. The final section touched on a problem that was becoming obvious: once organizations start connecting MCP servers to AI applications, they also need a way to manage and control that traffic – via a gateway.
I tried a few existing gateways, but using them was not straightforward. Registering an MCP server that used OAuth for authentication, with Keycloak for example, was far harder than any administrator should have to put up with. So, I decided to do something about it and started the Brutor AI project.
I architected Brutor MCP Gateway, choosing Python for the gateway core and React for the user interface. The architecture included both an MCP proxy and an OAuth proxy. I set off using Claude Opus 4 to help me build the software – I had great experience using it already when I built the MCP Workbench for testing MCP servers, so I was confident this would be the fastest way to develop.
Brutor MCP Gateway was born at the end of September 2025.
October 2025: Managing MCPs is not enough
In October, I attended MCP Dev Summit Europe in London to learn where MCP was heading and to demo the first version of our gateway to potential partners and fellow developers – the feedback was really encouraging.
I was also trying to get feedback on our plans to add LLM routing to our gateway. If you want to govern AI traffic, why govern only the tools an AI system calls? The model traffic sits in the middle of every interaction, and a gateway needs to see and control the whole flow:
prompt → tools and context → LLM → response → tool call → result
Surprisingly, there was not that much interest at the time for these plans, but we just kept going.
I added the LiteLLM library, which is written in Python and as such easy to integrate for LLM proxying and routing. It was then natural to also set up a curated catalog of LLMs with pricing information so customers could control AI costs better.
That was the first version of Brutor AI Gateway.
Winter 2025 to 2026: from traffic control to organizational control
On December 9, 2025, Anthropic reported more than 97 million monthly SDK downloads and 10,000 active MCP servers, and announced the same day that MCP would be donated to the Agentic AI Foundation under the Linux Foundation. Great news for us – when we started our project in summer 2025, MCP was still an emerging technology; by the end of the same year, it was a well-established technology with a growing ecosystem.
Besides making our gateway more robust and resilient with load balancing and failover, we also added more policies and features making the traffic more secure (guardrails, Human-in-the-loop…).
Our winter efforts were clearly focused on making Brutor more adaptable to customer needs.
Software tools should adapt to the organization, never the other way around. In Brutor AI Gateway, customers can organize their AI operations into Resource Groups – configured once, and resources follow additively and inherit limits and policies restrictively.
And finally, we also introduced Brutor User Portal – our full-featured chat interface connected to their company data – a governed alternative to public chat clients such as ChatGPT.
Early 2026: AI was becoming more than models and tools
By early spring 2026, autonomous agents and how to manage them dominated all conversations.
We introduced Agent Skills – the LLM handles the reasoning, MCP fetches and operates on the data, and Agent Skills implement the company’s domain-specific processes and procedures. Agent Skills were normally installed in the file system, but I implemented them as an MCP server, which makes them much easier to run and manage centrally.
We wanted to take Brutor to the next level by the beginning of summer, so we re-architected the whole solution, making also the biggest engineering decision of the year – the original Python proxy was never going to be the best foundation for a high-performance, highly concurrent, multi-user production environment, so I re-implemented the whole core proxy in Rust: LLM, MCP, OAuth, and Agent Skills.
The control plane, where configuration and management happen, stayed in Python. The result is a clean separation between the part of the system that needs maximum performance and the part that needs flexibility. For users, it means that governing AI with Brutor does not slow anybody down (our latest benchmarks here).
Looking back, being a small startup was such an advantage – we did not have to worry about legacy. Brutor is designed from the ground up to govern AI systems – we were not an API proxy with a gateway bolted on with limitations of what functionalities we could not offer to our users.
Spring 2026: Brutor became an AI governance platform
In February 2026, Gartner formally defined and sized a new market segment – AI Governance Platforms, giving what we have been building since the autumn a formal name and validating our direction.
We added a couple of new functionalities during spring – a big one was Policy-as-Code, so guardrails, policies, and limits can be exported as YAML, version-controlled, and stored in GitHub so customers can make their AI operations compliant with a variety of frameworks.
We added Agent-to-Agent (A2A) support. And we began building a knowledge base on Qdrant as the vector database, so documents can be indexed and retrieved to give LLMs additional context through RAG.
The product had become the Brutor AI Governance Platform. But governance means more than policies. An enterprise needs to know what AI exists in the estate, what each system is doing, who may use each one, what each one costs, and how all of this relates to compliance obligations. That became the focus of our next major release.
April – June 2026: Governance became an enterprise control problem
One quarter, seven big pieces: the AI Asset Registry with governance factsheets (your AI bill of materials), full-surface guardrails including streaming-output scanning; structure-aware Knowledge Base connectors for Slack, Jira, and Confluence.
Agentic governance with a sandboxed Skills runner and A2A delegation controls; enterprise identity (SAML, SCIM, DCR, 2FA) and Kubernetes-native deployment; multi-provider resilience with circuit breakers.
We also added a choice to tag data in Brutor for four major compliance frameworks – SOC 2, EU AI Act, HIPAA, and GDPR Article 30.
To be a true AI Control Plane, another idea became central to how we think about the product – “Govern what you route. See what you buy.”
For closed SaaS AI services that cannot be routed through the platform – such as Microsoft Copilot or ChatGPT Enterprise – we import usage and cost information, turning Brutor into a powerful AI FinOps Console for your business.
You can’t control what you can’t see – Shadow AI Discovery in Brutor discovers the AI in use across your organization (the tools, agents, and MCP servers) that nobody registered, so you can onboard it and govern with a couple of clicks.
July 2026: Agents changed the governance conversation once more
Summer 2026 was not a time for us to slow down – it turned out to be the exact opposite.
We started with Semantic Governance Policies – AI policies can now be written in plain language and they will be enforced in Brutor by an LLM judge (in a shadow mode first to prevent issues).
We also released the beta version of Brutor MCP Registry – a place to publish created and verified MCP servers together with a governance posture.
But the main focus was on agents still. We agreed with analysts such as Gartner that uniform governance across AI agents (either trusting them or not, basically) will lead to failure.
We introduced Agent Identity: in Brutor, every agent is a principal, issued by the organization’s identity provider and governed through per-action grants. The principle matters: govern actions, not simply access.
Brutor doesn’t just manage agents, it manages AI Systems in Production – dynamic compositions of models, tools, skills, agents or assistants working together to perform tasks, make decisions, and interact with data and enterprise capabilities. Mouthful, I know, but an important distinction for what was to come next.
A small sidestep before I do – using Claude to code our software (by now the eponymous Fable 5) meant that I could code new features for Brutor in days.
An example: because MCP is where Brutor AI started, we had followed its specifications closely and were able to add support for the new specifications – The MCP 2026-07-28 Specification – three days before the final specification was published.
August and September 2026: from governance to assurance
By late summer, it felt like everyone was releasing an AI gateway. AI gateways log AI requests, enforce guardrails, control traffic, and apply resource policies. Those capabilities matter.
But they leave the hardest question unanswered:
How do you know that an AI system continues to behave as designed?
An agent that asks an LLM what to do next will not behave the same way every time to get an answer, as models, data, prompts, tools, and skills can all change around the agent. And you know what it can lead to in real life – a runaway agent can burn through budgets in no time. It can produce an answer that sounds plausible but is complete nonsense; it can stop working without anybody noticing.
Brutor now offers an answer to this problem.
AI Systems Assurance
The idea is straightforward: instead of asking only what an AI system did, it learns how the system normally operates according to a defined contract, and detects the moment behavior starts to deviate – and lets you know right away.
This is a different problem from “traditional” AI governance.
- Governance makes sure that an AI system does what it is allowed to do.
- Observability tells you what a system did (or for public AI tools, also what your people did).
- Assurance tells you whether the system is still doing what you intended. This distinction now sits at the heart of where we were taking Brutor AI.
Tokenomics
August also brought a shared vocabulary for the economics of AI. The Linux Foundation launched the Tokenomics Foundation to define the economics and ROI of AI. Adding tokenomics was a natural extension of the AI cost analytics we already had, so we added them to the Brutor AI Mission Control dashboard so that organizations can see not only what their AI workloads cost today, but whether those workloads remain economically viable as they scale.
By this point, Brutor AI needed a new name once more (how long will this one last?…). We now call the product the Brutor AI Control Plane.
Autumn 2026: Visualize your AI systems
At the end of September, we added another important piece in sync with our user-friendly philosophy – The AI System Composition View in Mission Control draws the models, tools, skills, and agents that make up an AI system and how they connect, and lets you select any individual run and trace that run through the composition, step by step. Knowing that a system has drifted is useful. Knowing where the drift happened – even more so.
To make this tangible, we have released a demo of this functionality in the Brutor Demo System, an open-source loan pre-screening agent that runs against the free trial.
What Happens Next
This is our story so far – building Brutor AI into a system that can help customers keep up with the rapid adoption of AI and the complexities and challenges that come with it.
The first half of Brutor AI’s life was about controlling what AI may or may not do: one control plane for models, tools, skills, and agents, with the governance and audit trail around them. The second half has been about a different challenge: how to know that an AI system continues to do what you intended once the system is in production.
The next chapter will be shaped by the challenges our customers bring us. What are the biggest challenges you face as you scale AI across your organization – how can Brutor help?
