When the Whole Company Adopts AI: What It Does to Your SOC

Over the past year, we watched a new class of alert appear in enterprise security operations centers and grow faster than anything else in the stream: alerts that were triggered by AI tools and agents. Not attacks against AI, but the ordinary, everyday footprint of an organization using it, from developers running coding agents and non-technical staff signing consumer AI tools into corporate accounts.

We reviewed AI-related activity across numerous enterprise environments. Two numbers frame everything that follows. AI-related alerts still account for only 0.43% of all SOC alerts. And that share is climbing every single month, up 685% between February and June 2026. AI is a small slice of the alert stream today and the fastest-growing slice at the same time.

What makes those alerts worth a security team’s attention is not their volume but their composition. We sort everything an AI agent triggers in a SOC into three buckets: real attacks, risks, and noise, with the split being 94.1% noise, 5.8% genuine risk, and 0.02% real attacks. Meaning that across the data we investigated, real attacks that use AI agents are a drop in the ocean. The cost of AI in the SOC, so far, is not breaches. It is a rising tide of alerts that look alarming and almost never are, and a small, quiet set of genuine exposures that those alarms tend to bury.

This post walks through each of the three categories with anonymized examples. All customer names, hostnames, usernames, and identifiers have been removed; indicators are defanged.

AI adoption inside an enterprise is not one behavior it is two very different ones arriving at the same time.

The first is technical. Developers install coding agents that spawn shells, read credential stores, open network tunnels, download packages, and run security tooling all as legitimate work, and all of it indistinguishable to a detection engine from theearly stages of an intrusion. This is the loud half, and it dominates the data.

The second is when employees grant OAuth consent to third-party AI applications,share information, and paste documents into generative-AI tools. This is the quiet half. It rarely trips an endpoint detection, but it is where data leaves the building.

Both halves land in the same place, the SOC, and both look, at first glance, like something to worry about. Sorting the signal from the noise is the entire job.

AI accounts for a small share of the volume but is fast-growing**.** Of the roughly 16.9 million SOC alerts we reviewed, about 73,000 (0.43%) were AI-related. Read on its own, that is reassuringly small.

The rise is monotonic. Every full month is higher than the one before, and growth accelerated sharply in May 2026. Over the window when reporting is stable across regions (February to June), volume grew by 685%. The 0.43% figure is best understood as today’s floor, not a ceiling. A team that sizes its AI-alert handling to current volume will be under-provisioned within a quarter.

The composition is as lopsided as the trend is steep. Nearly all of the AI-generated alerts are noise.

For this research, we investigated the AI-related population and sorted each alert by the underlying activity. A real attack is a confirmed compromise. A security risk is not a compromise but a genuine exposure (for example, a coding agent running with its permission safeguards disabled). Noise is legitimate activity that tripped a detection written before AI agents existed. By that measure, nearly all of the AI-related alerts are noise (94.1%), a small portion are genuine security risks (5.8%), and real attacks are a sliver (0.02%).

The second measurement is how those same alerts were handled in production without a human in the loop. When an alert reaches an automated triage platform, two separate decisions are made about it.

Of the AI-related population, only 5.4% were ever escalated to a human analyst; the remainder were flagged for follow-up.

A high-severity alert does not necessarily mean an actual threat. For example, a single detection at a single customer accounted for 55% of all “critical” verdict alerts flagging a Windows binary (Expand.exe) as a lateral-tool-transfer. Upon inspection, it was found that a developer’s coding agent was setting up a shell environment, and the behavior was normal for this type of work.

The lesson for any SOC is the same: severity labels on AI activity have to be read with suspicion, not taken at face value.

A real attack is an actual compromise or an attacker operation enabled by, or riding on, AI adoption. This is the category every executive asks about first, and it is the smallest, accounting for roughly 0.02% of AI-generated alerts.

When it comes to actual threats that were detected in this class of alerts, none was a compromise caused by an organization’s own AI agent. Every alert titled “AI agent running mimikatz,” “reverse shell from a coding tool,” or “credential theft” was resolved, on inspection, to a developer doing legitimate work or to a detection misfiring. We return to those in the Noise section.

What was real is an attack that rides on AI rather than through it: a live phishing campaign that weaponizes AI brand names as lures. Across multiple customers, and as we expanded to new ones during the window we studied, we observed malicious emails with AI-themed subject lines featuring the biggest names in AI. The lure works precisely because AI adoption has made these brands familiar and their notifications routine. Employees now expect email from these products, which is exactly what the attacker is counting on.

Here are some examples of incidents where we spotted the execution of tools or commands that usually indicate real attacks (or penetration testing), only in these cases they were invoked by Claude, Codex, etc. So the investigator also needs to question why the agents were running these tools and whether it was part of a real attack that exploited the agent.

The pattern across all three is worth stating plainly: the closer we looked, the more the “attack” dissolved into context. That is the defining characteristic of AI-era triage.

