Enterprise GenAI adoption is stalled by governance gaps

At a glance

What this is: This is an analysis of why enterprise GenAI adoption is slowing, with governance maturity and trust emerging as the main blockers.

Why it matters: It matters because AI adoption now sits inside IAM, data governance, and risk programmes, where access, oversight, and accountability need to work together rather than in silos.

By the numbers:

• only 7% of enterprise adopters had fully embedded governance programs with continuous KPI monitoring
• enterprise adoption rates jumped from 55% in 2023 to 75% in 2024
• only 46% of users are willing to trust AI

👉 Read Knostic's analysis of enterprise GenAI adoption and governance gaps

Context

Enterprise GenAI adoption is the process of moving generative AI from pilots into business workflows with enough governance to manage access, output quality, and regulatory exposure. The central problem is not whether the technology works, but whether organisations can control what it sees, what it reveals, and who is accountable when it acts on sensitive knowledge.

Knostic argues that most enterprises are still treating AI adoption as a tooling exercise when it is really an identity and governance problem. That means the programme has to connect personas, policy, monitoring, and lifecycle controls in the same operating model, especially where AI outputs can expose information beyond the user’s intended scope.

The article's starting position is typical rather than exceptional: enterprises are advancing faster than their controls, and the gap is now visible across regulated sectors, operating teams, and executive oversight.

Key questions

Q: How should security teams govern GenAI access to sensitive business knowledge?

A: Security teams should govern GenAI access by mapping personas, tasks, and data classes to explicit policy boundaries. The goal is not only to restrict retrieval, but also to prevent AI systems from inferring or exposing information beyond the user’s intended scope. That requires IAM, data governance, and monitoring to operate as one control set.

Q: Why do traditional IAM controls fall short for enterprise AI adoption?

A: Traditional IAM controls fall short because they were built around direct access to applications and data, not inference-driven exposure. GenAI can combine fragments from multiple sources and reveal sensitive context without a direct entitlement breach. Organisations therefore need controls for what can be inferred, not just what can be opened.

Q: How can organisations know if AI governance is actually working?

A: They can measure whether AI governance is working by tracking oversharing, blocked prompts, hallucination frequency, and how often outputs stay inside the approved persona and data boundary. If those signals are not being monitored continuously, governance is probably reactive rather than operational.

Q: What should teams do before putting GenAI into production?

A: Teams should validate the use case in an internal sandbox using masked or synthetic data, then test retrieval scope, output handling, and exception workflows before granting production access. Production should begin only after the team can show that the model stays within policy under realistic conditions.

Technical breakdown

Why persona-based access controls matter for GenAI

Persona-based access controls limit what a user can infer from an AI system based on role, task, and context, not just a static entitlement. In GenAI environments, the main risk is not only direct data retrieval but also inference, where the model combines fragments into sensitive answers that the requester was never supposed to assemble. That makes access control a knowledge-layer problem, not just a data-layer one. Traditional RBAC often lacks enough context to manage prompt-driven access safely, especially when business context changes by session.

Practical implication: align AI access policy to task context and persona, not only to the user account or application.

What continuous monitoring needs to measure in AI workflows

Continuous monitoring for GenAI must track prompt safety, oversharing events, hallucination frequency, and the business context in which outputs were generated. These signals are useful because AI risk is dynamic: a model can behave acceptably in one workflow and become unsafe in another once different data, users, or permissions are introduced. Monitoring also creates auditability, which matters when teams need to explain why a particular answer was surfaced or blocked. Without traceability, governance becomes an assertion rather than a control.

Practical implication: instrument AI workflows with logging and exception detection that can be reviewed by security, compliance, and operations.

How internal sandboxes reduce GenAI governance risk

Internal sandboxes let teams test GenAI use cases with masked or synthetic data before exposing production systems or regulated data. This matters because many AI failures show up in the interaction layer, where prompts, retrieved context, and output policies combine in ways traditional test environments do not simulate well. A sandbox is not just a technical enclosure; it is a governance model that helps teams validate acceptable use, measure leakage risk, and define approval boundaries before rollout.

Practical implication: require sandboxed validation before production access is granted to any AI workflow that can touch sensitive information.

Threat narrative

Attacker objective: The objective is to obtain sensitive information or operational advantage through AI-generated overexposure rather than through direct system compromise.

1. Entry occurs when GenAI is introduced into business workflows with broad or poorly scoped access to enterprise knowledge sources.
2. Escalation happens when the system infers, combines, or surfaces information beyond what the requesting user should see, turning valid access into overexposure.
3. Impact is realised through leakage of sensitive data, compliance exposure, or loss of trust in the AI programme itself.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Microsoft Azure OpenAI service breach — stolen Azure API keys used to bypass AI safety controls at scale.

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

NHI Mgmt Group analysis

Governance failure, not model failure, is the real adoption bottleneck. The article's core evidence points to a familiar pattern in identity security: enterprises can deploy AI faster than they can govern access to it. That means the decision problem is no longer whether GenAI is technically viable, but whether the organisation can control inference, output, and accountability at scale. Practitioners should treat GenAI rollout as a governance programme with identity controls attached, not the other way around.

