AI governance maturity is still stuck at shadow and tracked AI

At a glance

What this is: This is a maturity model for AI governance that argues most enterprises are farther behind than they think, usually between shadow AI and tracked AI rather than governed AI.

Why it matters: It matters because IAM, IGA, and PAM teams need to know whether AI agent activity is merely visible, actually enforceable, and attributable across the identity chain.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read C1.ai's post on AI governance maturity and the five-rung ladder

Context

AI governance maturity is not the same thing as an AI strategy. In this post, governance means being able to inventory production agents, enforce policy at the point of action, and tie activity back to the originating human or system identity.

The article frames a five-rung maturity ladder that moves from shadow AI to compounding governance. For identity teams, the core issue is whether AI activity is only observed after the fact or actually governed in real time.

The distinction is material because many programmes confuse documentation, inventory, and policy statements with operational control. That gap shows up first in identity, auditability, and accountability.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do inventory and policy documents fail to prove AI governance maturity?

A: Because maturity depends on enforcement, not description. An inventory shows that agents exist, and a policy document shows intent, but neither proves the organisation can block, allow, or condition an action as it happens. If governance only appears after an incident or review, the programme is still operating at observation rather than control.

Q: What do teams get wrong about audit logging for AI tool use?

A: Teams often log the server error but not the identity event. For MCP, the useful record is which agent called which tool, on whose behalf, with what arguments, and when. Without that detail, incident response and compliance review become reconstruction exercises instead of evidence-led investigation.

Q: Who is accountable when a third-party AI agent misbehaves in production?

A: The organisation using the agent remains accountable for the outcomes, even if a vendor supplies the platform. Security, legal, compliance, and business owners should share responsibility for controls, monitoring, and incident response. If the agent can affect customers or regulated data, accountability cannot be outsourced with the technology.

Technical breakdown

Shadow AI and tracked AI create visibility without control

The first two rungs describe systems that exist in production but are not governed at the point of use. Shadow AI means the organisation may not know where agents run or what they touch. Tracked AI adds an inventory and some policy language, but the policy is not enforced where the action occurs. In identity terms, this is discovery without control binding. You can list the actor, but you cannot constrain its runtime behaviour or prove policy adherence from the audit trail alone.

Practical implication: treat inventory as a starting point, not evidence of governance.

Governed AI depends on request-time policy enforcement

Rung 3 introduces the control break that matters most to IAM practitioners. Governed AI is not about having policy text or a post-event audit log. It is about enforcing policy when the agent requests a tool, data source, or action. That means authorisation has to happen before the tool call completes, and the record must capture the decision, the requester, and the action context. Without that, the organisation can describe governance but not demonstrate it.

Practical implication: move controls from retrospective review into request-time enforcement and logging.

Federated reuse and compounding governance change the operating model

Rungs 4 and 5 describe a platform model in which teams publish reusable agents, tools, and policy templates, while governance becomes embedded in the platform itself. This shifts identity work from case-by-case approval toward repeatable control patterns. The deeper mechanism is that governance cost falls only when the platform standardises identity, policy, and audit primitives across teams. At that point, trust is no longer an exception process; it is the default operating model.

Practical implication: standardise identity and policy primitives before trying to scale reuse.

NHI Mgmt Group analysis

Most enterprises confuse AI documentation with AI governance. A policy deck, a wiki page, and an inventory are not the same thing as control at runtime. The article’s ladder is useful because it exposes how often organisations stop at visibility and call it maturity. Practitioners should treat this as a warning that evidence of AI existence is not evidence of AI control.

Request-time enforcement is the real maturity threshold for AI identity. The difference between tracked AI and governed AI is not whether the organisation can see agents. It is whether the organisation can stop, allow, or condition a tool call before the action happens. That distinction matters to IAM, PAM, and IGA teams because after-the-fact review does not prevent misuse. This is the control boundary that defines operational governance.

Human-origin attribution is becoming an identity requirement, not a reporting nicety. The post correctly insists on tracing activity back to the person who originated the chain, not a generic service account label. That is the point where AI governance overlaps with identity governance, audit, and accountability. If organisations cannot preserve that link, they cannot support meaningful recertification, incident review, or policy ownership.

Runtime governance gap: The most important concept here is the gap between knowing an AI agent exists and being able to govern its action in session. That gap grows when teams rely on static approvals, scattered logs, or undocumented defaults. Practitioners should recognise it as an identity control failure, not an AI adoption issue.

Federated reuse only works when the identity plane is standardised first. Teams can only safely share agents, workflows, and policy templates if the underlying identity and audit model is consistent. Otherwise reuse compounds ambiguity faster than it compounds efficiency. The practical conclusion is that scale depends on a common control plane, not just better content or more automation.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why discovery without enforcement remains a governance trap.
• That same visibility gap is explored further in the Ultimate Guide to NHIs, especially where lifecycle and runtime control must work together.

What this signals

The governance signal for IAM and IGA teams is clear: AI programmes do not become mature because the policy exists. They mature when runtime decisions are enforced, attributable, and reviewable in the same control plane, which is why the boundary between shadow AI and governed AI will become a board-level question rather than a tooling debate.

Runtime governance gap: organisations should expect this phrase to define the next phase of AI identity work. If the audit trail cannot answer what happened, who originated it, and whether policy was enforced at the moment of action, the programme is still absorbing risk instead of governing it.

The practical direction is to align AI governance with identity lifecycle, privilege control, and audit design rather than treating it as a standalone AI operations problem. Teams that standardise identity primitives now will have a defensible path to federated reuse later.

For practitioners

• Inventory production agents with a single source of truth Build one authoritative register for every agent, workflow, and tool call path so you can answer what is running, who deployed it, and what it touches without stitching together five systems.
• Enforce policy at request time Move from wiki policy to runtime authorisation that evaluates each tool call before execution, and log the decision with requester, action, and context.
• Preserve originator attribution through the full chain Require audit records to retain the human originator, not just the service account or platform identity, so investigations and recertification can trace accountability end to end.
• Make the governed path faster than the unsafe path Remove workflow friction that pushes developers toward downloadable credentials or unmanaged shortcuts, because the fastest path usually becomes the real control boundary.

Key takeaways

• AI governance maturity is measured by runtime control, not by strategy language or documentation volume.
• Most organisations still struggle to prove who deployed agents, what they touched, and whether policy was enforced at action time.
• Identity teams should treat AI governance as a request-time authorisation and accountability problem, not just an inventory problem.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Request-time enforcement: Request-time enforcement is the practice of evaluating a proposed access change before it becomes active. In identity governance, this shifts SoD from a retrospective review activity into a preventive control that can block, escalate, or reroute risky entitlement combinations.
• Originator attribution: The ability to trace an action back to the human or system that initiated the chain, not merely the intermediary account that executed it. For AI programmes, this is essential for accountability, recertification, incident review, and assigning policy ownership.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

• The five-rung maturity ladder with the specific signals used to distinguish each level in practice.
• The four diagnostic questions in full, including the operational examples behind each test.
• The ADAPT series context and the executive meeting structure used to set the next-stage roadmap.
• The article’s framing of how teams move from inventory and policy language to governed execution.

👉 C1.ai's full post expands the diagnostic questions, maturity signals, and executive roadmap guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.