When the Whole Company Adopts AI: What It Does to Your SOC  The Hacker News  Sep 12, 2026 AI Agent / Security Operations 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. The New Shape of the Alert Stream 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 the early 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. By the Numbers 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. Number of AI-related alerts per month as seen in our system. 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 breakdown of the AI-related alerts based on the final classification of each alert. 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. The verdict states how dangerous the activity looks: it can be benign, suspicious, or malicious. 79.8% received a benign verdict. The response states what happens next: the alert can be suppressed (closed automatically, so no analyst ever sees it), flagged for follow-up, or escalated to a human. 81.7% were automatically suppressed. 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. Category 1: Real Attacks 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. Anthropic is used as bait in the business context. In that alert, the email subject is RE: Anthropic Engagement approval & payment, and the analysis says the sender references a supposed contract/invoice with Anthropic to make a large payment request appear legitimate. So Anthropic is not the sender or the threat source, it’s part of the pretext used to support the invoice fraud story. An email uses a fake Google/Gemini Ads invitation lure to appear legitimate and trustworthy. It presents itself as a business-related workspace invitation, encouraging the recipient to connect or join what looks like an official Gemini Ads environment, but the sender and reply-to infrastructure are not associated with Google and instead rely on the suspicious domain gemini-advertisers[.]com, indicating a brand impersonation attempt designed to drive the user to a malicious site. The email impersonates OpenAI (“OpenAI Partner Summit 2026”) but originates from noreply-zoomevents@zoom.us. Although the URLs use legitimate zoom.us infrastructure, the content and registration flow are being used to lend credibility to a fraudulent invitation. Phishing email impersonating OpenAI Device code phishing The AI IDE Cursor seems to have moved from normal coding activity into unsafe low-level system actions: while likely attempting to complete a debugging or troubleshooting task, the agent used a known credential-dumping technique (MiniDump via comsvcs.dll) that can expose secrets from process memory. The parent-child chain Cursor.exe → powershell.exe → rundll32.exe, the temp .ps1 scripts, and the memory-dump commands show the IDE initiating an automated action sequence that may have been intended to help development, but did so in a way that created a serious credential-access risk on the endpoint. 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. Category 2: Unsafe Use 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. The split of permission-bypass flags as seen in our system. 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.