If your AI agent governance solution depends on the agent choosing to comply, is it governance?
I keep looking at the “governance” products launching in this space and seeing the same architectural mistake: they tell agents what they should do, then hope for the best.
Take TrustControls.ai (by Vanta) as a concrete example. They published 61 controls for agentic AI systems. The controls themselves are reasonable — things like “validate tool inputs,” “enforce least privilege,” “log all actions.” Hard to argue with any of it.
But look at the delivery mechanism: an MCP server that agents can query to learn what controls apply to them.
Agents can query it. They are under no obligation to do so.
This is the digital equivalent of posting the employee handbook on the intranet and calling it access control. The handbook might be excellent. The policies might be world-class. But if compliance is voluntary, you don’t have governance. You have aspirations.
There are three failure modes, and any one of them is fatal on its own:
The agent never asks. A jailbroken agent, a poorly prompted agent, or an agent built by someone who never integrated your MCP server — none of them will query your control definitions. Your governance doesn’t exist for them.
The agent asks but interprets probabilistically. Even a well-intentioned agent that queries your controls is still an LLM. It reads natural language policy and makes a probabilistic decision about what to do. This is not a boolean gate. “Validate inputs before passing to tools” can mean different things depending on the model, the prompt, and the phase of the moon.
Adversarial inputs bypass everything. Prompt injection, context manipulation, tool-use exploits — none of these care about your control framework. An agent under adversarial influence won’t politely check whether it’s allowed to exfiltrate data first.
To be fair, advisory governance is great for audits. It documents what should happen. Auditors love it. Compliance teams can check boxes. But it has roughly the security properties of a “please don’t steal” sign.
Real governance means the agent physically cannot take an action that policy disallows. Not “shouldn’t.” Cannot.
Your process doesn’t get to decide whether it has permission to read a file. The kernel checks, and if the answer is no, the syscall fails. The process’s opinion about file permissions is irrelevant. Same principle applies here.
Governance enforcement must be:
Concrete examples: runtime hooks that intercept tool calls before execution (preToolUse/postToolUse patterns). OS-level enforcement like WDAC or AMSI. Proxy layers that sit on the only network path between agent and API.
The agent doesn’t get a vote. That’s the point.
I should acknowledge there’s a spectrum here. Proxy-based approaches (like Ultra Security’s sidecar model) sit between advisory and enforcement. They intercept traffic and apply policy — which is real enforcement, as long as the agent routes through them.
The catch: if the agent can reach the tool directly, bypassing the proxy, you’re back to voluntary compliance. Architecture matters. A proxy is only as good as the network topology that forces traffic through it.
This is solvable (restrict egress, lock down tool endpoints), but it’s a deployment constraint that advisory frameworks don’t even acknowledge.
The industry is conflating two different things: governance UX and governance enforcement.
Defining controls is governance UX. It answers “what should we govern?” — and that’s valuable work. You can’t enforce policies you haven’t defined. TrustControls.ai and similar frameworks do this part well.
But defining controls is not enforcing them. A firewall rule and a Post-it note that says “don’t access that server” describe the same policy. They are not the same thing.
Until your governance solution can answer “what happens if the agent ignores this?” with something other than “nothing,” you have theater. Well-documented, audit-friendly, MCP-queryable theater. But theater.
Build the enforcement. Then dress it up with compliance frameworks. Not the other way around.
I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.