Home > Security and Compliance Blog > Cybersecurity Risk Management > Why the Shadow AI Identity Gap Is the Real Enterprise Risk in 2026

Why the Shadow AI Identity Gap Is the Real Enterprise Risk in 2026

by Patrick Spencer updated August 26, 2026 Cybersecurity Risk Management

Reading Time: 10 minutes

Nearly half of all enterprise AI activity now happens through identities your security team cannot see, cannot audit, and cannot produce evidence for when a regulator asks. That is the finding sitting at the center of Akamai’s new State of the Internet report on enterprise AI usage risk, and it should reframe how every CISO and compliance officer thinks about AI governance heading into 2026.

For the past two years, most enterprise AI security programs have organized themselves around a single question. Who is allowed to access which AI tool? That question produced allowlists, single sign-on requirements, and app-approval workflows. Akamai’s report, built on telemetry from its LayerX platform (acquired by Akamai), argues that this question is now the wrong one. The defining enterprise AI risk in 2026 is not who accesses AI, it is who shares sensitive business data with AI, and through which identity that data leaves the building.

Table of Contents

That distinction matters because AI does not move data the way traditional data loss prevention tools were built to watch. Email, file transfer, and upload channels are well defined and inspectable. AI interactions are not. Sensitive information gets fragmented across prompts, conversational context, pasted code, screenshots, and generated responses, each individually unremarkable, collectively a serious exposure. Kiteworks secure data exchange exists precisely because governance must follow the data, not the application it happens to pass through, and Akamai’s data gives CISOs and compliance leaders the clearest evidence yet of why that shift is overdue.

Key Takeaways

1. The risk question has changed.

Akamai’s report argues the primary enterprise AI risk is no longer which employees can access AI tools, it is which employees share sensitive data with AI and through what identity, a shift that moves the problem from access control to data governance.

2. Nearly half of enterprise AI activity is identity-unmanaged.

Akamai’s LayerX data finds that 47.11% of enterprise AI conversations occur through personal accounts rather than corporate-managed identities, meaning almost half of all AI activity sits outside standard identity governance.

3. Corporate identity does not guarantee corporate control.

Even when an employee signs in with a corporate email address, 14.4% of those conversations are running on personal freemium subscriptions, so data can still land in a vendor’s public training pipeline despite looking like sanctioned use.

4. A small population of power users drives most of the exposure.

Usage and conversation depth both concentrate sharply, with the top 5% of users generating at least 144 conversations and the top 5% of conversations running at least 18 prompts deep, meaning risk is concentrated, not evenly distributed.

5. AI agents are becoming a new enterprise identity class that still needs human accountability.

Akamai’s report calls on CISOs to inventory agents, their access, and their behavior the same way they govern human identities, and Kiteworks positions its Control Plane to give security and compliance teams that governance and evidence layer across both human and agent data access.

The Access Question Is Obsolete for Enterprise AI Risk

Akamai’s report opens with a framing worth quoting almost exactly as written. AI adoption in 2026 is a structural mandate, not an experiment. That single sentence explains why so many AI governance programs built in 2024 and 2025 are already behind. Those programs treated AI the way security teams treated any new SaaS category, identifying the tool, approving or blocking it, then moving on. AI does not behave like a static application. It continuously consumes, generates, stores, and acts on enterprise data, so the moment of “access” tells a security team almost nothing about what happened to sensitive information afterward.

A single sensitive customer record might travel through a prompt, get paraphrased in a response, get pasted into a second tool for formatting, and get screenshotted for a slide deck, none of which trips a conventional DLP rule because no single step looks like a data exfiltration event. Akamai’s report states plainly that the biggest AI security risk is no longer “employees who access AI,” it is “employees who share sensitive business data with AI.” For a compliance officer, that reframing has a direct consequence. Regulators do not audit application access lists, they audit data handling. Programs built around AI data governance rather than app gatekeeping are the ones that can answer the question a regulator will actually ask.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Inside Akamai’s LayerX Data on Enterprise AI Behavior

Akamai’s report draws its statistics from LayerX, the browser-security business it acquired, and this volume (published August 2026) is built entirely on behavioral telemetry, how employees actually use AI tools, not survey responses about intended use.

The usage pattern is worth sitting with before the identity numbers. Some 18.24% of employees use AI weekly, 30.47% monthly, and 47.67% qualify as quarterly-or-more users, meaning nearly half of everyone using enterprise AI is doing so casually. The average enterprise user participates in 36 AI conversations, but the bottom half of users generate 12 or fewer while the top 5% generate at least 144. Conversation depth follows the same shape: the average conversation contains 5.09 prompts and the median is only 2, yet the top 5% of conversations run 18 prompts or deeper, evidence of sustained, iterative sessions rather than one-off lookups.

