The Agent Governance Maturity Model

The Problem With "Are We Governed?"

Ask a CISO whether the enterprise's agents are governed and you get an anecdote, not an assessment. One team points to a policy document. Another points to a runtime guardrail. A third quietly hopes the question moves on. None of them is lying; they simply have no common scale to answer on. "Governed" is treated as a binary — yes or no — when it is actually a ladder with many rungs, and different parts of the enterprise are standing on different ones.

This is the exact problem the Capability Maturity Model solved for software process in the 1990s. Before CMMI, "is our process any good?" produced the same shrug. CMMI's contribution was not a control — it was a vocabulary: five named levels that let an organization locate itself, agree on where it stood, and see the specific next rung. The grade came first; the improvement followed, because you cannot improve toward a target you cannot name.

Agent governance is at the pre-CMMI moment now. The controls are being invented in the open — identity schemes, runtime policy, audit trails — but there is no agreed ladder telling an enterprise which rung it is on. This is that ladder.

Six Levels, Zero Through Five

The model runs from 0 to 5. Each level is a described organizational state, not a checklist score — you are at the level whose defining condition you have genuinely met, and no higher. As with CMMI, each rung subsumes the ones below it: you do not reach Controlled without first being Scoped, and you do not reach Scoped without first being Inventoried. The "how you'd know" column is the honest test — the evidence you could produce today if the board asked.

Level	Defining state	How you'd know
0 — Ad-hoc	Shadow agents. Teams have stood up agents against API keys with no central awareness. There is no inventory and no agreement that there should be one.	You cannot answer "how many agents are running?" with a number. Any figure you give is a guess.
1 — Inventoried	You can enumerate every agent. There is a roster — who authored each, what model it runs, where it lives — and it is believed to be complete.	You can produce the full list on demand, and a spot check finds no agent missing from it.
2 — Scoped	Delegated authority is explicitly declared per agent. For each one, the scope of what it is permitted to decide and do is written down, not assumed.	For any agent, you can point to a declared authority scope — not "it can reach whatever the key reaches."
3 — Controlled	That declared authority is enforced at runtime, not merely described in a prompt. The control plane blocks out-of-scope actions rather than politely asking the model not to take them.	You can attempt an out-of-scope action in a test and watch the system refuse it — enforcement, not instruction.
4 — Governed	Every agent action is attributable and auditable, and the kill-switch works with proof. You can trace who did what, and decommission an agent with evidence that it is off.	You can reconstruct any action's full trail, and demonstrate an agent is revoked — not just assert it.
5 — Accountable	A named human or team owns each agent, and the workforce is under continuous review — scopes re-examined, retired agents removed, governance treated as an operating discipline, not a project.	Every agent traces to an owner who answers for it, and review is scheduled and recurring, not one-time.

Read the ladder as a single trajectory: from not knowing what you have (0), through knowing and scoping it (1–2), to enforcing and proving it (3–4), and finally to owning it as a standing discipline (5). Governance is not a control you install once. It is a state you climb into and then hold.

Maturity Advances Across Layers, Not Just Up Levels

A maturity model that is only a vertical ladder hides something important: governance maturity does not advance evenly across an enterprise. It advances across the four layers of the Enterprise Agent Architecture — Agent / Workforce, Capability / Tool, Control Plane, and Governance — and most organizations are more mature in some layers than others. Mapping the levels onto the layers turns a single grade into a diagnosis.

EAA layer	Where the maturity levels bite
Agent / Workforce	Levels 0–1 live here. Moving off Ad-hoc means building the inventory — knowing which agents exist, who authored them, and what they run.
Capability / Tool	Level 2 lives here. Scoping means declaring, per agent, which tools, APIs, and data its delegated authority actually reaches. You cannot scope authority without naming what it touches.
Control Plane	Levels 3–4 live here. This is where declared scope becomes enforced scope — the runtime that blocks out-of-scope actions, records every action for attribution, and executes the kill-switch with proof.
Governance	Level 5 lives here. Named ownership, continuous review, and the operating discipline that keeps every layer below it from decaying back down the ladder.

