AI Power Users Are the New Shadow AI Risk: Why 5% of Employees Can Change Your Threat Model

The important lesson from Akamai's Enterprise AI Usage Risk Report 2026 is not simply that employees use AI. Security teams already know that. The sharper lesson is that enterprise AI risk appears concentrated. A small group of AI power users can generate an outsized share of prompts, uploads, tool connections, browser extension activity, and agent-style workflows. That changes where security teams should look first.

The Hacker News coverage of the report frames the issue around the top 5% of AI users. Those employees are not casual prompt writers asking for a meeting summary once a week. They are the people turning AI into an operating surface: coding with assistants, analyzing documents, uploading files, connecting tools, using browser or IDE extensions, and relying on models for decisions that start to matter. Akamai's own summary says these power users are more likely to share business information, upload files, submit sensitive data, integrate AI into daily decision-making, and delegate execution-level work to autonomous agents.

That concentration matters because most AI governance programs are still designed as if risk is spread evenly. A company may train everyone, publish an acceptable-use policy, approve one enterprise chatbot, and declare progress. But if the highest-volume 5% are also the ones experimenting with niche AI tools, personal accounts, extensions, coding agents, and autonomous workflows, the broad policy misses the narrow blast radius where real exposure is accumulating.

Akamai reports that nearly half of enterprise AI conversations occur through personal identities rather than corporate-managed accounts. That is a structural visibility problem. A personal login can turn a work prompt into data movement outside the controls the company thought it had: SSO, retention policy, enterprise DLP, audit logs, legal hold, and admin review. Even worse, some users register personal or freemium subscriptions with corporate email addresses, which can make the activity look business-approved while still bypassing enterprise governance.

The practical takeaway is that AI identity is now a security control. Security teams should not only ask which models are approved. They should ask which identity was used, which account tier processed the data, whether the prompt and output are logged, what retention terms apply, whether model training is disabled, and whether the organization can revoke access centrally. If the answer is unclear, the AI interaction belongs in the shadow AI bucket even if the tool brand is familiar.

The long-tail problem is just as important as the headline platforms. Most teams focus on ChatGPT, Claude, Gemini, and Copilot because those names are visible in executive conversations. But power users often adopt smaller AI tools first: PDF analyzers, meeting summarizers, code helpers, browser agents, spreadsheet copilots, research assistants, resume tools, transcription services, AI search plugins, and IDE extensions. Each tool may look minor. Together, they create a distributed data-processing layer that security never designed.

Browser and IDE extensions deserve special attention. Akamai's press materials say almost three quarters of AI extensions request high or critical permissions and that a measurable share contain known CVEs. That should immediately trigger a different review model. An AI extension is not just a browser convenience. It may see page content, clipboard data, source code, session state, local files, developer workflows, and prompts. In an enterprise setting, that can put credentials, customer context, and proprietary code one click away from the wrong boundary.

This is where old DLP thinking starts to fail. Traditional DLP was built around files, email, storage buckets, and known data patterns. AI data movement is often smaller, more conversational, and more fragmented: a function pasted into a coding assistant, a customer paragraph dropped into a rewrite tool, a spreadsheet uploaded for analysis, or a screenshot summarized by an extension. Each event may be too small to look like exfiltration. The aggregate can still reveal strategy, architecture, source code, customer data, and incident context.

AI agents raise the stakes because the risk is no longer limited to what a human pastes. Agents can act. They can browse, click, read, summarize, call APIs, open pull requests, query logs, write tickets, inspect repositories, trigger workflows, and interact with SaaS applications. If those actions happen through personal accounts, overprivileged extensions, or unmanaged connectors, the organization has created a semi-autonomous operator that is not in its identity, logging, or incident-response model.

The correct response is not to hunt down the 5% and punish them. Those users are often the employees producing the most value from AI. They may be the first to discover useful workflows for engineering, customer support, finance, sales, security, and operations. Blocking them without an approved alternative will push them deeper into unmanaged tools. The better security move is to identify them, learn what they are trying to accomplish, and give them governed paths that are faster than shadow AI.

Start with a 30-day AI power-user review. Pull logs from enterprise AI platforms, secure web gateways, browsers, endpoint telemetry, SaaS admin consoles, identity providers, model gateways, and developer tools. Rank users by conversation volume, number of AI tools used, file uploads, extension installs, source-code interactions, sensitive-data proximity, and agent-like automation. The goal is not surveillance theater. The goal is to find where business processes have already started depending on AI.

Next, separate users into risk patterns. Some power users are safe but heavy: they use enterprise Copilot or Gemini through managed identities for normal drafting and summarization. Some are high-value and unmanaged: developers, analysts, or operators using personal subscriptions because the approved tools are too slow or too limited. Some are high-risk by function: employees handling customer data, source code, finance, legal, HR, incident response, or production operations. Each group needs a different control, not one generic AI policy.

For CISOs, the control stack should be concrete. Require SSO and enterprise accounts for approved AI. Discover unmanaged AI apps continuously. Inspect prompts, uploads, copy/paste, and responses where legally and technically appropriate. Vet browser and IDE extensions like privileged software. Treat AI agents as identities with least privilege, short-lived access, and behavioral monitoring. Create model gateway logs that show user, team, model, provider, data class, tool call, cost, and policy decision.

SOC teams should turn this into detections. Look for new AI domains, personal-account sign-ins, unusual upload patterns, high-risk extensions, source-code copy events, model gateway spikes, AI usage from privileged users, and agent traffic to internal systems. Tie AI activity to identity, device, SaaS, and data events. A prompt is not just text. In the right context, it is a security event.

AppSec and cloud teams need their own version of the same playbook. In AppSec, prioritize coding assistants, repository access, GitHub Actions changes, dependency triage, and secrets exposure. In cloud security, prioritize model keys, service accounts, notebooks, build runners, vector stores, data buckets, and AI sandboxes with internet egress. The question is always the same: what can this AI-enabled workflow read, where can it send data, and what can it change?

HackWednesday's recommendation is to move from broad AI policy to concentrated AI risk management. The average employee still matters, but the power-user cohort is where the operating model changes first. Find the people and workflows where AI has already become embedded. Give them approved tools, enterprise identities, model gateways, extension governance, and clear data rules. Then monitor the interaction layer continuously.

The shadow AI problem is not that employees want to move faster. The problem is that security teams often cannot see the fastest-moving AI workflows until after sensitive data, code, credentials, or decisions have crossed a boundary. If 5% of users can create the biggest exposure, the smartest first move is obvious: find the 5%, secure their workflows, and turn them into the pilot group for governed AI adoption.