Treating Agent Governance as More Than a Policy

Ask a large enterprise about AI governance and you will, in most cases, be handed a document.

Every company has a policy.

Ask a large enterprise about AI governance and you will, in most cases, be handed a document. An acceptable-use policy, updated last quarter. A review committee that meets monthly. A set of principles — human oversight, data protection, responsible use — that nobody disagrees with and nothing enforces.

Credit where it's due: that document represents progress. A few years ago most companies had nothing — no policy, no committee, no principles. The issue is that the market's innovation has been relentless, and it is outpacing the machinery built to govern it. The document was written for a slower world than the one shipping around it.

Ask the operational question and the gap shows. How many agents are running in your environment right now, what can they reach, and who owns each one? The document doesn't know. The committee doesn't either. As mentioned in Chapter 1, Deloitte finds that only one in five companies has a mature governance model for agentic AI.1

Agent governance eats its predecessors

AI governance, as most enterprises built it, governs a technology: which models are approved, what data may touch them, how usage is reviewed. It was designed in the first-party era, for the AI the company chose, and it works where there's a decision point to attach it to — a procurement gate, a launch review, a model approval. Alongside it, most enterprises also run some form of application governance: the app inventory, the vendor review, the access recertification. That governs the software estate.

Agent governance includes both by default. An agent is AI acting through applications, so governing agents means governing the models underneath them and the third-party products around them as an entry-level requirement. But an enterprise could do both of those well and still fail at the actual job, because agents add what neither predecessor has an answer for: autonomous actors that hold identities, inherit permissions, form connections across the application layer, act without a human in the loop, and multiply at machine speed. AI governance asks "Is this model approved and used responsibly?" Application governance asks "Is this product sanctioned and correctly configured?" Agent governance has to ask “What is operating, what can it reach, who owns it, and what is it doing right now?” across a population that changes daily.

So the succession runs: application governance governed the software you bought. AI governance governed the intelligence you adopted. Agent governance governs the actors those two produced together and it inherits both of its predecessors' jobs the way an operating system inherits its drivers. You don't get to skip them. You also don't get to stop there.

Chapters 1 and 2 established why: agents arrive through third-party software, are built by anyone on anyone's platform, ride their creators' permissions, and multiply at machine speed into an application layer with no fixed edges. You cannot govern that with a document for the same reason you cannot govern air traffic with a memo about flying responsibly.

Agent governance is not a document. It's a practice.

Agent governance is not a document. It's a practice — a standing operating capability that produces current answers on demand. The rest of this chapter is what that practice consists of, layer by layer, and why the order of the layers matters.

What the practice has to hold

Be precise about the thing being governed, because its shape dictates the practice.

Instead of a list of models to approve, it's a moving population: agents inherited with your platforms, agents built by engineers and by marketing ops, agents that build other agents. Regardless of origin, each agent holds identities, inherits permissions, forms connections, and generates activity across hundreds of interconnected systems. The population changes daily. The connections change hourly. Any governance built on a point-in-time review is governing a photograph of a universe that kept expanding after the shutter clicked.

To that end, a good agent governance practice has three properties before it has any features. It's continuous, because the environment is. It's contextual, because Chapter 2's lesson holds: the risk is never in the agent alone, it's in what the agent can reach. And it scales without per-agent ceremony, because the population grows exponentially — any approach that requires a human ritual per agent collapses under the weight of the population it's supposed to govern.

The stack, from the bottom

Governance programs fail most often because the security team writes the rules before it can see the things the rules apply to. The working order is bottom-up, and each layer is the precondition for the one above it.

Discovery

You cannot govern what you don’t know about, and finding agents is harder than finding software ever was. Most agents never touch SSO. They surface in different places — app configurations, OAuth grants, network traffic, endpoint telemetry, email metadata, the browser. The OWASP Agentic Skills Top 10 now names the sharpest version of the gap under its "No Governance" category: a skill deployed and managed inside a third-party platform is unreachable by external scanners — the tools you point at the problem from outside can't see inside the venues where most agents live.2 Discovery has to be multi-vantage and permanent. This layer is the foundation for everything, and it's where many programs fail: in environments Reco has studied, connecting a single platform surfaced more than 100 agents before any agent platforms were even connected.

Posture