Knowledge-layer access is the missing control plane for enterprise AI. The most important risk described here is that users may receive answers they were never directly entitled to assemble from disparate sources. That breaks the assumption that access control ends at retrieval. The practical implication is that IAM, data classification, and AI policy must converge around what a user can infer, not just what they can open.

Internal sandboxes are a governance pattern, not a compliance checkbox. The article is right to emphasise controlled environments, but the deeper point is that AI deployment needs pre-production evidence about leakage, persona behaviour, and policy fit. This is where regulated enterprises can move from hope to measurement. Practitioners should use sandboxes to prove boundary conditions before expanding access to production data.

Continuous monitoring must extend into AI output governance. Static approvals do not tell you whether a model is oversharing today, with this user, in this workflow. The governance model has to detect drift in real time, because the same assistant can be safe in one context and unsafe in another. Practitioners should reframe monitoring as an always-on identity and content control problem, not a post-incident review exercise.

Enterprise AI maturity now depends on cross-functional identity stewardship. The article's discussion of steering committees, compliance, and DevOps is a reminder that AI governance fails when ownership is fragmented. Adoption programmes need a single operating model that connects policy, access, monitoring, and exception handling. Practitioners should expect AI governance to become part of identity governance rather than a separate innovation track.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• A separate finding shows that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which is why policy scope matters as much as model quality.
• For a deeper governance angle, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the access, rotation, and offboarding controls that shape machine identity programmes.

What this signals

Enterprise GenAI programmes are now being judged on governance readiness, not pilot count. With only 7% of organisations reporting fully embedded governance programmes, the practical question is whether security teams can prove that access, output, and review controls exist before broader rollout. That is becoming a board-level adoption constraint, not a niche control issue.

Knowledge inference has become an identity problem. The control boundary is no longer the repository alone, because AI systems can reveal information by combining context that no individual user explicitly requested. Teams should expect persona-based controls, monitoring, and exception handling to move closer to the centre of IAM operating models.

As the article implies, AI adoption will increasingly mirror NHI governance maturity. The same organisational patterns that govern service accounts, workload identity, and lifecycle review now need to be adapted for GenAI use cases. For practitioners, that means the maturity test is whether controls can keep up with dynamic access, not just whether a model is deployed.

For practitioners

• Define AI personas and access boundaries Map each GenAI use case to the persona, task, and data classes it may touch. Use those mappings to set policy before deployment, especially where prompts can reach regulated or confidential knowledge.
• Build a sandbox-first rollout model Require synthetic or masked data in internal sandboxes before any GenAI workflow reaches production systems. Validate prompt behaviour, retrieval scope, and output leakage in the sandbox, then approve only the narrowest viable access.
• Instrument AI monitoring for oversharing Log prompts, retrieved context, blocked outputs, and exception paths so security and compliance can review where the model exceeded expected boundaries. Treat hallucination and oversharing metrics as governance signals, not just model quality indicators.
• Align AI governance to IAM ownership Assign clear accountability across identity, security, data, and platform teams so AI policy does not sit outside normal governance processes. Fold approvals, reviews, and exception handling into the same operating rhythm used for other access controls.

Key takeaways

• Enterprise GenAI adoption is being slowed by governance gaps, trust deficits, and regulatory complexity more than by model capability.
• The article's strongest signal is that only 7% of enterprises have embedded governance programmes, which makes oversight maturity the real bottleneck.
• Practitioners need sandboxes, continuous monitoring, and persona-aware policy if they want AI adoption to scale without widening exposure.

Key terms

• Persona-based access control: A policy approach that limits what an AI system can reveal or do based on the user’s role, task, and context. It goes beyond static permissions by shaping outputs according to the business situation, which is critical when AI can infer sensitive knowledge from multiple sources.
• Knowledge-layer security: Controls that govern what an AI system can infer, assemble, or disclose from enterprise content. Unlike traditional data access control, knowledge-layer security focuses on the output path, where valid retrieval can still produce unsafe or overbroad answers.
• AI sandbox: A controlled environment where teams test AI use cases with masked or synthetic data before production exposure. It lets organisations evaluate leakage, policy fit, and workflow behaviour without placing regulated or sensitive information at immediate risk.
• Continuous monitoring: An always-on oversight practice that tracks AI behaviour, outputs, and exceptions over time. In GenAI programmes, it is used to detect oversharing, hallucinations, and policy drift before they become operational or compliance incidents.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• Prompt simulation examples that show how oversharing appears in enterprise AI workflows.
• A deeper walkthrough of continuous monitoring metrics for hallucination, leakage, and control drift.
• Practical examples of persona-based access controls in Microsoft 365 and Glean environments.
• Benchmarks and adoption metrics that teams can use for internal rollout planning.

👉 Knostic's full post covers sandboxes, monitoring, and rollout metrics for GenAI adoption.

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 IAM programme, it is worth exploring.