An AI governance strategy is a portfolio, not a purchase. No AI governance tool covers everything today, including this one. Governing models, developers, autonomous agents, and the tool-call protocol those agents use are different technical problems, with different buyers and different urgency — which means a real strategy runs two to three tools, not one. Here’s exactly which requirements AIControls addresses, and which ones need something else next to it.
Where AIControls fits
User & Developer Governance. Developers are already using Claude Code, Cursor, and similar tools, usually with no attribution and no policy. AIControls gives every LLM call a real identity via scoped personal access tokens — issued per org, team, and developer — with model access enforced by AD group, budgets enforced before overrun instead of reported after, and every call tied to a ticket.
Agent Runtime Governance. Once agents act autonomously — reading data, calling APIs, chaining actions — the question shifts from “who used this tool” to “what did this agent decide to do, and who’s accountable for it.” AIControls gives every agent a verifiable identity, evaluates its actions against policy before they execute, holds high-risk actions for human approval, and produces an audit trail built for compliance review, not just debugging.
MCP Governance. Model Context Protocol standardized how agents discover and call tools, which means that surface can now be governed as a protocol instead of custom integration code. AIControls sits in front of every MCP tool call — validating arguments, enforcing per-tool and per-datasource policy, filtering which tools an agent can even see — before the call reaches anything real. It’s specific enough, and different enough from general agent identity and permissions, to name on its own: MCP Governance.
Three requirements, one policy engine, one audit trail across all three — that’s the part of an AI governance strategy AIControls is built to own outright.
What it doesn’t do
Model Governance — whether a model is fair, explainable, and documented well enough to satisfy a regulator: bias testing, model cards, EU AI Act high-risk system documentation. Different discipline, different buyer, usually a Chief AI Officer or model risk team. AIControls doesn’t build this. If regulatory documentation for the models themselves is a live requirement, that’s a separate line item in the strategy, running alongside AIControls, not replaced by it.
What looks simple until it’s in production
Intercept the call, check a policy, log the decision — the shape of it is easy to sketch. A handful of the details underneath carry real engineering weight once agents are actually running against production systems.
Identity delegation. A request is rarely just “this agent.” It’s usually a human delegating to an agent, which may delegate part of a task to a second agent. The first hop — a service account acting on behalf of a user — is a token-exchange problem (RFC 8693) that’s solvable and well-specified. The second hop — tracing authority across agent-to-agent handoffs — is earlier-stage: Okta’s Cross App Access and the IETF draft underneath it, ID-JAG, are real progress, and MCP adopted it as a standardized authorization extension in late 2025. But the spec is still in draft, Standards Track status, not finalized. Building against it now means revisiting the integration as it moves, not a one-time build.
Fail-open or fail-closed. Something sitting in the execution path needs a documented answer for what happens when it, or a downstream policy check, is unreachable. Fail closed by default and one dependency outage takes every agent down with it. Fail open by default and the governance layer disappears exactly when something’s already gone wrong. The right default isn’t the same for every policy, and it has to be a decision, not an accident of how the code happened to handle an exception.
Approval durability. A human-in-the-loop hold has to survive more than the happy path — a process restart, or more than one replica running with an approval landing on the wrong one. An in-memory queue looks finished in a demo and silently drops every pending decision the first time something crashes mid-wait.
Cache locality. Intercepting or rewriting a model call in a way that looks harmless can quietly break prompt caching, usually the single largest lever on AI spend — we wrote about this trap specifically in Govern the Request, Not Just the Model.
Context compression. Long-running agent sessions don’t fit in a single context window, so something has to decide what gets summarized, pruned, or dropped before the next call. If that happens before your governance layer sees the request, you’re auditing and scanning a version of events that isn’t what actually happened — a policy violation buried in the part that got summarized away is never evaluated at all. Getting this right means the governance layer needs visibility into the session before compression, not just the trimmed context the model ends up receiving.
Context intelligence. Which ticket a session is actually working on, or that its behavior just changed shape, isn’t something a developer reliably declares — it has to be inferred from the tool calls and content happening in the session. Keyword matching produces false attribution that quietly corrupts every downstream report; doing it well is closer to a classification problem than a pattern-matching one, and it has to run fast enough not to add latency to every call.
Attribution. The easy version is “whoever holds the API key.” That breaks the first time a key is shared across a team, a CI pipeline calls on behalf of multiple humans, or a service account fans out to many callers — and once it breaks, every audit log entry looks identical, with no way to tell them apart after the fact. Attribution that survives an audit has to be built into the identity model from the start, not reconstructed by parsing logs afterward.
Policy flexibility. No policy author anticipates every legitimate request in advance. A ruleset that only knows allow or deny either blocks something real and pushes developers to route around it, or gets patched under pressure with a rule narrow enough to be a liability the next time something similar happens. The alternative is decision modes beyond binary — audit, warn, hold for approval — plus exceptions that are scoped and reviewable without a redeploy, so an unplanned case degrades gracefully instead of becoming an outage or a bypass.
Network egress. Agents don’t only touch what’s registered as an MCP tool or a governed LLM endpoint — they can make arbitrary outbound calls to anything reachable from the pod. Filtering that well means kernel-level visibility into what’s actually being called, not an allowlist bolted onto the application layer, plus real SSRF protection so an agent can’t be redirected into an internal metadata endpoint through a URL that looks like an ordinary API call. And there’s always a destination nobody wrote a policy for yet — the honest choices are block everything unclassified and break legitimate work, or route it to a judgment call that’s logged and reviewable instead of silently defaulting either way.
Local tool processes and multi-tenancy. The instinct for an unsupported tool server is “just spawn the subprocess.” That single decision creates five separate problems at once: credentials are shared across every caller since they’re set at process start, not per request; in-memory state from one tenant’s call can leak into the next; a slow call from one tenant blocks everyone else; an unpinned package fetched at startup is a live supply chain risk; and the child process inherits whatever privileges launched it.
Response scanning is a different problem than request scanning. A policy engine built on the request-evaluation pattern — the same shape as admission control — naturally checks what’s coming in. It has no native way to evaluate what the model actually said back. Catching a leak in the model’s output, not just the prompt, needs separate plumbing bolted on, not an extension of the same policy language.
None of these surface in a proof of concept. They surface in the first production incident, the first postmortem, or the first audit — a more expensive place to find them.
Questions that come up
Do I still need another tool? Likely, if model risk and regulatory documentation is a live requirement — most commonly for high-risk AI systems under the EU AI Act or similar frameworks. AIControls covers the layers next to that category, not that category itself.
How does this relate to the LLM gateway or router we already run? They’re not the same layer, and we’ve written about the distinction in detail — Govern the Request, Not Just the Model. Short version: routing decides which model answers a request. AIControls integrates with what’s already running — as an authorization hook in front of LiteLLM’s custom_auth, as an ext_authz provider in front of Agent Gateway or Envoy — and governs identity, tool calls, and audit on top of it.
Is this a compliance or GRC tool? No. It produces evidence a compliance program needs — audit trails, NIST AI RMF coverage mapping, exportable reports — but it isn’t the system of record for impact assessments, regulatory change tracking, or sign-off workflows. It’s the runtime layer that gives a GRC program something real to point to.
What does my team have to change? One Kubernetes label for MCP and agent governance, no code changes in the agent. A scoped personal access token, issued per org, team, and developer, for developer governance — no new login flow to adopt. Both deploy in under thirty minutes.
Is this recognized outside of what we say about it? Gartner published its first Magic Quadrant for AI Governance Platforms in June 2026 — the first formal line drawn around this category. We’re early-stage and don’t expect placement in year one of a new category; what the report does confirm is that runtime enforcement, not dashboards or inventory, is where governance platforms separate from monitoring tools. That’s the layer we built first.
Building the rest of the strategy
If you’re assembling an AI governance program rather than buying a single tool, the honest map looks like this: AIControls for developer access and cost, agent runtime enforcement, and MCP tool governance. A model risk or GRC platform for regulatory documentation and impact assessments, if that’s a live requirement. Two vendors, one coherent strategy, no gap and no overlap — which is a more useful starting point than a single platform pitch that quietly doesn’t cover a third of what you actually need.
More on how we think about the category: Understanding AI Governance: A Market Map and The Gate That’s Missing from Every AI Governance Stack.
