AI governance’s blind spot is identity, not model quality

At a glance

What this is: This is an analysis of why enterprise AI adoption is being undermined by identity and governance gaps, with shadow AI emerging when governed access is too hard to use.

Why it matters: It matters because IAM teams now need to govern AI agents, MCP connections, and human access paths together, or employees will bypass controls and create unmanaged AI risk.

By the numbers:

• 75% of knowledge workers are already using AI tools.
• 78% are bringing their own.
• Only 18% know their company's AI policy.

👉 Read ConductorOne's analysis of the AI governance gap and shadow AI

Context

AI governance is the discipline of deciding which people, agents, and tools can access which data and actions, under what policy, and with what oversight. In this case, the primary problem is not AI capability but the gap between enterprise control design and how quickly employees can adopt AI outside those controls.

The article shows a familiar identity pattern: when the governed path is slower than the ungoverned path, users route around it. That creates shadow AI, where access is unmanaged, approvals are bypassed, and sensitive data can move into tools that were never intended to hold it.

Key questions

Q: How should security teams stop employees from bypassing governed AI access?

A: Make the approved path faster than the bypass path. If requesting access to a sanctioned AI tool takes days while a free-tier sign-up takes minutes, users will route around policy. The practical fix is to automate low-risk approvals, shorten provisioning, and attach identity-aware controls so the legitimate workflow is the easiest one to use.

Q: Why do AI tools create identity governance problems for IAM teams?

A: Because AI tools introduce new identities, delegated permissions, and tool-call decisions that must be governed like other access objects. The issue is not only who can log in, but which data, tools, and actions an AI identity can reach at runtime. That expands IAM from application access to policy enforcement across the action chain.

Q: What breaks when organisations treat AI governance as a separate security program?

A: They usually create a second control plane that cannot keep pace with real usage. That leads to duplicated approvals, weak audit coverage, and unmanaged tool connections outside the identity system of record. AI governance works best when it extends identity infrastructure instead of sitting beside it.

Q: How do you know if AI access governance is actually working?

A: Look for three signals: users request access through the sanctioned path, approvals complete quickly enough to prevent bypass, and every tool call is tied to a specific identity and audit event. If employees still prefer external tools, governance is too slow or too hard to use.

Technical breakdown

Why shadow AI emerges when governed access is too slow

Shadow AI appears when legitimate access requires too many manual steps, too much back-and-forth, or too much technical knowledge for the requester. In identity terms, the control problem is not absence of policy, but enforcement latency. If a user can reach a free-tier tool faster than they can get approved access, the security model is already losing. Governance has to operate at the speed of adoption, or it becomes optional in practice.

Practical implication: measure request-to-access time for AI tools and treat long provisioning paths as a control failure, not a user convenience issue.

AI agent identities, MCP access, and policy enforcement

The article’s core technical point is that AI access is not just application access. Agents may connect through MCP servers, call tools, and use delegated permissions to act on a user’s behalf. That means the identity layer has to authenticate the actor, evaluate policy at the tool level, and record audit events for each call. Traditional IGA can manage human application access, but it was not built to govern agent-to-tool authorisation or prompt-time data access.

Practical implication: define tool-level entitlements for AI access and require policy enforcement at the point of each call, not only at provisioning.

Why delegated consent changes the governance model

The article distinguishes between low-risk actions and privileged operations that need step-up approval. That is the right governance split because AI access is not binary. A user-scoped assistant may be allowed to read analytics data, but it should not be able to delete resources or rotate credentials without real-time confirmation. This is an identity governance problem because the decision is about who can authorise which action in which context, not about the model itself.

Practical implication: map AI actions into risk tiers and require explicit approval for privileged operations, especially when the action changes data, access, or system state.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is a control-plane failure, not an adoption side effect. The article shows that employees bypass governed access when the approved path is slower than self-service sign-up. That is a governance breakdown, because policy without usable enforcement simply creates parallel, unmanaged identities and tool connections. The implication is that identity teams must treat AI access speed as part of the control design, not as a separate UX problem.

AI governance is identity governance with a new actor type. Agents need identities, credentials, policies, lifecycle states, and audit trails just like humans and service accounts do. The difference is that they also introduce tool-call permissions, delegated authority, and runtime enforcement requirements. Existing IGA models can be extended, but only if teams stop treating AI access as an adjacent technology problem. Practitioners should place AI governance inside the identity control plane.

