By NHI Mgmt Group Editorial TeamBased on C1.ai: “The Four Stages of AI Adoption, and What Separates the Companies That Get It Right” (June 1, 2026)

TL;DR: C1.ai argues that AI adoption moves from scattered exploration to piloting, embedding, and transformation, and that governance gaps widen as tools and agents shift from occasional use to actors inside enterprise workflows. Identity, access, and audit controls have to evolve with that behaviour or security teams end up retrofitting governance after production exposure.


At a glance

What this is: This blog maps four AI adoption stages and concludes that governance lags most sharply once AI tools and agents become embedded in business workflows.

Why it matters: It matters because IAM, IGA, and security teams have to govern AI identities and actions before embedded use turns into unmanaged access, audit, and policy exposure.

👉 Read C1.ai's analysis of the four stages of AI adoption and the governance gap


Context

AI adoption now spans employee experimentation, piloted use cases, embedded workflows, and enterprise transformation. The governance problem is not the presence of AI itself, but the point at which tools and agents start acting inside business processes with access to data and systems.

For identity teams, the relevant question is when AI stops being a productivity aid and starts behaving like an actor that needs identity, policy, and audit controls. That shift changes the control model from visibility over use to governance over execution.


Key questions

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Q: Why do AI pilots create risk even when they are formally approved?

A: Approved pilots often govern only a small island of AI use while the wider organisation keeps experimenting informally. That split leaves a gap between policy and practice, which is where risk accumulates. If the controls do not cover the full usage footprint, the pilot becomes a narrow exception rather than a governance model.

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Should organisations prioritize visibility or least privilege first for AI agents?

A: Organisations should do both, but visibility comes first because you cannot restrict what you cannot find. Once agents, tokens, and delegated workflows are discovered, least privilege can be applied to narrow scope and reduce blast radius. Without discovery, least privilege is incomplete because the hidden population remains unmanaged.


Technical breakdown

Shadow AI turns discovery into an identity problem

In the exploring stage, AI use is diffuse, unapproved, and often invisible to central IT. That makes the first control issue inventory, not enforcement: teams need to know which tools are being used, what data they touch, and whether they create unsanctioned access paths. This is a governance gap because policy cannot protect what it cannot see, and informal adoption tends to outpace approval workflows. Once AI use becomes embedded in work habits, the discovery problem turns into a lifecycle problem for identities, data flows, and authorisations.

Practical implication: inventory AI tools and usage paths before you try to govern permissions or approvals.

Governed pilots create a split brain between sanctioned and real-world AI

Piloting adds structure, but it also creates a false sense of control if governance only covers the approved sandbox. The article highlights a common split brain: one department has workflows, access controls, and approvals, while the rest of the organisation continues using whatever works. That means the risk surface is not the pilot itself, but the gap between official AI and actual AI. Identity governance has to follow the full usage footprint, not just the pilot charter, or sanctioned controls become a narrow exception rather than the operating model.

Practical implication: assess pilot controls against enterprise-wide usage, not against the pilot scope alone.

AI actors need governed identity once they execute business actions

When AI is embedded in workflows, the article treats tools and agents as actors because they access data, call APIs, and execute actions on behalf of people. That is the point where identity design changes materially. Least privilege, policy enforcement, access reviews, and audit trails must apply to the AI layer, not just the human user who requested it. This is no longer about user experience or feature rollout. It is about controlling what an AI system can do, when it can do it, and how those actions are attributed back into the control environment.

Practical implication: assign governed identity and policy enforcement to every AI workflow that can take action.


Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI adoption is becoming an identity governance problem before it becomes a platform problem. The article shows that AI moves from informal use to embedded execution long before most organisations redesign controls. That means the first failure is not technical sophistication but governance lag, where policy, review, and audit functions are still built for human-paced approvals. Practitioners should treat AI uptake as an identity lifecycle issue from the start.

Shadow AI creates a governance blind spot that traditional sanctioning models do not close. Approving a pilot does not govern the dozens of adjacent tools employees keep using in parallel. The article’s strongest insight is that sanctioned AI and actual AI diverge quickly, which makes tool approval a weak proxy for risk control. Teams need a broader view of AI usage, data paths, and action authority, or they will govern only the visible minority.

