TL;DR: Enterprise AI adoption is colliding with weak policy awareness, shadow use, and unmanaged tool access, with 75% of knowledge workers already using AI tools and 78% bringing their own, according to ConductorOne. The governing issue is not just access speed but whether identity controls can preserve visibility, auditability, and lifecycle control as AI tools, agents, and MCP connections spread.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 75% of knowledge workers use AI tools today, and 78% bring their own, creating massive shadow AI risk.
- Only 18% of employees know their company’s AI policy.
Questions worth separating out
Q: How should security teams govern AI tool access without creating shadow AI risk?
A: Security teams should make governed access faster than the ungoverned path, while preserving approval, logging, and revocation.
Q: Why do AI tools and agents change IAM governance requirements?
A: AI tools and agents change governance because they can act repeatedly, chain actions, and consume credentials in ways that traditional user-centric IAM does not model well.
Q: What breaks when AI agents are not treated as governed identities?
A: When AI agents are not treated as governed identities, they become opaque access objects with no clear owner, approval history, or revocation path.
Practitioner guidance
- Map every AI access path to an identity owner Assign a human owner, approval path, and revocation path to each AI tool, assistant, agent, and MCP connection before it is allowed into production workflows.
- Separate governed AI access from ad hoc user enrolment Route requests through a single approval workflow so that sanctioned access is faster than shadow access, while preserving visibility into who requested what and why.
- Apply per-call authorization to AI tool use Check each tool invocation against policy, record the identity context, and retain audit detail that can support access certification and incident review.
What's in the full announcement
ConductorOne's full product announcement covers the operational detail this post intentionally leaves for the source:
- How self-service AI access requests are routed through policy-based auto-approval or human approval
- How fine-grained tool-call logging is structured for audit, compliance evidence, and access certification
- How agent credentials are vaulted, rotated, and revoked across the AI access lifecycle
- How the 3,000+ hosted MCP server model maps applications into governed access paths
👉 Read ConductorOne's announcement on AI Access Management for enterprise AI adoption →
AI access management for enterprise AI adoption: what changes now?
Explore further
AI access governance is becoming a control-plane problem, not a user-experience problem. The article shows that the bottleneck is no longer whether employees can find AI tools, but whether the governed path is faster than the shadow path. That changes the identity conversation from convenience to enforceable control over who or what can call AI services, agents, and MCP links. Practitioners should treat AI access as a governed entitlement layer rather than a productivity feature.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often governance stops at partial inventory.
A question worth separating out:
Q: What should organisations review before connecting AI systems to MCP servers?
A: Organisations should review which AI system is allowed to call which MCP server, what data it can reach, and how those calls are logged. MCP connections should be treated as privileged entitlements, not simple integrations, because they extend identity-bearing access into downstream tools and data sources.
👉 Read our full editorial: AI access management redefines governance for enterprise AI adoption