AI Agent GovernanceGuide
AI Governance Maturity Model: The 5 Levels of Attribution Depth
Most AI governance maturity models grade paperwork. This one grades attribution depth: how fast you can name who is accountable for an agent action.
Agen.co
/15 min read
An agent just moved money, changed a permission, or emailed a customer. Who is accountable for that specific action? Most enterprises can produce a policy document, an owner's name on a spreadsheet, and last quarter's access log. None of that answers the question while the action can still be stopped.
An AI governance maturity model is a graded framework for benchmarking how well your organization governs AI, from ad hoc and ungoverned through to fully enforced. Nearly every published version grades process formality: how many policies, committees, and audit cycles you have. That axis made sense when the governed object was a model in a registry. It does not survive contact with agents.
Agents act. So this guide re-axes the model on the only thing that makes an action governable: attribution depth. How precisely, and how fast, can you name the human accountable for an action while that action is still stoppable?
What is an AI governance maturity model?
An AI governance maturity model is a staged assessment framework that scores an organization's AI governance capability across defined dimensions and places it on a level, typically one through five, where each level describes observable evidence rather than intent. Security and compliance leaders use it to benchmark current state, prioritize investment, and show a board a credible trajectory.
Traditional versions inherit their levels from capability maturity thinking: ad hoc, developing, defined, managed, optimized. Those labels measure how formal your process is, and a program can be extremely formal yet unable to answer a single question at runtime. Governance maturity is one slice of the broader ai maturity model conversation, but this page is narrower: it grades control, not capability.
Why model-era maturity models break on agents
Model-era governance assumes a slow, reviewable object. A model gets trained, registered, documented, approved, and monitored on a human timescale, so a quarterly control loop is adequate. An agent is not that object. It authenticates, holds credentials, chains to sub-agents, and takes discrete actions that were never individually reviewed. Governance that stops at the model layer never touches the thing that caused the harm, because agent governance has to operate at the action layer rather than the policy layer. For the foundations, start with the complete guide to AI agent governance and the broader picture of governing AI and autonomous agents.
Why AI governance maturity is now measured at runtime
Three forces moved the goalposts at once.
Autonomy raised the blast radius per action. A copilot that drafts text is a content risk. An agent with tool access is an operational one. As autonomous AI agents take on multi-step workflows, the unit of risk shrinks to the individual tool call and multiplies in volume.
Control cadence stopped matching actor cadence. A control that fires four times a year cannot govern an actor that acts four thousand times an hour, which is why "we have a policy" and "we are governed" quietly stopped meaning the same thing.
The regulatory floor came up. The EU AI Act (Regulation 2024/1689) attaches risk-tiered obligations, human oversight duties, and record-keeping requirements to AI systems in scope, and those duties are hard to discharge without per-action records that resolve to a person. See our guide to EU AI Act compliance for the detail. This is where governance maturity becomes part of your enterprise ai strategy: the ceiling on agent rollout is now the speed at which security can say yes.
The six dimensions a credible model has to score
Most published models score strategy, ethics, data governance, and monitoring, inherited from the model era. An agentic AI governance maturity model needs six dimensions that describe whether an action can be attributed and stopped.
| Dimension | What it scores | The failing state |
|---|---|---|
| Agent inventory | Whether you can enumerate every agent running, including unsanctioned ones | Agents show up in vendor bills, not in an inventory |
| Identity assignment | Whether each agent carries its own credential rather than a shared key | Ten agents, one API key, no way to tell them apart |
| Delegated authority | Whether the chain from human to agent to sub-agent to tool is explicit and bounded | An agent inherits everything its deployer can do, forever |
| Runtime enforcement | Whether a specific action can be evaluated and blocked before it executes | An alert fires after the transaction cleared |
| Attribution and audit | Whether the log answers "which human is accountable", not just "which token was used" | Logs prove something happened, not who is answerable |
| Coverage breadth | Whether the same verdict applies on endpoint, browser, gateway and cloud, for internal and external agents | Four tools, four policies, and the incident lands in the gap |
Delegated authority and coverage breadth are the two nobody scores, and the two that decide whether the top of the model is reachable. The audit dimension is where programs meet the difference between logging and accountability, unpacked in the guide to AI audit.
The five levels of AI governance maturity
Each level is defined by one question and the evidence that answers it. The question never changes. What changes is how precisely you can answer it, and how fast.
| Level | Name | The question you can answer | Observable evidence |
|---|---|---|---|
| 1 | Unattributed | None of it | Shared service accounts and API keys; agents invisible to security |
| 2 | Inventoried | "Which agents are running, and who deployed them?" | Discovery in place, shadow agents surfaced, ownership tracked |
| 3 | Attributed | "Which human is accountable for this agent?" | Per-agent identity and a named owner per agent |
| 4 | Governed at runtime | "Should this specific action be allowed, right now?" | Per-action authorization against the identity behind the agent, with step-up and human-in-the-loop |
| 5 | Accountable by architecture | "Is the answer identical everywhere, for every agent?" | One enforcement plane across endpoint, browser, gateway and cloud; delegation chains preserved |
Level 1: Unattributed
Agents run on shared credentials. One API key fronts several workloads, so the log tells you a token acted and nothing more. Security learns about an agent when it breaks something or when finance queries the invoice. The tell is not the absence of policy, because plenty of level 1 organizations have an excellent policy binder. It is that no artifact in the environment can distinguish one agent from another.
Level 2: Inventoried
You can enumerate what is running. Discovery surfaces the agents nobody registered, which is usually when a program learns its shadow AI problem is larger than its sanctioned one. Level 2 is where an approval process starts working, because you can review new agents once you know they exist. It is also where most programs stop.
Level 3: Attributed
Each agent carries its own identity, and that identity resolves to a named accountable human. Not a team alias. A person. Agents stop being anonymous automation and become a managed identity class with its own lifecycle, joiner-mover-leaver semantics included. The mechanics are in the guide to non-human identity.
Level 3 changes what an incident looks like. You revoke one agent without breaking four others, and "who is accountable" is answered in minutes instead of a week. What it cannot do is stop anything: attribution here is a property of the record, not of the request.
Level 4: Governed at runtime
This is the jump that separates a documented program from an enforced one, and where most maturity models wave at "automated enforcement" without specifying anything. Specifics matter, so here they are.
At level 4 the unit of governance is the individual action. When an agent calls a tool, writes to a system, or spends against a budget, the request is evaluated before it executes, and the evaluation is anchored to the identity of the human behind the agent, not just to the agent's own credential. That distinction is what makes the verdict meaningful. A gateway that sees a valid token can tell you the call is authenticated, but not whether the person accountable for it is entitled to that outcome.
Four properties define the level. A program missing any one of them is not there yet.
- Pre-execution evaluation - the decision point sits inline on the request path, not on a log stream. Detection after the fact is a level 3 capability wearing level 4 language.
- Identity-anchored policy - the decision input includes the human behind the agent, the agent's own identity, the delegation chain between them, and the specific action requested.
- A preserved delegation chain - when an agent acts on a person's behalf and hands work to a sub-agent, the "on behalf of" relationship survives the hop and stays bounded. This is solved at the standards level, where OAuth 2.0 Token Exchange (RFC 8693) defines how one credential is swapped for another while recording who is acting and who is being acted for.
- Graded responses - high-consequence actions trigger step-up authentication against the accountable human, or route to human-in-the-loop approval, instead of failing the whole workflow.
Latency is the hidden gate. A verdict that takes seconds is not inline, it is an outage, so teams disable it and the level quietly reverts to 3. The decision has to return fast enough that the agent workflow does not notice it. None of this is exotic. It is the same principle NIST SP 800-207 Zero Trust Architecture applies to human access: authenticate and authorize dynamically, per request, before access is granted.
Level 5: Accountable by architecture
Level 5 is not more of level 4. It is the same verdict, everywhere, without exception. Four conditions define it.
- One enforcement plane across four surfaces. Endpoint, browser, gateway and cloud all consult the same policy and return the same answer. Four tools with four policies is not level 5 no matter how good each one is, because the incident lands in the seam. Routing agent traffic through an MCP gateway covers one surface, not the set.
- Internal and external agents on the same plane. Workforce copilots and customer-facing agents governed by one system. Almost nobody meets this condition, because internal agent tooling and customer identity infrastructure are usually separate stacks with separate owners.
- Delegation chains preserved end to end. The accountable human is resolvable at the last hop, not just the first, even with three agents and two tools in between.
- Real-time verdicts replace periodic certification. The audit question is answered continuously by the enforcement record, so the quarterly access review becomes a confirmation exercise rather than the control itself.
An organization at level 5 is genuinely AI-native in the only sense of the phrase that means anything operationally. It deploys agents faster than its peers precisely because it can stop any single action any of them takes.
What moving up one level actually buys you
| Move | What changes for the business |
|---|---|
| 1 to 2 | Shadow agents become known agents, and the approval process has something to approve. |
| 2 to 3 | Incident response drops from days to minutes: revocation is surgical, the accountable person already named. |
| 3 to 4 | Security approves new agents in hours instead of quarters, because it can stop any single action rather than vetting every possible action in advance. A velocity return, not only a risk one. |
| 4 to 5 | Blind spots between tools close, and the auditor's questions are answered from the enforcement record, not a reconstruction project. |
How to assess your AI governance maturity honestly
Self-report questionnaires inflate. Run an evidence test instead: for each dimension, name the artifact that proves the answer. No artifact, no level. This is also how a governance-focused ai readiness assessment differs from a generic one. You are testing enforcement, not intent.
- Inventory - pull the list of every agent running today. If it took more than a day, or anyone says "plus whatever the data team is running", you are at level 1 here.
- Identity - pick two agents and check whether they authenticate with distinct credentials. A shared key caps you at level 2 regardless of everything else.
- Delegation - trace one multi-agent workflow and ask whether the last tool call still knows which human initiated it.
- Enforcement - name a high-consequence action and ask what would stop it right now. If the answer describes an alert, that is detection.
- Attribution - take one action from last week's logs and name the accountable human without asking a colleague. Time it.
- Coverage - ask whether the same policy applies to an agent in a browser session and one calling through the gateway, and whether customer-facing agents are in scope at all.
Your overall level is the lowest dimension, not the average, because an auditor will find the weakest one without your help. To turn the assessment into a prioritized backlog, pair it with a structured way to map and score your agent risk.
Why most programs stall between level 2 and level 3
The plateau is well documented. Independent research into how organizations implement AI risk-management practice describes private-sector adoption as sporadic and selective at best, with most organizations lagging well behind the frameworks they cite. The interesting part is the mechanism, not the statistic.
Programs stall because policy lives in a document while agents authenticate with shared, untraceable credentials. You cannot enforce per action against an identity you do not have. Every level 4 capability depends on the level 3 primitive, so a team that funds dashboards and review boards before fixing credentials is buying visibility it can never act on. That is the difference between paper maturity and enforced maturity, and why AI security posture management is an input to governance rather than a substitute for it.
One variant catches even careful programs: pilot-to-production drop-off. Agents are governed tightly in the pilot, then inherit a broad service account when they scale, silently reverting that workload to level 1.
How the levels map to NIST AI RMF, ISO/IEC 42001, and the EU AI Act
A maturity model does not replace the frameworks your auditors know. It is the enforcement lens over them. The NIST AI Risk Management Framework organizes risk management into four core functions, Govern, Map, Measure and Manage, and is deliberately voluntary and outcome-based rather than prescriptive about mechanism. That is the space a maturity model fills.
| Framework element | Where it lands on the levels |
|---|---|
| NIST AI RMF · Map | Level 2. You cannot map what you have not discovered. |
| NIST AI RMF · Govern | Levels 2 to 3. Roles, ownership, accountability structures. |
| NIST AI RMF · Measure and Manage | Levels 3 to 5. Measurement becomes continuous once actions are attributable, and managing risk in practice means changing an outcome before it happens. |
| ISO/IEC 42001 | Levels 2 to 3. A certifiable AI management system proves the system exists and is operated, and NIST publishes a crosswalk between the AI RMF and ISO/IEC 42001. |
| EU AI Act | Level 3 floor, level 4 in spirit. Human oversight and record-keeping assume attributable actions. |
Two honest limits. Certification is not enforcement: an ISO/IEC 42001 certificate attests to a management system, not a runtime decision point, so a certified organization can sit at level 3. And the NIST Digital Identity Guidelines treat identity assurance as a graded property across assurance levels rather than a binary one, which is why a levelled model beats a checkbox. For framework detail, see our guides to the NIST AI Risk Management Framework and to ISO/IEC 23894.
AI governance maturity model vs AI maturity model vs AI readiness assessment
The three terms get used interchangeably and measure different things. A governance maturity model asks how well you can control what your AI does, and it is owned by security, IAM and GRC.
AI maturity model. The broader instrument, owned by the CIO or transformation lead. An ai maturity model grades your whole AI capability: data foundations, talent, model lifecycle, platform tooling, business integration. Governance is one slice of it. A company can score highly there while sitting at governance level 2, because capability without control is how shadow agents scale. The platform side of that picture is in our guide to the enterprise AI platform.
AI readiness assessment. Point-in-time and forward-looking, usually owned by program and platform leads. An ai readiness assessment asks whether you are prepared to begin or expand: data quality, skills, infrastructure, change management. A maturity model asks how well you already run what you have. Readiness tells you whether to start, maturity tells you what to fix before you scale. For the governance-specific version of that exercise, start from an agentic risk map rather than a generic readiness checklist.
A 30-60-90 plan to move up one level
Do not plan a climb to level 5. Plan the next level only, because each one depends on the primitive below it.
- Days 1-30, find the floor - run the six evidence tests and record your lowest dimension. Produce a real agent inventory including unsanctioned agents, and give every one a named human owner even if credentials are still a mess.
- Days 31-60, fix identity - replace shared credentials on the highest-consequence agents first. Every agent gets its own identity, tied to its accountable person, with a lifecycle that ends when that person leaves. Highest-return move on the curve.
- Days 61-90, enforce one path - pick one high-consequence action, put a decision point inline on it, and wire a step-up or human-in-the-loop response. One enforced path proves the model and gives the board something better than a policy count.
- After 90 days, widen coverage - extend the same policy to a second surface rather than adding a second tool, and bring customer-facing agents into scope before the audit does it for you.
This sequencing is the governance spine of a credible enterprise ai strategy. Strategy documents usually get the ambition right and the ordering wrong, funding dashboards before fixing the credential layer everything else depends on. Order the roadmap by dependency and the same budget buys a level instead of a report, which is the practice behind confident AI adoption.
Frequently asked questions
What is an AI governance maturity model?
An AI governance maturity model is a staged framework that scores how well an organization governs its AI and AI agents, usually across five levels from ad hoc to fully enforced. It benchmarks current state against observable evidence, defines what good looks like, and sequences the investments needed to close the gap.
What are the five levels of AI governance maturity?
Graded by attribution depth, the levels are: 1 unattributed, where agents share credentials; 2 inventoried, where every agent is discovered; 3 attributed, where each agent resolves to a named human; 4 governed at runtime, where every action is evaluated before it executes; and 5 accountable by architecture, where the same verdict applies everywhere.
How do you assess your organization's AI governance maturity?
Use evidence tests, not self-report. For each dimension, name the artifact that proves the answer: the agent inventory, distinct credentials per agent, a traceable delegation chain, an inline enforcement point, an attributable log, and consistent coverage across surfaces. Your level is the lowest scoring dimension, never the average.
What is the difference between an AI maturity model and an AI governance maturity model?
An AI maturity model grades your whole AI capability, including data, talent, platform, and business integration. An AI governance maturity model grades control specifically: whether you can attribute, authorize, and stop what your AI does. Organizations frequently score well on capability and poorly on governance.
How does the NIST AI RMF map to a maturity model?
The AI RMF defines four functions, Govern, Map, Measure and Manage, but is deliberately outcome-based rather than prescriptive about implementation depth. A maturity model supplies that depth: Map corresponds to inventory, Govern to ownership and attribution, and Measure and Manage to runtime enforcement and consistent coverage.
Does ISO/IEC 42001 certification make you mature?
No. ISO/IEC 42001 certifies that an AI management system exists and is operated, which is genuine evidence of level 2 to 3 maturity. It does not attest to runtime enforcement. A certified organization can still be unable to stop a specific agent action before it executes.
How long does it take to move up one maturity level?
Inventory work, level 1 to 2, is usually a matter of weeks. Identity assignment, 2 to 3, takes materially longer because it touches every agent owner. Runtime enforcement, 3 to 4, is the longest of the three and is gated on identity being finished first. Attempting them in parallel usually delivers none of them.
Where to go next
The useful output of this model is not a score. It is one sentence: here is the dimension where we cannot name the accountable human, and here is what we are fixing first. For most enterprises that sentence points at credentials, unglamorous work with the highest return on the whole curve.
To see what levels 4 and 5 look like when they are built rather than described, start with how we approach accountability and audit for agent actions. If the next move is the climb itself, the shortest path to adopting agents with confidence runs through the credential layer, not the policy binder.
Keep reading