AI adoption gap exposes enterprise data risk in agentic workflows

At a glance

What this is: This is a data-driven report on how enterprise AI adoption, agent use, and sensitive data exposure are accelerating faster than security governance can adapt.

Why it matters: It matters because IAM, data security, and AI governance teams now need visibility into who and what is interacting with sensitive data across human users, tools, and AI agents.

By the numbers:

• Frontier organizations are now utilizing over 300 GenAI tools, adopting them at nearly 6x the rate of the average company.
• 39.7% of all AI interactions involve sensitive data, meaning the average employee inputs proprietary information into AI once every three days.
• 82% of the top 100 most-used GenAI SaaS applications are classified as medium to critical risk.
• 23% of enterprises have already adopted agent-building platforms to create custom workflows.

👉 Read Cyberhaven’s 2026 AI Adoption & Risk Report on AI agents and data security

Context

Enterprise AI adoption has moved from experimentation into routine business execution, which means the security problem is now access, data handling, and governance rather than curiosity. When employees use hundreds of GenAI tools and agents in parallel, the central question becomes which identities, datasets, and workflows are actually under policy control. In identity terms, the issue is not just user authentication but the expanding surface of human, machine, and agentic access.

Cyberhaven’s report frames this as an adoption gap: usage rises faster than oversight, and sensitive data is already flowing through everyday AI interactions. That creates a direct governance challenge for IAM, DLP, and AI security programmes because policy cannot rely on tool-by-tool exception handling once AI becomes embedded in normal work. The starting position described here is increasingly typical for frontier enterprises, not an outlier.

The most useful NHIMG lens is to treat AI tools and agents as part of the broader identity estate. That makes access scoping, data minimisation, and auditability the practical controls that matter, alongside the broader guidance in the OWASP Agentic AI Top 10 and the OWASP NHI Top 10.

Key questions

Q: How should security teams govern AI use in developer tooling?

A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.

Q: Why do personal AI accounts create so much risk in enterprise environments?

A: Personal accounts bypass enterprise identity controls, so security teams lose visibility into who authorised access, what scopes were granted, and whether the session can be revoked. They also separate the data trail from the user’s corporate identity, which makes investigation, containment, and audit evidence much harder.

Q: What do security teams get wrong about AI agent identity governance?

A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Technical breakdown

Why the AI adoption gap creates governance blind spots

The adoption gap appears when business teams expand AI usage faster than security and compliance can inventory it. That matters because tool proliferation creates fragmented data paths, inconsistent authentication, and unclear responsibility for what content is entered into or returned from AI systems. Once employees use personal accounts, specialised assistants, and agent-building platforms in the same environment, policy enforcement becomes conditional rather than uniform. The security issue is not AI itself, but the loss of control over where sensitive data travels and which identities can move it.

Practical implication: inventory AI access paths before you try to govern use cases.

How sensitive data moves through agentic and assistant workflows

AI assistants and agents often sit between the user and the data source, which means they inherit trust the user did not explicitly grant. In practice, that can expose proprietary content through prompts, context windows, logs, plugins, and downstream automations. If the workflow includes coding assistants or agent-building platforms, the data flow extends beyond a single conversation into repositories, tickets, and execution environments. This is why AI governance increasingly overlaps with data security posture and identity controls rather than sitting apart from them.

Practical implication: classify prompts, outputs, and connected tools as governed data flows, not informal productivity traffic.

Why personal accounts and unmanaged tool access matter

When employees access enterprise AI through personal accounts, the organisation loses lifecycle control, audit continuity, and sometimes contractual visibility. That is a familiar identity problem in a new form: the access path exists outside corporate IAM, so revocation, logging, and entitlement review become incomplete. For AI tools, this is especially risky because the same account may bridge multiple services and models, creating hidden persistence across sessions and vendors. Governance has to start with identity binding, not after-the-fact content inspection.

Practical implication: require identity-bound access and separate personal use from governed enterprise workflows.

Threat narrative

Attacker objective: The objective is to gain or amplify access to valuable corporate data through trusted AI workflows, then use that exposure for exfiltration, misuse, or operational advantage.

1. Entry occurs when employees adopt AI tools through sanctioned channels, personal accounts, or agent-building platforms that extend enterprise data access beyond core IAM visibility.
2. Escalation follows when assistants, coding tools, or agents inherit permissions that let them read, summarise, move, or transform sensitive corporate data across workflows.
3. Impact appears as sensitive data exposure, policy drift, and incomplete auditability, which makes compliance, incident response, and breach investigation materially harder.