About 5.8% of the AI-related alerts are the ones we think deserve the most attention. These alerts detect an unsafe use of AI tools, not necessarily a compromise (yet). It is the moment when an agent, behaving exactly as instructed and with no attacker involved, does something that materially exposes the organization or the user.

The main risk is agents running with a permission-bypass flag, the option that tells the agent to stop asking the user before it acts. Many users choose to trust the agent not to destroy their machines or execute dangerous commands, but as experience and, now, the data show us, in many cases, agents will attempt, and mostly succeed in executing commands that expose the organization and the user to great risks. It is worth noting that, especially when running the agent with the permission-bypass flag, it is recommended to use additional configurations, also known as harnesses, to programmatically prevent the agent from attempting to execute risky commands.

On every sample we examined, the invocation was legitimate developer work. That is exactly why it matters. This is the same precondition abused in a publicly documented supply-chain attack, where an attacker’s malicious code executed freely because a coding agent had been launched with its permission prompts disabled. The exposure is not intent; it is that the rail is off, across many customers and at scale, waiting for the one time the code the agent is asked to run is not benign. Notably, these same permission-bypassed invocations are also the single largest source of false positives.

Other instances of unsafe use we surfaced:

Noise is the largest category by an order of magnitude, 94.1% of the AI-generated, and it is the one that directly determines whether a SOC drowns. Noise here is not random. It is specific and diagnosable: detections written before AI agents existed, now firing at high severity on routine agent work. This is not a new tendency in the SOC, as Sophos previouslyreported.

The clearest example is the AI vendors’ own software. The genuine Anthropic Claude Desktop installer, verified by its code signature, triggers major EDR rules such as “Ransomware Operations detected” and “Encoded PowerShell Download and Run” across several customers. The installer is legitimate. The detection describes installer behavior in the ransomware vocabulary.

Underneath that sit the agent-behavior false positives, all confirmed on inspection to be developers using tools as intended:

The false-positive rates are the story. Across the noisiest AI activity detections, the benign share ranges from 77% to 99%. Several detections are wrong on the AI-generated more than four times out of five:

The one exception proves the rule. The ClickFix detection is the single cluster that leans genuinely severe, only 37% benign, and it does so precisely because it collides with the permission-bypass risk from the previous section: it fires on coding agents launched with --yolo. Even the “real-looking” noise traces back to legitimate AI use.

From our analysis, the first step for every SOC is clear: tune the noisiest legacy detections, the ones firing at high severity on routine agent work. Next, define policies on what information can be shared with third-party AI platforms (as with any third-party platform) and, based on those policies, proactively hunt for permission-bypass flags, unauthorized tunnels, and risky OAuth grants rather than waiting to be alerted.

The second step is harder, because it touches how triage itself works. AI tools execute commands on the user’s machine, with the user’s credentials, essentially acting on the user’s behalf. Alerts are therefore triggered by actions attributed to the user, and in many cases the user was not aware those actions took place. Before AI, suspicious activity executed on a user’s machine without their knowledge usually indicated a high probability that an attacker had taken over the machine. Now SOC teams face a new layer of complexity: first determine whether the action in question was executed by an AI agent or tool.

To separate the user’s context from the agent’s, and to keep the agent away from credentials and sensitive information it should not have, we suggest running AI tools in an isolated environment with restricted access, such as a Docker container or a virtual machine. Isolation limits what the agent can reach, and it makes the agent’s behavior easier to distinguish from the user’s own activity.

Pulling the three categories together, the operational reality of enterprise AI adoption looks like this:

The uncomfortable synthesis is that AI adoption has not, so far, brought a wave of AI-enabled breaches. It has brought a wave of alerts, small as a share of total volume today, that have grown 18-fold in six months and are overwhelmingly false, alongside a smaller, quieter set of genuine exposures that the alerts tend to bury. A SOC that treats every agent action as a potential intrusion will exhaust itself on false positives and, in doing so, will be less likely to notice the ngrok tunnel or the keychain dump that actually matters.

The work ahead is therefore less about detecting AI attacks and more about teaching detection engines what normal AI behavior looks like before the volume that is doubling and tripling month over month makes that work unavoidable. Understanding this distinction is what separates a SOC that scales with AI adoption from one that is buried by it.

Intezer is an autonomous AI SOC platform built to solve exactly the problem this data illustrates: the growing gap between alert volume and analyst capacity. Rather than tuning individual detections one at a time, Intezer investigates every alert automatically, applying forensic-level analysis to determine what's actually happening on an endpoint or in an email, then delivers a verdict a human can trust. That means 100% alert coverage — including the AI-related noise — without the SOC drowning in it.

If you're seeing the same shift in your own alert stream,visit intezer.comto see how Intezer's platform handles it.

Note:This article has been expertly written and contributed by Nicole Fishbein. Senior Security Researcher and Malware Analyst at Intezer.