Policy-based access for AI only works when the governed path is faster than the bypass path. That principle reframes AI governance from access restriction to adoption shaping. If employees can get to an ungoverned tool in minutes and an approved tool in days, security policy will lose regardless of its quality. The field needs to measure time-to-governed-use as a first-class identity metric.

Agent identity management must separate personal assistants from enterprise agents. The article correctly distinguishes user-scoped assistants from organisation-scoped automation. Those are different governance objects with different ownership, review cycles, and privilege boundaries. Conflating them creates lifecycle confusion and audit gaps. Practitioners should classify AI identities by delegation model before assigning controls.

Governance for AI tools now depends on the identity blast radius created by delegated consent. Identity blast radius: the amount of data, tools, and privileged action an AI identity can reach before a human re-enters the decision loop. The more broadly an assistant can act on behalf of a user, the more quickly a small access decision becomes an enterprise exposure. Teams should treat that blast radius as a design constraint, not a post-incident metric.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly unmanaged identity exposure becomes systemic.
• For the broader lifecycle view, Ultimate Guide to NHIs frames visibility, rotation, and offboarding as the controls that keep identity governance enforceable.

What this signals

Shadow AI will keep growing until AI access becomes faster than personal workarounds. That is a governance design issue, not a policy awareness issue. IAM and security teams should expect demand for self-service provisioning, automated approvals, and identity-aware proxying to become standard expectations rather than advanced capabilities.

Agent identity management is moving from experiment to operating model. As organisations connect assistants to MCP servers and data sources, the question becomes who owns the identity, who certifies the access, and how quickly privileged actions can be revoked. Teams that already manage service accounts and delegated access can adapt faster than teams starting from scratch.

The strongest signal from this article is that identity programmes now need a measurable adoption path, not just a control catalogue. If employees cannot use AI securely in under a few minutes, the organisation is effectively paying for policy that is easier to bypass than to follow.

For practitioners

• Measure time-to-governed-access for AI tools Track how long it takes a non-technical employee to request, approve, and use an AI tool through the sanctioned path. If the approved path takes longer than self-service sign-up, redesign the workflow before users build their own shadow AI path.
• Define tool-level entitlements for AI identities List the exact tools, data sources, and parameters an AI identity may use, then apply policy checks at each call. Do not stop at application-level access grants if the real risk sits inside MCP connections or delegated tool usage.
• Split personal assistants from enterprise agents Assign different ownership, approval, and lifecycle rules to user-scoped assistants and organisation-scoped automation. Review their permissions separately so that a personal productivity assistant does not inherit enterprise-grade privileges by default.
• Tier privileged AI actions by business risk Classify actions such as reading analytics, changing records, deleting resources, and rotating credentials into separate approval tiers. Require real-time human confirmation for actions that change state, exposure, or access.

Key takeaways

• Enterprise AI governance fails when the sanctioned path is slower than shadow AI, because users choose the easiest workable route.
• The scale problem is already visible, with only 18% of workers knowing the AI policy and most users adopting AI tools independently.
• Identity teams should govern AI through the same control plane they use for access, but with tool-level policy, delegated consent, and faster provisioning.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, agents, or connected services outside approved governance. It usually appears when the sanctioned path is too slow, too technical, or too restrictive, causing employees to create unmanaged access paths that security teams cannot see, certify, or revoke in time.
• Agent Identity: Agent identity is the identity assigned to an AI system so it can authenticate, receive policy, and perform actions on behalf of a user or organisation. In practice, it requires ownership, lifecycle control, delegated permissions, and auditability, because the agent is not just software but a governed actor.
• Delegated Consent: Delegated consent is permission granted to an identity to act within defined boundaries on behalf of another principal. For AI, it matters because an assistant may be allowed to read, recommend, or execute certain tasks while higher-risk actions still require real-time human approval before completion.
• Identity Blast Radius: Identity blast radius is the amount of data, tools, and privileged action an identity can reach before a control stops it. For AI and NHI governance, the concept helps teams evaluate how far a single access decision can spread across systems, especially when delegation and automation widen the impact.

Deepen your knowledge

AI governance, delegated consent, and agent identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to extend identity governance into AI adoption, it is a practical place to start.

This post draws on content published by ConductorOne: Your AI Strategy Has a Blind Spot. Read the original.