NHI Mgmt Group analysis

AI adoption has outpaced identity governance, and that is now the core enterprise risk. The report shows a shift from experimentation to normalised operational use, which means unmanaged AI access is no longer a pilot problem. Once hundreds of tools sit alongside human users, the identity estate becomes hybrid by default. Practitioners should treat AI governance as an IAM and data security issue, not a standalone innovation programme.

Sensitive data flowing through AI systems creates a new form of governance debt. When nearly 40% of AI interactions contain sensitive content, the organisation is accumulating unreviewed risk in everyday workflows. That risk is not only leakage, but also policy ambiguity about retention, logging, and downstream reuse. Adoption drift: the gap between who can use AI and who can govern it becomes a durable control failure. Teams should close that gap before it turns into institutional blind spot.

Personal accounts are an identity boundary failure, not just a usage preference. If workers interact with AI through unmanaged identities, revocation and audit become partial by design. That means the organisation cannot reliably answer who accessed what, when, and through which model or agent. Practitioners should align AI access policy with IAM lifecycle controls, because identity binding is the difference between governable use and shadow AI.

Agent-building platforms are turning AI from content consumption into delegated action. That changes the risk from read-only exposure to workflow execution and cross-system movement. In security terms, the relevant question is no longer only what the model knows, but what the agent can reach. Teams should map these environments to OWASP Agentic AI Top 10 and OWASP NHI Top 10 thinking, because tool access and identity trust now intersect directly.

What this signals

Adoption without identity binding will keep producing shadow AI. As AI tools become routine, the operational question shifts to whether each workflow is tied to a managed identity, an owner, and a revocation path. If not, security teams will keep discovering usage after the fact instead of governing it prospectively. The control objective is visibility before policy enforcement, not forensic recovery after exposure.

Agentic workflows collapse the line between data access and action. Once an assistant can not only read content but also trigger downstream systems, the risk profile resembles delegated privilege rather than simple software use. That means teams need to assess agent permissions with the same seriousness they apply to service accounts and other non-human identities. For reader programmes, this is where IAM, DLP, and AI governance converge.

The clearest signal for practitioners is whether the organisation can explain AI access in identity terms, not just in application terms. If inventory, logging, and offboarding do not cover AI accounts, the programme is already behind the operating model. The next step is to make AI usage measurable against the same lifecycle controls used for other governed identities.

For practitioners

• Inventory AI tools and agent platforms by identity path Build a register of sanctioned and unsanctioned AI services, noting whether access occurs through corporate SSO, personal accounts, browser extensions, or embedded agents. Map each path to the data classes it can reach and the business owner responsible for approval.
• Bind enterprise AI use to managed identities Require SSO, explicit tenancy controls, and lifecycle-managed accounts for any AI system that can touch corporate data. Remove dependence on personal accounts wherever prompts, outputs, or agent actions could affect confidential information.
• Classify AI prompts and outputs as governed data flows Extend DLP, retention, and logging policies to prompts, responses, and downstream artefacts such as code, tickets, and summaries. This is especially important where coding assistants or agent-building platforms can move data into other systems.
• Review agent permissions against least-privilege boundaries For AI agents that can take actions, document the exact systems they can reach, the credentials they inherit, and the conditions under which access is revoked. Cross-check against the OWASP Agentic AI Top 10 and the OWASP NHI Top 10.

Key takeaways

• The central risk is not AI experimentation but uncontrolled operational use across hundreds of tools and workflows.
• Cyberhaven’s data shows sensitive information is already moving through AI at scale, which turns governance into a data and identity problem rather than a policy exercise.
• Enterprises should anchor AI access to managed identities, auditability, and least-privilege boundaries before agentic use becomes the default operating model.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• 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.
• Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full report

Cyberhaven's full report covers the operational detail this post intentionally leaves for the source:

• Detailed breakdowns of AI tool adoption by sector, including which industries are adopting fastest.
• The underlying dataset from 222 companies and how real-world data movements were measured.
• Examples of how code assistants and agent-building platforms change enterprise risk in practice.
• The report’s full risk classification approach for the top GenAI SaaS applications.

👉 Cyberhaven’s full report includes sector-level adoption patterns, risk classifications, and the underlying data methodology.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to emerging AI and automation risk.