TL;DR: C1.ai says enterprise AI adoption is being slowed by shadow use, policy gaps and unmanaged tool access, with 75% of knowledge workers already using AI tools, 78% bringing their own and only 18% knowing company AI policy. The real governance test is whether access, audit and lifecycle controls can keep pace with AI tools, agents and MCP connections before shadow AI becomes the default.
At a glance
What this is: C1.ai argues that AI access management extends identity governance to AI tools, personal assistants, agents and MCP connections, with the main finding being that governed access must be faster than shadow adoption.
Why it matters: For IAM, IGA and security teams, the practical issue is not AI usage itself but whether policy enforcement, auditability and lifecycle control can cover AI identities before unmanaged access spreads.
By the numbers:
- 75% of knowledge workers use AI tools today, according to C1.ai.
- 78% bring their own AI tools, according to C1.ai.
- Only 18% of employees know their company’s AI policy, according to C1.ai.
👉 Read C1.ai's AI access management analysis for enterprise AI adoption
Context
Enterprise AI adoption creates a governance gap when users can access tools and agents outside the approved path. In identity terms, the problem is not only authorization at login, but who can request, use, and retain access to AI tools, MCP connections, and agent credentials over time.
C1.ai positions AI access management as a way to bring those AI interactions back under policy, audit, and lifecycle control. That matters because shadow AI is not a niche exception when most workers are already using AI tools and many are bringing their own.
The article is typical of current enterprise AI adoption patterns: usage moves faster than policy comprehension, while security teams are asked to govern a growing identity surface that includes tools, assistants, and autonomous agents.
Key questions
Q: How should organisations govern AI usage when employees use unapproved tools?
A: Organisations should start with visibility, not enforcement. If teams cannot see which apps, agents, or workflows are being used, they cannot assess data exposure or apply meaningful controls. Once usage is mapped, policy can shift from blanket bans to context-based decisions that reflect sensitivity, role, and business purpose.
Q: Why do AI tools create new identity governance risks for IAM teams?
A: AI tools create new identity governance risks because they combine fast adoption with broad access paths and subordinate permission objects. A user may look clean in the directory while the platform still holds project roles, service accounts, or keys that can act independently. That makes governance a control-plane problem, not a simple login problem.
Q: When do AI access controls fail in practice?
A: They fail when authorization happens after retrieval, when tool permissions are broad, or when response masking is treated as optional. In those cases the system has already pulled sensitive content into context or invoked a privileged action before policy intervenes. The safest design is source-side enforcement before the model sees the data.
Q: How do access, audit, and lifecycle controls change for enterprise AI adoption?
A: They have to cover AI tools, assistants, agents, and the connections they use, not just the human requester. Access must be granted with policy context, every tool call must be logged, and revocation must work at the identity level so governance stays current as AI usage changes.
How it works in practice
Why AI access management is an identity problem, not just a tool problem
AI access management sits at the intersection of identity governance, authorization, and audit because AI tools are now part of the enterprise access surface. If users can request, connect, and use AI tools without governed entitlement checks, the organisation loses visibility into who approved the access, what data the tool touched, and how long the access remained active. Treating AI tools and agents as governed identities is the only way to make access review and compliance evidence meaningful. Practical implication: model AI tools, assistants, and agents as access-bearing identities in IAM and IGA workflows, not as informal productivity add-ons.
Practical implication: model AI tools, assistants, and agents as access-bearing identities in IAM and IGA workflows, not as informal productivity add-ons.
How MCP connections expand the governed attack surface
Model Context Protocol connections turn an AI experience into a governed integration path between the agent and enterprise systems. That changes the security question from 'what can the model say' to 'what systems can the agent invoke, under which credentials, and with what logging'. If MCP servers are effectively exposing API-backed applications through a new control plane, then access policy, credential protection, and authorization context must follow the connection, not just the user session. Practical implication: inventory MCP endpoints with the same rigor used for APIs and third-party integrations.
Practical implication: inventory MCP endpoints with the same rigor used for APIs and third-party integrations.
Why lifecycle control matters for AI agents and assistants
An AI agent is not automatically autonomous, but it is still a non-human identity when it holds credentials, ownership, and policy state. That means lifecycle failures look familiar: orphaned access, stale permissions, and unclear ownership, only at machine speed and with broader reach. If the platform can rotate credentials and revoke access instantly, the governance issue becomes whether that lifecycle is actually tied to the agent's role and business purpose. Practical implication: attach owners, expiry conditions, and revocation rules to every AI agent identity.
Practical implication: attach owners, expiry conditions, and revocation rules to every AI agent identity.
NHI Mgmt Group analysis
AI access management is now a governance layer, not a convenience feature. The article reflects a broader shift in which AI tools, personal assistants, and enterprise agents become first-class access subjects. That means identity teams are no longer only approving users and service accounts, but the AI-mediated pathways those identities use to reach enterprise systems. The practitioner implication is that AI adoption and access governance now move together.
Shadow AI is the operational proof that policy comprehension is part of the control surface. If most employees use AI tools and very few know the policy, the gap is not simply user behaviour. It is a governance design failure where approved access is slower and less usable than unapproved access. That makes policy adoption, entitlement clarity, and request flow design central to security outcomes.
AI agents should be governed as non-human identities with explicit ownership and lifecycle states. Once an agent has credentials, policy state, and revocation rules, it behaves like any other NHI from a governance standpoint, even if its runtime decisions are more dynamic. The important question is not whether the system is autonomous, but whether its access can be owned, reviewed, and retired with the same discipline as other machine identities. Practitioners should align agent governance to NHI lifecycle controls.
MCP creates a new abstraction layer that can hide privilege expansion if it is not inventory-led. When applications become accessible through governed MCP servers, the integration point becomes the new place where privilege, approval, and audit must be enforced. If the control plane is not mapped to underlying APIs and entitlements, organisations may think they are governing AI use while actually governing only the front door. Practitioners should treat MCP inventory as a prerequisite to trustworthy AI governance.
Named concept: governed path precedence. The article's central idea is that the approved route to AI access must be faster than the ungoverned one. That is a useful way to frame AI governance because it ties control design to user behaviour rather than policy language alone. The practitioner implication is simple: if the sanctioned path is slow, shadow AI will become the default access model.
From our research library:
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
- 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.
- Read next: NHI Lifecycle Management Guide
What this signals
Governed path precedence: AI governance now depends on making the approved route faster and clearer than the shadow route. When employees can reach AI tools and agents more easily through unofficial channels, policy becomes advisory instead of enforceable, and that is when access sprawl starts to outrun review.
MCP inventory is becoming a control prerequisite: once AI tools can invoke enterprise applications through governed connectors, practitioners need to know which applications sit behind each MCP server, which credentials are in play, and where the audit trail begins. Without that mapping, access management can look complete while hidden integrations remain outside sight.
Policy awareness is now part of identity governance for AI adoption. If employees do not know which tools are approved or how access is granted, they will choose convenience over compliance and security teams will inherit unmanaged AI usage as a standing condition.
For practitioners
- Map AI tools as governed identities Classify AI tools, personal assistants, and enterprise agents as access-bearing identities in IAM and IGA records, including owner, purpose, approval state, and revocation path.
- Inventory MCP connections before broad rollout Create an inventory of MCP servers, the enterprise applications they expose, and the credentials used to invoke them so hidden integration paths do not bypass policy.
- Bind credentials to lifecycle states Attach expiry, ownership, and revocation rules to each AI agent credential so access can be removed as soon as the business purpose ends.
- Shorten the governed request path Make approved AI access faster to obtain than shadow alternatives by simplifying request, approval, and provisioning steps without dropping policy checks.
- Audit AI policy awareness Measure whether employees can identify which AI tools are approved, which data they may handle, and which requests require review before use.
Key takeaways
- AI access management is emerging as the governance layer that determines whether enterprise AI adoption stays visible, policy-driven, and auditable.
- The biggest risk is not AI usage itself but the combination of shadow adoption, weak policy awareness, and unmanaged access paths into enterprise systems.
- Practitioners need identity-level ownership, lifecycle controls, and fast governed request flows if they want adoption to stay within control boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address 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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI tools and agents with broad access mirror over-privileged non-human identities. |
| NHI-10 — Human Use of NHI | Employees using AI tools through unmanaged paths blend human intent with non-human access. | |
| Recommendation — Limit AI tool entitlements to the minimum scope required for each approved use case. Separate human request flows from non-human execution paths and log both clearly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents and assistants can misuse delegated access when privilege is not tightly bounded. |
| Recommendation — Constrain agent credentials and verify every high-risk tool call before execution. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article centres on governance, accountability, and policy enforcement for enterprise AI use. |
| Recommendation — Assign clear accountability for AI access decisions and document escalation paths for exceptions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core control issue is entitlement management for AI tools, agents, and connectors. |
| Recommendation — Review and enforce AI-related entitlements with the same discipline used for other privileged access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential protection and revocation are central to managing AI agent and tool access. |
| Recommendation — Apply authenticator lifecycle controls to AI credentials, including rotation and immediate revocation. | ||
Key terms
- AI Access Management: AI Access Management is the governance layer that controls which AI clients, assistants, and agents can reach enterprise tools and data. It combines entitlement requests, policy enforcement, logging, and review so AI use is governed through identity controls rather than ad hoc exceptions.
- 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.
- MCP Connection: An MCP Connection is the live link between an AI agent and an external tool, data source, or service using the Model Context Protocol. It defines how the agent discovers capabilities, exchanges context, and requests actions. Security controls should govern authentication, authorization, scope, logging, and revocation for each connection.
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
What's in the full announcement
C1.ai's full post covers the operational detail this post intentionally leaves for the source:
- Self-service provisioning flow for AI tools and agents, including policy-based auto-approval and routed human approval
- Examples of how credential vaulting and instant revocation are applied to AI identities in practice
- How full audit context supports access certification workflows and compliance evidence generation
- How hosted MCP servers extend governed access to API-backed applications
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org