The 5% Problem: How a Handful of AI Power Users Became the Riskiest People in Your Company

Key points

• Akamai research found the top 5% of enterprise AI users generate the majority of risky AI activity inside companies.
• Most security teams are focused on casual ChatGPT and Claude users writing emails, not the small group building AI into core systems.
• These power users often connect AI tools directly to customer data, code repositories and internal databases without security review.
• The risk pattern echoes the early days of shadow IT, where staff installed unapproved software that later became a serious weakness.
• Standard controls like data loss prevention and access logging often miss AI traffic entirely, because it looks like normal web browsing.

Most companies worrying about artificial intelligence at work are worrying about the wrong people.

The usual fear goes like this. An employee pastes a confidential document into ChatGPT to get a quick summary, and the secrets leak. Fair enough. It happens. But new research from Akamai, the content delivery and security company, suggests the real damage is being done by a much smaller crowd doing much bigger things.

Akamai says roughly 5% of enterprise AI users account for the bulk of genuinely risky activity. These are not the marketing assistants tidying up a press release. They are engineers, analysts and operations staff who have quietly stitched AI tools into workflows that matter, things like customer support pipelines, code deployment, financial reporting and internal search over sensitive data.

This pattern was first flagged in reporting by The Hacker News, and it should feel familiar to anyone who lived through the last decade of cloud adoption.

Who are these 5% and what are they actually doing?

They are the keenest adopters, and they are building, not just chatting. Instead of typing questions into a chatbot, they are hooking AI models into real systems using APIs, which are the connectors that let one piece of software talk to another automatically.

A developer might wire a large language model into the company's code repository so it can suggest fixes. An analyst might connect an AI tool to a customer database so it can answer questions in plain English. A support lead might set up an automated agent that reads incoming tickets and takes action on them without a human in the middle.

Each of these can be genuinely useful. Each also punches a hole through the careful boundaries a security team spent years building.

Why is this worse than a normal employee using ChatGPT?

Because the AI is no longer a helper on the side. It is inside the machinery.

When someone pastes text into a chatbot, the worst case is usually a data leak. When someone connects an AI model directly to production systems, the worst case is that the model, or anyone who can trick it, can read or change real business data. Prompt injection, where an attacker hides instructions inside a document or web page the AI later reads, becomes a way to reach into the company itself. It is the AI-era cousin of cross-site scripting, the classic web flaw where malicious code hitches a ride inside trusted content.

The tooling around these integrations is also young. Many of the libraries and agent frameworks in use today have had serious flaws found in them this year alone. Power users tend to adopt them fast and update them slowly.

Why don't security teams see it?

Because AI traffic mostly looks like ordinary web browsing to the tools that watch corporate networks. A request to an AI provider is just an outbound HTTPS call, the same kind your browser makes when you load a normal website. Data loss prevention systems, which are designed to spot secrets leaving the company, were built for email attachments and file uploads, not for a steady drip of sensitive text going out through an API key someone set up on a Tuesday afternoon.

Akamai's point is not that AI is dangerous. It is that a small group of enthusiastic staff can move faster than the controls around them, and that the risk is concentrated, not spread evenly.

What should ordinary employees take from this?

If you are not in that 5%, very little changes. Keep sensitive data out of public chatbots and use whatever approved tools your employer provides.

If you are in that 5%, the honest ask is simple. Tell your security team what you have built before they find it in a log.