By Sagar Batchu, Co-founder & CEOAI governance platform
The software an enterprise uses to control what its AI is allowed to do. It connects agents to the systems they need, enforces policy on every prompt and tool call, and produces the audit record that proves it. The platforms that work combine AI enablement and AI security on one path; the ones that only document governance from the sidelines do not.
AI governance is the set of decisions an organization makes about what its AI is allowed to see, do, and decide on its behalf, and who is accountable when something goes wrong. Done well, it means you can understand what your AI is doing, control what it is allowed to act on, and track every action back to a policy and an identity.
But because AI governance is still a new field, that definition has not been adopted uniformly across the industry. Many products sold under the name do not enforce anything at runtime. They document what an organization’s AI is supposed to do without ever touching what it actually does.
A steady run of public AI incidents has made closing that gap an urgent priority. 2026 is the year enterprise AI governance became infrastructure. Gartner expects spending on AI governance platforms to pass $1 billion by 2030, and reports that organizations running one are 3.4 times more likely to rate their governance program effective.
This article explains what a real AI governance platform does, how to tell the difference between a platform that enforces and one that only documents, and what to look for when evaluating the category.
AI governance vs AI security
AI governance and AI security are sometimes conflated, but they differ in what they ask, who owns them, and what they protect against.
AI governance
AI governance is about accountability and control from the inside. The question it answers is what your AI is allowed to do, and whether you can prove it stayed within those bounds.
Its owners are the board, the Chief AI Officer, and risk and compliance functions. The threat it addresses is a trusted agent doing something authorized but wrong, acting on data it should not have reached or making a decision no one sanctioned.
AI security
AI security is about defense from the outside. The question it answers is how to stop AI systems from being attacked or abused.
Its owners are the CISO and security engineering. The threat it addresses is an attacker hijacking an agent through prompt injection, credential theft, or supply chain compromise.
Each can only be answered by something sitting on the path between an agent and the systems it touches. We map the security half in what is AI security. The rest of this piece is about the governance half, and why the two have to live in one place.
What is AI governance?
AI governance is the set of decisions an organization makes about what its AI is allowed to see, do, and decide on its behalf, and who is accountable when something goes wrong.
Several recognized AI governance frameworks define the discipline:
- NIST AI Risk Management Framework. Built on four functions (GOVERN, MAP, MEASURE, and MANAGE), its GOVERN function spans the whole organization, establishing the accountability, roles, and policy that govern how AI is built and used.
- ISO 42001 (ISO/IEC 42001). Defines a management system for AI, covering the formal policies, oversight responsibilities, and review processes an organization should put in place.
- OECD AI Principles. Updated in 2024 and endorsed across 47 jurisdictions, these set the human-centered values AI systems should respect.
We cover the discipline in depth in what is AI governance.
These frameworks define what to govern, but they stop short of enforcing it. An AI governance platform takes the decisions a governance program has made, applies them to live AI activity, and produces the record that proves they held.
Why do enterprises need an AI governance platform?
AI governance was a theoretical concern for enterprises until recently. Three things changed that.
Agent sprawl
Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from under 5% in 2025. Every one of those agentic AI deployments can read data, call tools, and act on production systems, and the number of things to govern has outrun any manual process to govern them.
The cost of incidents
IBM’s 2025 Cost of a Data Breach report found that 13% of organizations had already had a confirmed breach of an AI model or application, and 97% of those lacked proper AI access controls at the time. Governance stopped being a hypothetical risk and became a line item with a price.
Regulatory pressure
The EU AI Act attaches obligations (risk management, data governance, logging, and human oversight) to high-risk AI systems, with penalties reaching €15 million or 3% of global turnover.
The high-risk deadline originally fell on August 2, 2026, but the EU’s Digital Omnibus, provisionally agreed in May 2026, deferred it to December 2, 2027 for standalone systems and August 2028 for high-risk AI embedded in products.
The NSA’s MCP security guidance signals that federal requirements are coming.
Build versus buy
The organizations that solved this first built their own. Uber built three governance layers (an LLM gateway, an MCP gateway and registry, and an agent identity system) before scaling AI across its engineering organization, and it took a dedicated platform engineering team years on top of a decade of existing infrastructure.
JPMorgan built governance-first into its AI program. Both proved the architecture works, but the path they took is closed to almost everyone else.
It requires a standing platform-engineering team, years of build time, and a foundation of identity and service infrastructure that takes years to establish. An enterprise that needs governance this quarter cannot hire, build, and integrate its way there. That gap, between building it like Uber and buying nothing, is exactly the gap the AI governance platform category exists to fill.
What does an AI governance platform do?
An AI governance platform has to deliver four capabilities, mapping onto the GOVERN-function obligations the recognized frameworks describe and onto Gartner’s AI TRiSM (Trust, Risk and Security Management) model, which is the operational layer for AI risk management that the standards describe but do not implement.
Discovery and inventory
A continuous, accurate record of every AI tool, agent, model, and connection in use, including the ones nobody approved. Gartner’s guidance on managing agent sprawl identifies a centralized agent inventory as a core early step, because a platform cannot govern what it cannot see. The unsanctioned tools and models that accumulate outside IT’s view are the problem known as shadow AI.
Identity and access
Real, scoped identity attached to every agent, so an action ties back to a specific user through SSO when a human is in the loop, or to a scoped service identity when the agent runs autonomously. Without this, agents inherit whatever access they can discover, and no tool call can be attributed to anyone.
Policy enforcement
The rules that decide what an agent may reach and what may flow through each call, applied to live activity. This is the capability the GRC tools cannot reach.
Observability and audit
A complete, structured record of every AI interaction, exportable into the SIEM and warehouse the security and compliance teams already use. AI observability at this level is what satisfies the auditor and what tells the board whether the AI investment is working.
What to look for in an AI governance platform
If the platform is meant to govern AI that already touches production systems, the evaluation reduces to a few structural questions:
- Is it on the request path? Can it sit between agents and the systems they reach, or does it observe from the side? Only an on-path platform can enforce.
- Can it block in real time? When a tool call violates policy, does the platform stop it before it executes, or does it record it after? Active blocking is the bar.
- Does it cover tool calls, not just model calls? Most of the risk lives in what an agent does after the model responds, at the tool call. A platform that only inspects prompts and completions misses the layer where data leaves and actions land.
- Does identity flow end to end? Is every action attributable to a specific user or scoped agent identity, inherited from SSO, rather than to an anonymous process?
- Does it discover shadow AI? Does it find the unsanctioned tools and agents, or only govern the ones already on a list?
- Does the audit trail leave the platform? Can every interaction be exported into the SIEM and warehouse the security and compliance teams already run on?
A platform that answers these is a single layer that connects, authenticates, enforces, and observes on one path.
Why governance has to live on the request path
Many platforms sold under the AI governance label are GRC tools: a place to register models, run risk assessments, attest to policies, and generate audit reports. ServiceNow, OneTrust, IBM watsonx.governance, and Collibra all sell a version of this, alongside dedicated tools like Credo AI and Holistic AI.
It is real work, and regulated enterprises need it. But it describes governance without performing it.
AI governance platform
of them can stop a violating call.
A model registry sits beside your production database, not between it and the agents that act on it. A risk assessment cannot inspect the tool call that exfiltrates customer records. These platforms run alongside your AI rather than on the path it takes, so the most they can do when an agent does something it should not is record that it happened after the fact.
The only place to enforce is the request path
What an agent reads, calls, and decides happens on the request path, in real time. The only way to control it is to be on that path.
Governance has to be a property of the enablement layer
The layer already on that path is the enablement layer that connects AI to your systems in the first place. Governance has to be a property of that layer, which is why governance and enablement cannot be separate initiatives.
Security and enablement can come hand in hand
Locking everything down kills the adoption the board is asking for, and leaving it open invites the incidents. They look like opposing goals only when different tools own them. On the same layer the conflict dissolves. The gateway that lets an agent reach a database is the same gateway that decides which agents may reach it, redacts what comes back, and logs the call.
Why GRC suites cannot make the move
A GRC suite can ship an AI governance tile, but it cannot move itself onto the request path, because it was built to document rather than to enforce.
The AI governance platform landscape
Two questions sort the market. How much does a tool enable AI, by connecting and powering agents? And how much does it govern AI, by securing, controlling, and auditing it? Plot vendors on those two axes, and color them by origin (AI-native or legacy infrastructure), and the field separates cleanly.
The bottom right is the enablement camp: AI-native LLM gateways like LiteLLM, Portkey, and TrueFoundry, alongside API-management incumbents like Kong and MuleSoft adding AI gateways. They connect and route agents well but do little to control them. The top left is the control camp: AI security tools like Lakera and Prompt Security, MCP-security gateways like Runlayer, dedicated governance platforms like Credo AI, and legacy security and GRC suites like ServiceNow, OneTrust, CrowdStrike, and Palo Alto extending into AI. They were built to govern, not to enable.
The two camps barely overlap. The enablement tools were never built to control AI, and the security and governance tools were never built to enable it. Even Palo Alto, a legacy security leader, is reaching across the gap by folding the Portkey gateway into its Prisma AIRS platform, because control without enablement is only half a control plane.
Speakeasy and the AI control plane
The top-right corner, high on both enablement and governance, is nearly empty. That is where an AI control plane has to sit, and it is where Speakeasy sits: an AI-native platform built to connect AI to systems that also secures and governs every call. It leans to the enablement side, because that is the only side from which real governance can be built.
The AI control plane is the solution to AI governance
When the four capabilities (discovery, identity, enforcement, and observability) are assembled onto a single path that every prompt, response, and tool call flows through, the result is an AI control plane.
Why separate tools cannot cover it
Each individual tool sees only part of the interaction. An LLM gateway sees prompts but not the downstream tool call. An identity provider sees the user but not whether an agent or a human is acting. A GRC platform sees the policy but not the live call that breaks it. The control plane is what you get when these layers are designed to see each other.
What a control plane does
An AI control plane sits on the request path and delivers all four governance capabilities in one place:
- An MCP gateway that connects agents to tools and enforces policy at the tool-call boundary
- Agent hooks that inspect every prompt and tool call inside the agent itself
- Identity and access that extends enterprise SSO to every agent action
- Audit logging that turns AI activity into compliance evidence
Why it has to be built from the enablement side
The layer that connects AI to your systems is already on the request path. A control plane built on top of that layer governs by default, because every agent action flows through it. A governance module bolted onto a system of record cannot reach the path, so it can only observe.
Speakeasy is building the AI control plane
Speakeasy is building that layer. It is the infrastructure Uber and JPMorgan built internally, available without the dedicated platform team and the multi-year build. Speakeasy started with managing MCP access, because connecting AI to data is where the sharpest governance failures happen, and has been extending across the four capabilities since.
If closing the gap between the policy an organization has written and the policy that actually holds at runtime is the problem you are facing, we’d be glad to talk.