AI governance challenges expose the gap between adoption and control

At a glance

What this is: This guide argues that enterprise AI governance is failing because ownership, visibility, and enforcement have not caught up with AI adoption.

Why it matters: It matters to IAM practitioners because the same accountability and control gaps that weaken human identity programmes now also affect AI use, shadow AI, and agentic access.

By the numbers:

• 88% of organizations report regular use of AI in at least one business function.
• 78% of employees admit to using AI tools that their employer has not approved.
• 98% of organizations have a relationship with at least one third-party vendor that experienced a breach in the last two years.

👉 Read WitnessAI's guide to the six enterprise AI governance challenges

Context

Enterprise AI governance is the set of decisions, controls, and accountability paths that determine who can use AI, for what purpose, and under what oversight. The first problem is not technical sophistication, but ownership: when security, legal, compliance, HR, and business teams each hold part of the responsibility, enforcement often disappears between functions.

The result is predictable. Adoption moves faster than policy, shadow AI spreads into unmanaged workflows, and traditional security tooling cannot reliably inspect conversational intent or AI-native traffic. For identity teams, this is the same old governance problem showing up in a new actor class, only now the blast radius includes models, prompts, agents, and downstream data handling.

Key questions

Q: How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?

A: Organisations should create one enforced AI governance path with explicit decision rights, not a loose committee structure. Each function can contribute policy and risk input, but one owner must be able to approve, block, and track exceptions. Without that, accountability is fragmented and policies remain aspirational.

Q: Why do legacy security tools struggle to control AI-related data exposure?

A: Legacy tools were built for files, patterns, and known application flows, while AI risk often lives in prompts, responses, and session context. That means keyword-based DLP and delayed API monitoring miss the meaningful part of the interaction. Security teams need controls that understand intent and inspect bidirectional AI traffic.

Q: What breaks when AI agents are treated like normal human users in governance programmes?

A: Human-centric governance assumes access is stable enough to review later and that authorisation is tied to a person’s session and behaviour. AI agents can act with inherited credentials, call tools, and chain actions in ways that do not fit those review cycles. Identity teams need separate runtime authority and audit trails for agents.

Q: How do security teams reduce shadow AI risk without blocking all AI adoption?

A: Start by discovering what is actually in use across browser tools, desktop apps, IDEs, and embedded copilots. Then classify usage by risk and intent, and apply policy choices such as allow, warn, block, or route to approved models. Visibility first, enforcement second, so governance follows real behaviour.

Technical breakdown

Cross-functional AI governance and enforcement failure

AI governance breaks when decision rights are split across teams but no single function can approve, block, or continuously enforce policy. In practice, that produces paper controls, fragmented risk reviews, and stalled deployment paths. A tiered governance model can help, but only if it has executive sponsorship, dedicated funding, and operational authority. Without those, the structure becomes advisory rather than enforceable, which means risk remains unmanaged even when policies exist.

Practical implication: define a single enforcement owner for AI risk decisions and make every other team a contributor, not a veto point.

Why legacy DLP, CASB, and endpoint tools miss AI risk

Legacy security tools were built around files, keywords, and predictable application flows. Conversational AI changes the unit of risk from a document to an interaction, where meaning, context, and cumulative leakage matter more than a single flagged term. That is why keyword-based DLP misses prompt abuse, and why API-driven CASB monitoring often arrives too late to stop exposure in real time. AI-native controls need intent-based classification, bidirectional visibility, and policy enforcement that can react during the session, not after it ends.

Practical implication: evaluate whether current controls inspect prompts, responses, and session context before assuming they can govern AI use.

Agentic AI governance and credential sprawl

Agentic AI changes the identity problem because the actor can call APIs, query systems, and execute workflows using inherited credentials with minimal human oversight. That shifts the risk from user misuse to machine decision-making, where tokens, API keys, and service credentials proliferate quickly and can outlive their intended scope. This is where AI governance intersects with NHI discipline: the programme must account for machine credentials, runtime attribution, and the fact that traditional session-based IAM assumes a human-paced control loop. For autonomous behaviour, that assumption no longer holds.

Practical implication: inventory agent identities and their credentials separately from human accounts, then tie each to explicit runtime authority and auditability.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

AI governance is now an identity governance problem, not just a policy problem. When enterprises cannot say who owns enforcement, they also cannot say who is accountable for access, data movement, or policy exceptions. That is the same structural failure IAM teams already see when governance exists only in documents and committees. The practical conclusion is that AI governance must be managed like an identity programme with enforceable ownership, not a loose compliance overlay.

Legacy controls fail because they were designed for documents and sessions, not conversational intent. DLP, CASB, and endpoint tooling all assume the observable unit is a file, an event, or a known SaaS flow. AI use breaks that assumption because risk appears across prompts, responses, and multi-turn context. For security architects, this means the control boundary has shifted from the endpoint to the interaction itself.