Every AI agent that can act on behalf of a user becomes an identity subject, not just an application feature. Once an agent can call APIs, access sensitive data, or trigger workflow steps, identity controls have to cover that execution path directly. The implication is not merely more security review. It is a change in what identity governance is governing: not people alone, but machine execution tied to business authority.

The named concept here is governance lag: the delay between AI becoming operational in business processes and the identity controls needed to supervise it. In the exploring and piloting stages, that lag is manageable. In the adopting and transforming stages, it becomes a structural gap that forces retroactive security work. Practitioners should measure whether control design is keeping pace with AI execution.

Transformation only works when governance is designed as part of the operating model. The article’s final point is that AI scale does not reduce the need for identity discipline; it increases it. Organisations that build policy, access reviews, and auditability into the AI path can move faster with less friction. For identity leaders, the operational conclusion is simple: if AI can act, governance must already be in the path.

From our research library:

What this signals

Governance lag: AI programmes now fail most often at the point where adoption outpaces identity control design. The operational question is no longer whether AI is allowed, but whether the organisation can govern execution paths fast enough to avoid retrofitting controls after users have already normalised the tool.

The practical boundary is simple: if an AI system can reach data, make calls, or route work, it belongs in the identity model. That is why identity and access teams need to shift from tool approval to execution governance across the full AI footprint.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap explains why AI adoption programmes often advance faster than the governance models meant to contain them.


For practitioners

  • Inventory all AI tools in use Map sanctioned and unsanctioned tools, then identify which teams, workflows, and data classes they touch. The goal is to close the visibility gap before AI use becomes embedded in normal business processes.
  • Define identity for AI actors Treat AI agents and integrated AI services as governed identities with scoped permissions, ownership, and revocation paths. If a system can call APIs or take actions, it needs an identity model, not just a feature flag.
  • Extend access reviews to AI execution paths Review who can create, approve, and connect AI workflows, and verify that those paths are auditable end to end. Manual user recertification is not enough when the actor can act between review cycles.
  • Build policy enforcement into workflow design Place approval, logging, and access constraints inside the AI workflow rather than around it. That reduces the need for retroactive remediation when AI moves from pilot to production.

Key takeaways

  • AI adoption becomes an identity issue once tools and agents move from isolated use into governed business workflows.
  • The hardest risk is not experimentation itself, but the gap between approved pilots and the unapproved AI use that continues around them.
  • Security teams need visibility, scoped identity, and auditable policy paths before AI becomes embedded enough to make retrofitting the default response.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseAI agents acting on behalf of users creates identity and privilege governance risk.
Recommendation — Apply ASI03 to scope agent privileges and review every action path an agent can take.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about governing AI adoption as it moves into operations.
Recommendation — Use GOVERN to assign accountability for AI use, access, and auditability across the organisation.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAI workflows need permissions and entitlements governed like other executing identities.
GV.OC-01 — Organizational ContextThe article frames AI governance as an enterprise operating-model issue, not a tool issue.
Recommendation — Apply PR.AA-05 to ensure AI tools and agents only have the access required for their tasks. Define AI adoption scope, ownership, and control boundaries within your organisational context.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementAI tools and agents that authenticate to systems need managed credentials and revocation paths.
Recommendation — Use IA-5 to manage AI credentials, rotations, and revocation for workflow access.

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.
  • Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
  • AI Identity Scope: The set of resources, tools, and credentials an AI system can access in order to complete a task. Proper scope is narrower than generic user access because autonomous systems can chain actions quickly, making overbroad permissions far more damaging than in human-only workflows.
  • Governance Latency: Governance latency is the delay between a change in risk, relationship, or access need and the point at which the control model reflects that change. In API environments, high governance latency turns simple access management into a bottleneck and increases residual exposure.

What's in the full article

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

  • The stage-by-stage examples of exploratory, piloted, adopted, and transformative AI use
  • The article's specific guidance on treating AI agents as governed actors inside enterprise workflows
  • The operational distinction between sanctioned AI use and the wider shadow AI footprint
  • The author's closing argument on building governance as a foundation rather than an afterthought

👉 The full C1.ai post expands the stage model and the governance implications for AI at enterprise scale.

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 identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org