The governance gap.

Two numbers from a Forrester survey of 500 enterprises deploying AI agents tell the entire story of where the market is right now: 71% lack a formal governance framework for autonomous agents, and 64% of those same organizations plan to increase agent autonomy within twelve months.¹ Read those two numbers next to each other and the implication is hard to miss. Most enterprises are not just deploying agents without governance. They're planning to give those ungoverned agents more authority over the next year.

This is happening for a reason that's easy to be sympathetic to. Agent governance is a moving target. The EU AI Act becomes fully enforceable in August 2026, with penalties up to EUR 35 million for high-risk system non-compliance.¹ ISO/IEC 42001 is the new management-system standard, but it's broad. NIST AI RMF is American, voluntary, and doesn't have the operational specificity teams need on a Tuesday afternoon. Internal audit isn't sure what to ask for. Procurement is signing vendor contracts without anyone reading the model-output indemnification clauses. The CISO knows something is off but the AI strategy didn't come through her org.

Meanwhile the engineering team has shipped three agents into production this quarter and is being asked to ship six more.

What "agent governance" actually means

Traditional AI governance asked questions like: was the model trained on permissioned data, can we explain its predictions, does it produce biased outputs. Those questions are still relevant but they're not sufficient. Agents act. They write to systems, send messages, move money, change records, and chain calls together in ways their designers didn't always anticipate. Governance for an agent is the set of controls that answer four operational questions:

1. What is this agent authorized to do? The action surface area, written down, with an explicit list of what's in and out of scope.
2. What must it never do? The hard guardrails. Not just policy in a doc, but enforced at runtime.
3. How are its decisions logged? The audit trail. Every input, every tool call, every output, with a time stamp and a session ID.
4. Who is accountable when it goes wrong? Not "the AI made a mistake." A specific human, with a specific role, who has the authority to pull the agent offline.

If you can't answer those four questions for an agent that's running in production, you don't have a governance framework. You have an exposure.

The four traps

1. Treating governance as a launch-stage activity

The most common pattern we see: an enterprise stands up a cross-functional council to "define AI governance," produces a sixty-slide document, blesses one or two flagship deployments, and then everyone goes back to their day jobs. Six months later there are seventeen agents in production. None of them went through the council. The team that built them didn't know about the framework, or knew about it and didn't have time to apply it, or couldn't tell which of the policies in the document actually applied to their use case.

Governance is not a launch artifact. It's an operational practice. The teams that get this right run governance reviews on a cadence that matches the deployment cadence, not the planning cadence. If you ship an agent every two weeks, you review every two weeks.

2. Confusing governance with security

Security teams have agent-relevant skills, but agent governance is bigger than the AppSec checklist. A SOC 2 audit is not an agent governance review. A pen test on the underlying API is not an agent governance review. The questions that govern agent behavior, what it's allowed to do, when it should escalate, what data flows through it, how it learns from feedback, are mostly not security questions. They're business-process questions answered by the people who own the workflow the agent is automating.

A good governance framework explicitly assigns these questions to the workflow owner, not the security team. The security team owns the controls that enforce the answers. That distinction matters because it tells the workflow owner they can't outsource governance, and it tells the security team they don't have to invent business policy.

3. Governing the model, not the action

Most early enterprise AI policies were written for the era of pre-trained models being used for analysis and content generation. They focused on training data, hallucination rates, output bias. Those concerns are still relevant. But agents do something models alone don't do: they take actions in the world. The governance frame has to shift from "is the model's output acceptable" to "is the agent's action acceptable, given the state of the world it acted on, the authority it had, and the human who can review the trail."

The simplest test: if you removed the language model from your agent and left only the action layer, would your governance framework still describe what the agent is allowed to do? If yes, you're governing the action. If no, you're governing the model.

4. Vendor-defined autonomy

Platform vendors define their own boundaries. Salesforce Agentforce has a permission model. Microsoft Copilot has a permission model. ServiceNow AI has one too. Each is internally coherent, none of them speak to each other, and none of them map cleanly onto your enterprise's existing role-based access control. If you let each platform define what its agent is allowed to do inside its own walls, you've effectively delegated your authorization model to your vendors. You can reverse this, but only by writing the cross-platform authority model yourself.

The choice of foundation model vendor and the choice of agent framework are not independent decisions. If agents run on a vendor's proprietary orchestration layer, lock-in compounds at every layer of the stack.

That's a structural argument for keeping your authorization model and your audit trail at a layer above any single vendor's platform. It also happens to be a structural argument for working with implementation partners who are platform-agnostic, but you'd expect us to say that.

A working framework: the five-pillar model

The framework below is a synthesis of what's emerged in production-grade enterprise deployments through the first quarter of 2026. It's deliberately not aspirational. Every pillar maps to controls a team can stand up in weeks, not quarters.

What gets you in trouble fastest

If we had to pick one thing for an enterprise to do this quarter, it's pillar 5. Most governance failures we see in the field are not technical. They're accountability failures. An agent does something it shouldn't, and there's no single person whose job description includes "this agent." The team that built it has moved to the next project. The vendor says it's working as designed. The workflow owner says they didn't know what the agent was doing day to day. The CISO finds out in a postmortem.

This is solvable in an afternoon. Take the list of agents currently in production. Assign each one a named human owner with the authority to pull it offline. Send each owner a one-page summary of what their agent does, what it's authorized to do, and how it's being monitored. Tell them they're accountable. That single change, made well before any of the more technical pillars are in place, materially reduces enterprise risk.

Where the EU AI Act actually bites

The Act classifies AI systems by risk level and imposes proportionate requirements. Most enterprise agent deployments fall into "limited risk" or "high-risk" categories.¹ Limited-risk agents, which include most customer service chatbots and content generators, must disclose their AI nature to users and maintain basic documentation. High-risk agents, which include financial decision-making, HR screening, healthcare support, and similar workflows, face the full set: conformity assessments, human oversight mechanisms, complete audit trails, technical documentation, and ongoing monitoring.

The Act becomes fully enforceable in August 2026. If your agents are in scope and your governance framework isn't, the question isn't whether you'll need to remediate. It's whether you'll do it on your timeline or on a regulator's.

Closing thought

The governance gap closes one of two ways. The first is structured: the workflow owner, the security team, and an outside partner who has done this before sit down and answer the four questions, then the five pillars, then write the policy document last because by then they know what to write. The second is unstructured: an agent does something it shouldn't, the postmortem reveals the gap, and the framework gets written in retrospect with the regulator on the call.

Both work. The first is significantly cheaper.