Agentic AI creates a governance assumption collapse around predictable human-paced access. Least privilege was designed for actors whose intent is known at provisioning time and whose access can be reviewed later. That assumption fails when the actor is autonomous because it can select tools, chain actions, and consume credentials during execution without waiting for approval. The implication is not merely a stronger control set, but a redesign of how entitlement, timing, and accountability are defined for digital workers.

Runtime governance gap: AI programmes fail when policy is enforced after the interaction instead of during it. That gap matters because AI risk is often instantaneous and cumulative, which makes retrospective review too late to prevent data exposure or unauthorised actions. The field should treat runtime enforcement as the baseline, not the advanced option.

AI supply-chain governance must extend to vendor data handling and third-party model use. Organisations cannot rely on annual questionnaires when embedded AI services can process sensitive data continuously. The governance issue is not only contractual disclosure, but the ability to see where data goes and whether that use aligns with internal policy. Practitioners should treat third-party AI as part of the identity and data perimeter, not as an external footnote.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity governance fails when inventory is incomplete.
• For the lifecycle angle, the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next step when you need offboarding, rotation, and revocation discipline.

What this signals

Enterprises that want to govern AI well need to treat runtime visibility as a prerequisite, not an enhancement. Shadow AI, agentic access, and vendor AI all expand the attack surface faster than policy cycles can absorb it, which makes discovery and enforcement inseparable. The practical signal is that AI governance now belongs in the same operational conversation as identity, data, and access control, not in a separate innovation track.

Intent-based control is the emerging design pattern for AI governance because risk is expressed through meaning, not just movement. If a control cannot inspect prompts, responses, and session context, it cannot reliably distinguish normal use from risky use. For security teams, that means the programme must shift from blocklists and static policy to continuous classification and enforcement, aligned with the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework.

The biggest programme risk is not that AI will appear suddenly, but that it will appear everywhere at once. Once employees, vendors, and agents all use AI in parallel, governance needs a shared control model that can handle human users, machine identities, and autonomous actors without fragmenting into separate exceptions. That is where identity architecture and AI security converge.

For practitioners

• Assign one accountable AI governance owner Create a decision-making path that lets one named function approve, block, or escalate AI use cases. Keep legal, compliance, HR, and security involved, but remove ambiguity about who enforces the final decision. Use an executive sponsor to prevent committee drift.
• Map AI controls to conversational risk, not file risk Review whether your current DLP, CASB, and endpoint stack can inspect prompts, responses, and multi-turn context. If it cannot classify intent or inspect bidirectional AI traffic, it is not sufficient for AI governance.
• Discover shadow AI across all user surfaces Build discovery that covers browser tools, native desktop apps, IDEs, embedded copilots, and model access that bypasses browser-only monitoring. Network-level visibility should produce a live inventory before policy decisions are made. See the Ultimate Guide to NHIs , Key Challenges and Risks for the related visibility problem in machine identity programmes.
• Separate agent credentials from human access reviews Treat AI agents as distinct identity subjects with their own credentials, runtime permissions, and audit trails. Do not fold them into human review cycles, because their usage patterns and timing do not match human-centric recertification models. The Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is useful background on lifecycle thinking here.
• Extend third-party risk reviews to AI data handling Ask vendors whether customer data is used to train models, where data is processed, and which third-party AI services they embed. Then verify those answers at runtime, not just at contract renewal, because AI exposure can occur continuously.

Key takeaways

• AI governance fails when ownership is split across functions but enforcement is not owned by anyone.
• Legacy security tools cannot reliably govern conversational AI because they were built for files and fixed application flows.
• Agentic AI turns governance into an identity problem, because runtime authority and credential scope matter more than static approvals.

Key terms

• AI governance: AI governance is the set of policies, controls, and decision rights that determine how AI may be used, by whom, and under what oversight. In practice, it becomes effective only when enforcement, auditability, and accountability are assigned to a single operational owner rather than spread across disconnected teams.
• Shadow AI: Shadow AI is the use of AI tools, models, or copilots outside sanctioned governance paths. It creates risk because the organisation cannot reliably see what data is shared, which models are used, or whether the activity aligns with policy and legal obligations.
• Intent-based control: Intent-based control is a security approach that evaluates what a user or system is trying to do, not just what data appears on the wire. For AI, this matters because prompts and responses can expose risk through context and meaning even when no obvious keyword or file transfer exists.
• Agent identity: Agent identity is the set of credentials, permissions, and audit records that distinguish an AI agent from a human user or generic service account. When agents can act at runtime, identity must cover tool access, execution authority, and traceability across every action the agent takes.

Deepen your knowledge

AI governance ownership, intent-based enforcement, and agent identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI and digital worker use cases, it is worth exploring.

This post draws on content published by WitnessAI: AI governance challenges are now the defining risk category for enterprises scaling AI. Read the original.