The cross-map exposes the common failure mode: an enterprise that has invested in a slick control plane (a Level-3 capability) while its workforce layer is still at Level 0 — enforcing scopes on an agent roster it cannot fully enumerate. Sophisticated enforcement over an incomplete inventory is not Level 3. Your real maturity is the lowest layer's maturity, because an agent you never inventoried is one your control plane never governs.

What Each Rung Actually Costs

The value of a maturity model is that it makes the next step concrete instead of aspirational. Each transition is a specific piece of work, not a posture.

0 → 1: Build the census Discover every agent, including the shadow ones, and put them in one roster with authorship and model provenance. The work is discovery and reconciliation — and it usually surfaces agents no one remembered deploying.
1 → 2: Declare authority explicitly For each agent, write down the scope it is granted — not what its credentials technically reach, but what it is authorized to do. This forces the uncomfortable conversation about over-broad keys.
2 → 3: Move scope from prose to runtime Stand up a control plane that enforces the declared scope, so an out-of-scope action is refused by the system rather than discouraged by a prompt. This is the jump from description to control — and the hardest rung.
3 → 4: Make everything provable Instrument attribution and audit so every action traces to an agent, and build a kill-switch whose effect you can demonstrate. "We turned it off" becomes "here is the proof it is off."
4 → 5: Assign owners, schedule review Give every agent a named human owner and put the workforce under recurring review. This is an org-design change more than a technical one — and it is what keeps the lower rungs from eroding.

Note the shape of the ladder: the early rungs are documentation, the middle rung is genuine architectural investment, and the top rung is organizational. Enterprises that stall almost always stall at 2→3 — where governance stops being paperwork and starts being a runtime.

Where Most Enterprises Actually Sit

The honest observation, from the field, is that most enterprises today sit at Level 0 or 1. Their agents are already live — making decisions, calling tools, acting on delegated authority — but they cannot produce a complete inventory of them. This is the blank-row problem from Part 1 of this series, now expressed as a grade: the workforce is on the floor, and the roster does not exist.

That is not a failure of diligence. It is what happens when a workforce is deployed faster than the architecture to describe it, using the same instinct that stood up a shadow integration a decade ago. The maturity model's first gift is permission to say so plainly: we are at Level 1, and our next move is to reach Level 2 is a far stronger position than a vague claim to be "governed." A named level is a plan. A shrug is not.

Where Does Your Organization Sit?

The model is only useful once you locate yourself on it. The most reliable way to do that is not to grade the enterprise as a whole — it is to grade each of the four layers separately and take the lowest as your true level. Can you enumerate every agent (Workforce)? Is each one's authority declared against the tools it touches (Capability)? Is that authority enforced and attributable at runtime (Control Plane)? Does a named owner review it on a schedule (Governance)?

A structured self-assessment against exactly these four layers is available at /governance-stress-test — a way to assess where you stand, honestly, before anyone else grades you. It asks the questions above and returns a layer-by-layer read rather than a single flattering number.

This maturity lens is a way of grading the topmost layer of the Enterprise Agent Architecture — the Governance layer, where ownership, review, and accountability live. That layer is the subject of Part 4 of the series, which takes the discipline this model measures and describes how it is actually built.

About This Series

Michael K. Saleme — Enterprise Agent Architect

Enterprise Agent Architecture is published as a position-paper series — the canonical account of the practice, released one part at a time. The Practitioner Series pieces, of which this is one, are the durable framework artifacts: reference models an enterprise can adopt and grade itself against, in the tradition of CMMI and TOGAF.

The recurring work of three decades of enterprise architecture has been the same four concerns — identity, integration, authorization, and control. A maturity model does not add a fifth concern; it grades how far an enterprise has carried those four into a workforce that now reasons and acts on its own.