Most teams shopping for AI agent governance in 2026 end up buying a dashboard, and then find out six months later that their actual problem was an agent holding a database credential with no spending cap on it.
AI agent governance platforms decide what your autonomous agents are allowed to do and how much they can spend doing it. The category splits into five layers, and no single product covers all five well. The five that matter in 2026 are Bifrost, Microsoft Agent 365, Zenity, Arthur AI, and Credo AI.
I have ranked them by the thing most lists skip: how much each one can actually stop, in real time, before a bad action lands. Not how good the report looks afterwards.
What AI agent governance actually means
Let's start from first principles, because "governance" is a word that has been stretched until it means almost nothing.
Traditional software governance assumes a human is somewhere in the loop. A person logs in, a person clicks the button, and the audit log records which person did it. Permissions attach to that person.
An AI agent breaks that assumption in a very specific way. The agent holds the credential, decides on its own which tool to call, and calls it a few hundred times while you are asleep. There is no click to attribute.
So governing an agent means controlling five separate things, and they really are separate:
- Identity. Which agent is this, who owns it, and what is it allowed to be?
- Authorization. Which models, tools, data and systems can it reach?
- Spend. How many dollars and how many tokens can it consume before it gets cut off?
- Behavior. Was the input a prompt injection, was the output leaking a card number, was the answer just confidently wrong?
- Evidence. Can you reconstruct, six weeks later, exactly what it did and why?
Miss any one of those and you don't have governance, you have a partial view with a nice chart on top of it.
Gartner polled more than 3,400 organizations investing in agentic AI and predicted that over 40% of agentic AI projects will be canceled by the end of 2027, naming escalating costs and inadequate risk controls as two of the three reasons. Notice that both of those are governance failures and not model failures. The model was fine. Nobody had put a limit on it.
And the readiness gap is not subtle. In a Deloitte survey of 3,235 IT and business leaders across 24 countries, only 21% said their organization has a mature governance model in place for agentic AI. So four out of five teams are running agents on trust.
The five control points, walked through one incident
This is the part I wish the other lists on this topic did, so let me do it here.
Take one concrete setup. A customer support agent running on Claude Sonnet, wired to two MCP servers: one for Linear so it can file tickets, and one Postgres connection so it can look up an order. A support engineer built it in an afternoon. It works fine.
Now walk through what goes wrong, as four separate events.
Event one. The Postgres MCP server got registered with a connection string that has write access, because that was the string already sitting in the engineer's .env file. Nobody noticed, because the agent never tried to write anything.
Event two. A customer pastes a support message that contains an instruction addressed to the agent, telling it to look up recent orders for a different email address. This is item one on the OWASP Top 10 for Agentic Applications, published in December 2025, and this is the boring, non-exotic version of it.
Event three. The agent complies, and because it is trying to be helpful, it iterates. It runs the same lookup pattern 4,000 times over a two-hour window, each call carrying a large system prompt plus the full retrieved context.
Event four. Somebody finds out the next morning, from a bill.
So which layer catches which event?
An identity layer catches event one, and only event one. If the agent has an identity with declared scopes, then a read-only agent holding a write-capable credential is a visible contradiction, and you can alert on it. But identity has nothing at all to say about a malicious support message.
A behavior layer, meaning guardrails, catches event two. A prompt injection classifier sitting in front of the model can flag that instruction and refuse the turn. But guardrails run per call, and they are stateless. Four thousand individually-innocent calls are four thousand clean passes.
An evidence layer, meaning tracing and observability, sees all four events, perfectly, in full detail, after they have already happened. That is not a criticism of it, that is the definition of the layer. I wrote a whole post on what you should capture on every agent call and I still think tracing is the first thing you should turn on. It is just not a control.
The only layer that can stop event three while it is happening is the layer that every single call physically passes through, counting tokens as they go, with the authority to return a 402 on call number 900.
That layer is the gateway. Which is exactly why it is number one on this list.
Now, the five AI agent governance platforms
That is the map. Five control points, and one hard rule underneath all of it: a tool can only enforce what it sits in front of.
So here are the five, ordered by how much of the request path each one owns, with what it actually does and where it runs out of road.
1. Bifrost, governance on the request path
Bifrost is Maxim AI's open-source AI gateway, written in Go, and it is at number one here because it is the only entry on this list that sits inside the call. Every model request and every MCP tool call passes through it, which makes it the only one that can refuse.
The governance model is a three-tier hierarchy: customer, then team, then virtual key. A virtual key is the thing your application actually authenticates with, and it is the primary governance entity. One looks roughly like this:
{
"id": "vk-001",
"name": "support-agent-prod",
"value": "sk-bf-*",
"is_active": true,
"provider_configs": [
{
"provider": "anthropic",
"weight": 0.5,
"allowed_models": ["claude-sonnet-4-5"],
"key_ids": ["anthropic-primary"]
}
],
"team_id": "team-support-001",
"expires_at": "2026-12-01T00:00:00Z"
}
Read that config out loud as a sentence and you get the whole point of the layer! This agent may talk to Anthropic, may use exactly one model, may use exactly one of your provider API keys, belongs to the support team, and stops working in December whether anyone remembers it or not.
Three parts of this are worth pulling out properly.
Budgets that cascade
Budgets attach independently at each of the three tiers, and they get checked cumulatively. The virtual key's budget is checked, then the team's, then the customer's, and the request only proceeds if all of them still have room.
{
"id": "budget-support-vk",
"virtual_key_id": "vk-001",
"max_limit": 100.00,
"reset_duration": "1M",
"current_usage": 0.0
}
Reset durations run from one minute up to one year (1m, 1h, 1d, 1w, 1M, 1Q, 1Y), and there is a calendar-aligned mode that resets on real UTC month and quarter boundaries instead of a rolling window. That sounds like a tiny detail until you try to reconcile a rolling 30-day agent spend against a finance team's calendar month.
There is also a budget override, with an effective limit that equals the base budget plus the override amount, granted either for a fixed number of cycles or forever. That primitive exists because the alternative, in every organization I have ever seen, is somebody quietly raising the real limit at 2am and never lowering it back.
Rate limits that count tokens, and not just requests
Rate limits live only at the virtual key tier, and they are two fully independent counters:
{
"token_max_limit": 10000,
"token_reset_duration": "1h",
"request_max_limit": 100,
"request_reset_duration": "1m"
}
That separation is the thing that would have caught event three in the walkthrough. A requests-per-minute cap does nothing against an agent making a modest number of enormous calls. A token cap with its own independent reset window is the control that actually maps to how agents burn money.
And the failures come back as honest HTTP semantics, which matters more than it sounds: 402 for a budget exhausted, 429 for a rate limit hit, 403 for an inactive key, an expired key, or a blocked model. Your client code already knows how to handle those. You are not parsing an error string to find out what happened.
MCP tools as a governed surface
This is the part that almost nothing else in the category does yet.
Bifrost's MCP gateway treats tools the way it treats models, so tool filtering is deny-by-default at three levels. The client config sets which tools exist at all, per-request headers (x-bf-mcp-include-clients, x-bf-mcp-include-tools) narrow that set for a single call, and virtual key filtering overrides both. A key with no MCP configuration gets no MCP tools at all, period! You can also bundle a curated set of tools from several different servers into one MCP Tool Group and attach that group to a key.
Now go back to event one in the walkthrough. A write-capable Postgres tool that the support agent's key was never granted is a tool the agent cannot even see, regardless of what is sitting in anybody's .env file.
For the behavior layer, Bifrost does not try to build its own classifiers. It plugs into AWS Bedrock Guardrails, Azure AI Content Safety, Google Model Armor and Patronus AI, and it emits OpenTelemetry out of the box. It also does adaptive load balancing with provider failover, semantic caching, and multi-node clustering, which is the reliability half of the same control plane.
The numbers. Maxim's own benchmark puts the added latency in the tens of microseconds (the repository claims under 15 microseconds per request at 5,000 requests per second, the product page says 20), with 3.3 GB peak memory, and against LiteLLM it claims 9.5 times the throughput and 54 times faster latency at the 99th percentile, meaning the slowest one request in a hundred. Treat vendor benchmarks as vendor benchmarks, but the architectural reason behind them is real: this is a Go binary in your request path, and not a Python process. The core is Apache 2.0 on GitHub at around 7.4k stars, and you can have it running with one command:
npx -y @maximhq/bifrost
Where it runs out of road. Bifrost governs the call, and it does not discover agents. If a team stands up an agent that talks to OpenAI directly and skips the gateway, Bifrost will never know that agent exists. So it is simultaneously the strongest enforcement point available and the easiest one to route around, which means it only works if you make it the only path out. Also, enterprise RBAC, SSO and audit logs sit in the commercial tier and not in the open-source core.
Pick it if you want a control that can actually say no, and you are willing to make gateway egress mandatory.
2. Microsoft Agent 365 with Entra Agent ID
Microsoft Agent 365 is the most serious attempt yet at solving layer one properly.
The idea underneath it is Entra Agent ID, and it is a genuinely good idea: every agent gets a first-class identity in the directory, the same way every employee has one. Once an agent is a directory object, everything Microsoft already built for humans starts applying to it. Conditional Access policies. Least-privilege scoping. Purview for data classification, Defender for threat detection, Intune for endpoint controls. Agent 365 then adds the registry and the admin hub on top, so you get a real inventory of the agent fleet, including the agents somebody spun up in Copilot Studio and never told you about.
That registry is the answer to the exact problem a gateway cannot solve. Agent sprawl is a discovery problem before it is an enforcement problem, and you cannot govern an agent you have not found yet.
Where it runs out of road. The gravity is real. Coverage is deepest for Copilot Studio and Azure AI Foundry agents and for agents on managed endpoints, and it thins out fast for a Python agent your ML team runs in a container on another cloud. It also does not do token budgets in any meaningful sense. It will tell you an agent exists and what it may touch, and it will not stop that agent at dollar 4,000.
Pick it if you are already an Entra shop, which honestly means pick it anyway, because identity is the one layer you cannot fake.
3. Zenity, posture and runtime action validation
Zenity comes at this from the security side rather than the platform side, and its strength is the part of your estate that nobody has an inventory of.
It discovers agents living inside Copilot Studio, Power Platform, AWS Bedrock and Google Vertex AI, then keeps watching what those agents touch and share. The framing is AI Security Posture Management, and the genuinely useful mechanic is buildtime policy: it flags an over-permissioned connector before the agent ships, which is the cheapest possible moment to catch event one from the walkthrough. Gartner named Zenity a 2025 Cool Vendor in Agentic AI TRiSM (their acronym for trust, risk and security management), and that low-code coverage is why.
So why does the low-code angle matter this much? Well, because that is where the agents you don't know about actually live. An engineer's Python agent is at least in a repository somewhere. A business analyst's Copilot Studio agent with access to a SharePoint site full of contracts is nowhere you are currently looking.
Where it runs out of road. It is a security product, so it governs risk and not cost. There is no budget primitive here and no token accounting at all. And its discovery is strongest in exactly the places Microsoft's is strongest, so if you already have Agent 365, the overlap deserves a hard look before you pay for both.
Pick it if a lot of your agents are being built by people who are not engineers.
4. Arthur AI, guardrails and evaluations without a framework tax
Arthur AI launched its Agent Discovery and Governance platform in December 2025, and the thing I find genuinely interesting about it is that it is framework-neutral in a category that mostly is not.
Discovery works across four vectors: OpenTelemetry streams, MCP server monitoring, network-layer analysis, and the platform APIs of Vertex AI, Bedrock and Azure AI Foundry. And because the tracing is built on OpenTelemetry and OpenInference rather than a proprietary SDK, it works with LangChain, LlamaIndex, raw OpenAI and Anthropic calls, and whatever your team decides to pick next quarter.
On top of that it runs two things that are worth keeping separate in your head. Runtime guardrails, which intercept before and after the model call for PII, prompt injection and toxicity. And continuous evaluations against live production traffic, which is the part that catches hallucination and quality drift, the failures that never throw an error and never show up in a latency graph.
That second distinction is the one I care most about, and it comes from doing the work by hand and getting it half right. On a contract with a startup building an AI co-worker that lives in Slack (keeping it a bit vague, can't reveal much more than this lol), I was the first layer of internal testing, and I built an internal tool that captured the product's data logs and generated reports on latency and probable slowdowns. It was useful, and the core users got a better product out of it. But it told me when the thing was slow, and it never once told me when the thing was confidently wrong. Those are two different systems, and I had only built one of them.
Where it runs out of road. Same ceiling as any observability-first product: it sees everything and blocks a narrow slice of it. The guardrails are per-call, so the accumulation problem from event three stays unsolved, and there is no spend primitive here either.
Pick it if your stack is heterogeneous and output quality is your real risk, rather than permissions.
5. Credo AI, the compliance program of record
Credo AI is on this list for a reason that has nothing to do with runtime, and I would rather be blunt about that than pretend it belongs in the same bucket as the other four.
Its Policy Packs translate regulation into something an engineering team can actually act on, mapping the EU AI Act, ISO 42001 and the NIST AI Risk Management Framework down into concrete requirements. It keeps an AI Agent Registry of what is in production, plus GAIA, an assistant for the governance workflow itself. When a regulator or an enterprise customer's security review asks what your agents do and which controls apply to them, this is the layer that produces the answer.
And the timing here is worth getting right, because a lot of content on this topic is now stale. The Digital Omnibus on AI entered into force on 27 July 2026, and it deferred the high-risk obligations for standalone Annex III systems all the way out to 2 December 2027, and to 2 August 2028 for AI embedded in regulated products. So the deadline a lot of teams panic-bought a platform for has moved.
What did not move is Article 50. The transparency duties landed on 2 August 2026, and those catch every chatbot and every piece of synthetic content, which in practice means they catch most agent deployments regardless of risk tier. The high-risk regime got 16 more months. The disclosure regime is live right now.
Where it runs out of road. Credo AI cannot block a request. It produces policy and evidence, and if you buy it expecting enforcement, you have made the exact purchasing mistake this whole post is about.
Pick it if you sell into regulated industries, or your legal team has started asking questions in writing.
What none of these five actually do
Time for the honest part, because a list that ends on five recommendations and no caveats is just an ad.
Agent-to-agent calls are mostly ungoverned. When agent A hands a task off to agent B, whose budget does it hit, whose identity does it carry, and does B's guardrail see the original user's prompt or A's rewritten version of it? Inter-agent communication is item seven on the OWASP agentic list, and I have not seen anybody solve it convincingly yet. Gateways get closest, because that hop is still an HTTP call, and "closest" is doing a lot of work in that sentence.
Memory is a governance hole. An agent that writes a poisoned fact into its long-term store carries that fact past every per-call guardrail forever, because on every future call it is not an injection anymore, it is just context. Nothing on this list governs writes to agent memory the way it governs writes to a database.
Agent identity is not portable. Entra Agent ID is real and it is good, and it is also Microsoft's. There is no cross-vendor standard yet, so an agent's identity in your directory means nothing to a partner's system. We are roughly where federated human identity was before SAML showed up.
And the buying mistake, which is the whole reason I ordered this list the way I did. A team worried about a runaway bill buys a compliance platform, and a team worried about a regulator buys a tracing tool. Both walk away with a real product doing a real job, and neither one has touched the thing that wakes them up at 3am.
Frequently asked questions
Is an AI gateway enough on its own for agent governance? For spend, authorization and tool access, yes, and it is the strongest control you can get for those three. For discovery and identity, no. A gateway cannot see an agent that does not route through it, so pair it with an identity or discovery layer, and make gateway egress mandatory at the network level rather than by policy document.
Do I need an AI agent governance platform for a small team? You need two of the five control points from day one, and neither of them is a purchase. Put every model call behind one gateway with a per-key spending cap, and turn tracing on. My own side project Scholarian has fetched and ranked over 10,000 papers across 250-plus search sessions, and the reason I care about per-key caps is not enterprise policy, it is that a retry loop in a research pipeline is perfectly capable of spending real money overnight.
What is the difference between AI agent governance and AI observability? Observability tells you what happened, governance decides what is allowed to happen in the first place. They get sold together because tracing is how you prove a policy was enforced, but a trace has no authority. If your platform can produce a beautiful timeline of an incident and could not have prevented that incident, you bought observability.
Where do guardrails fit into all this? Guardrails are the behavior layer, and they run per call, screening inputs for injection and outputs for leakage or toxicity. They are necessary, and they are stateless, which is why they miss failures made out of many individually-fine calls. Run them at the gateway rather than inside each application, so that one policy update covers every agent instead of six repositories.
Does the EU AI Act require an agent governance platform? No regulation names a product. But the Article 50 transparency duties are in force as of 2 August 2026, and the deferred high-risk regime still expects risk management, logging and human oversight when it lands in December 2027. Those obligations are much cheaper to meet if the logging was there from the start.
What would I actually pick?
If I could only run one thing, it is the gateway, and that is Bifrost. Put every model call and every MCP tool call behind it, then set a token budget with its own reset window on every virtual key and deny tools by default. It is the only layer on this list that can turn a policy into a refusal, it is Apache 2.0 so the argument costs you nothing but an afternoon, and at microsecond-scale overhead you are not trading latency for control.
Then add identity second, and not fifth. Agent 365 if you are on Entra, which most enterprises already are. Discovery is the one problem a gateway genuinely cannot solve for you, and most of the rest of this list is a refinement of a control you would already have.
And here's my bet for the next 18 months: this category does not stay five layers wide. Identity and posture will collapse into whoever already owns your directory, evaluations will fold into observability, and the thing that survives as a separate purchase is the request path, because that is the only place enforcement is physically possible. If I turn out to be wrong about that, I'll happily write the follow-up.
That's all from my side, folks. If you are running agents in production and you have found a control that actually stopped something, I want to hear about it, so drop it in the comments. And if you want more of this, I write about AI infrastructure regularly on X and on my site.
Top comments (0)