App sprawl compounds the concentration problem. The top four AI applications in a typical organization are each used by more than 20% of the workforce, but usage drops below 5% by roughly the tenth most-used application and approaches zero by the thirtieth. That long tail of niche, regional, and personal-preference shadow AI tools, including consumer platforms like DeepSeek that Akamai notes are running 99.83% through personal accounts amid active government scrutiny of where that data ends up, is the terrain where governance programs have the least visibility and the most exposure per user.

Nearly Half of Enterprise AI Activity Runs Through Unmanaged Identities

The statistic anchoring this report is straightforward. Some 47.11% of enterprise AI conversations happen through personal identities rather than corporate-managed accounts, against 52.89% through corporate accounts. Almost half of everything employees do with AI inside the enterprise happens through an identity the organization cannot deprovision on termination and cannot produce an audit trail for.

This is not evenly distributed by platform. ChatGPT runs 61.36% personal, Copilot 63.92% personal, and Claude 61.09% personal, while purpose-built enterprise offerings flip the pattern entirely: Gemini Enterprise runs 98.15% corporate and Copilot for Microsoft 365 runs 90.55% corporate. The gap is not a permanent feature of AI adoption, it is a governance failure specific to general-purpose consumer tools operating unmanaged inside the enterprise.

The problem hides inside compliant-looking accounts too. Of AI conversations initiated from a corporate email address, 14.4% are actually linked to personal freemium subscriptions rather than enterprise-managed licenses, meaning submitted data may still feed a vendor’s public training pipeline despite looking, on a domain-based access report, exactly like sanctioned use. A CISO reporting AI usage figures based on email domain alone is very likely overstating actual governance coverage. This is the gap Kiteworks Compliant AI is built to close, governing the data itself at the point it would leave a sanctioned environment rather than trying to detect every personal account after the fact.

AI Power Users Concentrate the Risk, and the Attack Surface

Akamai devotes a dedicated spotlight to what it calls AI power users, a small population that conducts longer, more contextual sessions, shares more sensitive business information, and increasingly delegates execution-level work to autonomous agents. That dependence on AI-generated output is where the power-user pattern intersects with the report’s vibe hacking case study. In 2026, LayerX researchers showed that a popular frontier AI coding assistant could be manipulated by subtly editing a project’s local markdown instruction file, the kind of behavioral-profile document used to set a model’s contextual boundaries, causing the assistant to perform unauthorized actions or generate insecure code while appearing to behave normally.

Akamai’s recommendation follows directly: identify power users, measure how AI is used rather than simply which apps are accessed, and monitor prompts, uploads, and responses that touch sensitive information. That guidance only works if the organization can observe interaction content in the first place, not just log which application was opened.

CursorJacking and CometJacking Show Attackers Targeting the Agent, Not the User

Akamai documents two incidents that illustrate how AI tools have themselves become attack surface. In CursorJacking, a rogue browser extension disguised as an ordinary productivity tool reaches into the Cursor AI coding assistant’s local storage, extracts API keys and session tokens, and silently exfiltrates them, letting an attacker impersonate the developer, abuse connected services, and compromise linked repositories. In CometJacking, analyzed against Perplexity’s Comet AI browser, an attacker embeds malicious instructions inside an ordinary web page; simply visiting it through a link can manipulate the browser’s AI agent through indirect prompt injection, exposing emails, credentials, and local files with no download required.

Both incidents exploit trust an organization already extended to an AI tool, and both bypass controls built to watch human behavior because the action is carried out by software the human authorized once and then stopped watching. Governance built only around what a human clicks will miss both.

The CISA Data Spill Shows Why Good Intentions Are Not a Control

The most instructive incident in Akamai’s report is not a hack at all. In early 2026, multiple news outlets reported that a U.S. government official accidentally released internal, restricted operational data from the Cybersecurity and Infrastructure Security Agency through a public AI tool. Akamai is explicit about what this represents: not an external compromise, not a cyberattack, but an optimization mistake made by a highly trained user performing routine daily analysis.

That framing should unsettle any security leader whose AI governance program is built around detecting malicious insiders, because this incident involved neither malice nor an access failure. It was a data-handling failure, and no allowlist or application approval process would have caught it, because the tool itself was permitted. Only controls that inspect what data is moving through a sanctioned interaction, in real time, can catch this class of incident, the gap between access control and a genuine zero trust approach to AI data governance.

Browser Extensions Are Privileged Software Nobody Is Governing