Once you can see the population, the first risk to manage isn't the exotic one — it's configuration. The uncomfortable truth of the agent era is that most exposure starts with defaults: the guest-user profile someone configured three years ago, the intake feature nobody connected to the new agent platform, the sharing rule that made sense before agents could read everything it exposed. The Agentforce chain in Chapter 2 wasn't an exploit; it was a configuration. The City-Forum campaign that Reco's research team tracked across Salesforce and ServiceNow instances worldwide ran for over a year on exactly this: misconfigurations, working as configured. Posture management (i.e., knowing how every platform's agent-relevant settings are configured, continuously, against how they should be) is where governance earns most of its risk reduction.

Identity and ownership

Every agent gets an identity and an owner, or it doesn't run. This is the layer where the first-party era's habits translate best (the enterprise already knows how to do joiner-mover-leaver for humans) and where the agent era breaks them hardest (agents don't join through HR, don't leave when their creator does, and outnumber employees in a growing number of environments). The operational test is simple. Pick an agent at random; if no human raises their hand within a day when asked "whose is this?", your identity layer isn't working.

Usage

Who in the organization is using which AI, through what surface, with what data — the AI governance job, inherited whole. This is where personal adoption becomes visible. It's also where governance most often over-corrects into blocking, and blocking backfires twice. It teaches employees to route around visibility, and worse, it kills good ideas that agents could have made real. It’s important to remember that most of the individuals building agents in your enterprise aren’t trying to compromise security. Marketing ops building an agent wants pipeline reports, not a breach. They don’t lack good intent but they do lack any way of knowing whether the agent they just wired together is safe. The usage layer done right is enablement infrastructure: see what people are building and meet them there with the secure path, so the good idea ships and the exposure doesn't.

Agent controls

Only now — with the population discovered, platforms configured, identities owned, and usage visible — do the rules in the policy document become enforceable: least-privilege scopes checked against actual need, approval and quarantine for new agents, review cadences that re-check whether access still matches function as agents and platforms change. And with the population governed, prioritization becomes possible in a way flat finding lists never allow: risk tiering that reflects each agent's full context (i.e., what it can do, who can reach it, and what it touches) so the same finding on a sandboxed dev agent and a customer-facing one shows with different severities, and the queue starts with the one that matters. This is the layer that exists in no predecessor discipline — the part of agent governance that is only agent governance.

Runtime

Live inspection and intervention on agent actions. The point here is placement: runtime sits last because every question that it has to answer in milliseconds — is this action normal for this agent, is this data sensitive, is this destination approved — is answered by the layers below it. Deploy it without them and it enforces blind.

Non-compliance will be expensive

If the operational argument doesn't move an organization, the financial one should.

The EU AI Act's penalties are already live and carry GDPR-level fines: up to €35 million or 7% of global annual turnover for prohibited practices, up to €15 million or 3% for other violations. The prohibited-practices ban has applied since February 2025; broader transparency and GPAI obligations followed in August 2026.3 The rest of the world's frameworks — NIST AI RMF, ISO/IEC 42001, sector regulators — are converging on the same expectations: inventory your AI systems, assign accountable owners, demonstrate oversight, evidence it on request. Every one of those verbs assumes the stack above exists. An organization that cannot enumerate its agents cannot inventory them; one that cannot name owners cannot assign accountability; one with no posture layer cannot evidence oversight of systems it isn't watching.

GDPR already ran this experiment, and the results are public. British Airways was fined £20 million4 and Marriott £18.4 million5 when breaches exposed the gap between their documented policies and their operational reality; Meta's €1.2 billion fine in 20236 remains the ceiling so far, and cumulative GDPR enforcement has passed €7 billion.7 The problem in these examples doesn’t stem from imperfect policies — everyone had (and still has) imperfect policies. These companies were the ones whose compliance existed on paper and nowhere else, and who couldn't produce evidence of operational control when regulators asked. The companies that fare better have made compliance a byproduct of operations: the evidence exists because the practice produces it continuously.

An agent governance practice built bottom-up generates that audit trail — the inventory, the owners, the configurations, the review history.

What the board actually wants

Chapter 1 ended with the squeeze: boards demanding agent adoption and accountability in the same breath. The governance practice is what resolves the squeeze, because it's what turns "yes" into a defensible answer.

A CISO we spoke with described presenting exactly this to the board: a live dashboard of the organization's AI and agent estate — what's running, what it can reach, how posture is trending — instead of a policy summary. The difference in the room is the difference between reporting a philosophy and reporting a position. Boards know how to govern from positions. How many agents do we have? A number, current as of this morning. What can they reach? A map, with the toxic combinations flagged. Who's accountable? Names.

IPCA Framework for Governance

Identity

Ownership registry

Permissions

Least-privilege review cadence

Connectivity

Toxic combination detection

Activity

Baselines and drift

And that's the point to end this chapter on: agent governance, done as a practice, isn't the brake on agent adoption. It's the thing that lets the enterprise say yes quickly — to the next platform, the next agent builder, the next Slack Code — because yes comes with eyes open and a current map. The companies moving fastest on agents this decade will be the ones that can see them.

Next: In chapter 4, we’ll explore what it means to actually secure an agent and why everything in this chapter still doesn’t stop the attack that comes through the front door.