Adoption of AI browser extensions peaks at mid-sized organizations, 17.70% at companies with 1,000 to 2,500 employees, against 9.53% at large enterprises. The permission profile is where the real exposure sits: nearly 75% of AI extensions request high or critical permissions, they are almost three times more likely to request cookie access than the average extension (18.19% versus 6.67%), and 41.91% request scripting access. On top of that footprint, 16.31% carry known CVEs, roughly half again the rate of browser extensions generally. CursorJacking is the real-world consequence. Akamai’s recommendation, treating extensions as privileged software with a continuously updated inventory rather than a one-time approval, requires a governance capability most organizations built years before generative AI existed.

AI Agents Are Becoming a New Class of Enterprise Identity

The fifth risk in Akamai’s top-five list is AI agents that operate outside existing guardrails, and it is the risk the report treats as most unresolved. Akamai is careful, and worth being equally careful about here, not to describe agents as acting independently of the humans and organizations that deploy them. An agent operates under delegated authority, using access a human or a policy granted it, and every action is in principle traceable back to that grant. The governance failure is that most organizations have not yet extended the identity, monitoring, and access controls they already apply to human users to cover the agents now operating alongside them.

That extension is what a unified Control Plane provides. Kiteworks Control Plane governs how both human users and AI agents access, use, and exchange sensitive content under one policy and audit layer, so an agent retrieving a regulated document is subject to the same ABAC policy evaluation and audit logging as a human doing the equivalent task. A Secure MCP Server integration that connects an agent to enterprise content without routing that connection through governed, logged access reintroduces the same identity gap this report warns about, just with an agent instead of a personal ChatGPT account as the unmanaged identity.

Akamai’s Five Pillars, and Where Kiteworks Closes the Evidence Gap

Akamai closes its report with a five-pillar framework: focus on power users, eliminate shadow AI through identity federation, protect data at the AI interaction layer with contextual DLP instead of pattern matching, secure extensions as privileged software, and prepare for autonomous agents by governing them as a distinct identity class. It is a sound checklist, and it is written from a security operations vantage point, focused on visibility and detection. That is not, by itself, the lens a Chief Compliance Officer needs when a regulator’s inquiry has a statutory clock attached to it. Knowing an interaction happened and was risky is a detection outcome. Producing, within the regulator’s deadline, a defensible record of which data was involved and under what policy authority, is an evidence outcome, and a program built entirely around detection still needs an evidence layer underneath it.

Kiteworks Compliant AI applies policy at the point sensitive content would move to or from an AI interaction, so governance does not depend on first identifying every application an employee or agent might use. The Kiteworks Control Plane extends that same policy and audit layer across secure email, secure file sharing, managed file transfer, secure web forms, and AI interactions alike. When an examiner asks what data an AI interaction touched, the answer needs to come from a governed audit log, not a best-effort reconstruction, and a CISO Dashboard that surfaces this activity across human and agent access alike is what makes Akamai’s own recommendations actionable.

To learn more about closing the shadow AI identity gap and governing AI agent access to sensitive data under one evidence-ready Control Plane, schedule a custom demo today.

Frequently Asked Questions

Access risk asks whether an employee is permitted to open a given AI tool, which is what allowlists, SSO requirements, and app-approval workflows control. Usage risk asks what data moved through that interaction and where it ended up, a question access controls cannot answer because Akamai’s data shows the highest-risk activity, personal accounts and freemium subscriptions, often passes every access check while still moving data outside corporate governance. Programs organized around AI data governance close that gap because they govern the data itself regardless of identity or application.

It means an examiner, auditor, or opposing counsel asking what happened to sensitive data inside an AI conversation has roughly even odds of hitting an identity the organization has no formal relationship with and no ability to produce records for. A compliance program needs data governance and audit capability that operates at the point sensitive content would leave a governed environment, not one that only tracks activity on accounts it already knows about.

Akamai’s report and Kiteworks’ own positioning treat AI agents as a new identity class that still operates under delegated human and organizational authority, not as an autonomous actor outside anyone’s accountability. Because agents typically carry privileged access to enterprise SaaS, email, and files, as the CometJacking case study shows, they need the same ABAC policy enforcement and audit logging already applied to human accounts, extended to cover this second population.

No. Akamai’s report is explicit that the objective of AI security is to secure enablement, not restrict the technology, and Kiteworks Compliant AI is built around that same premise, applying policy at the point sensitive content moves to or from an AI interaction so employees keep using approved AI tools productively while sensitive data stays governed and auditable.

An auditor typically expects a record showing what data the agent accessed, under what policy authority, at what time, and what controls, encryption, access restrictions, logging, applied at the moment of access, produced quickly enough to meet the inquiry’s own deadline. A governed Kiteworks Control Plane with a consistent audit log across human and agent activity is what lets a compliance team assemble that evidence package on demand.

Additional Resources