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

When generative AI spreads across the entire company, from developers to business teams, the SOC is the first to feel it. A study published by Intezer on August 25, 2026, based on roughly 16.9 million alerts collected across numerous enterprise environments, puts numbers on the phenomenon. Its conclusion is nuanced: so far, AI adoption has not triggered a wave of breaches. What it mostly produces is noise, and that noise hides real exposures that current detection rules struggle to see.

What the data shows

Intezer’s researchers classified each AI-related alert by the underlying activity: attack, security risk or noise. They also measured, separately, the verdict (benign, suspicious, malicious) and the response (suppressed, flagged, escalated). The authors stress that the 0.43% share is a floor rather than a ceiling, and that growth accelerated sharply in May 2026.

Noise: rules written before agents existed

Most of the noise comes from detections designed before AI agents existed, which now fire at high severity on perfectly legitimate activity. Examples from the study:

• The official, signed Claude Desktop installer triggered “Ransomware Operations detected” and “Encoded PowerShell Download and Run” alerts at several customers, because of its Squirrel/Electron installation chain.
• OpenAI’s Codex CLI, launched with the --yolo flag, tripped ClickFix, tool-disabling and DLL-injection detections.
• A single detection flagging Expand.exe as lateral tool transfer accounted for 55% of all “critical” verdict alerts. In reality, it was a developer’s coding agent setting up its shell environment.

The direct consequence: once an AI agent is involved, the severity shown in the console is no longer a reliable priority signal.

Real risk: the agent doing exactly what it was told

The 5.8% classified as “security risk” involve no attacker at all. They are exposures created by agents carrying out their task, sometimes with excessive privileges:

• Permission bypass: agents launched with --yolo or --dangerously-skip-permissions, which no longer wait for human approval before acting.
• Reverse tunnel: an AI code editor spawned PowerShell, which started ngrok to open a named tunnel to the internet using the user’s own token.
• macOS keychain: to read a single token, an agent ran security dump-keychain, writing every stored secret to a temporary file.
• Data and OAuth: consent grants to ChatGPT, first sign-ins to the OpenAI application, data-protection alerts on uploads to generative AI services.
• Credential access: a Cursor.exe → powershell.exe → rundll32.exe chain using the comsvcs.dll MiniDump technique to dump process memory, likely for debugging according to the authors.

The key point: these behaviors are largely invisible to conventional alerting, precisely because they are buried in noise.

Real attacks: AI as bait

The few confirmed attacks did not come from internal agents. They exploited the popularity of AI brands: a fake Anthropic invoice used to request a large payment, a fake “Gemini Ads” invitation pointing to the look-alike domain gemini-advertisers[.]com, a fake “OpenAI Partner Summit 2026” event sent from a zoom.us address, and device code phishing.

What this changes for the SOC

Attribution comes first

Faced with a PowerShell alert, the first question is no longer just “is this malicious?” but “who acted: the user, an AI agent or an attacker?”. Without that distinction, analysts swing between two mistakes: escalating legitimate agent activity, or reflexively suppressing genuinely dangerous activity because it “looks like AI”. The parent process tree (IDE, agent CLI, Node or Python runtime) becomes essential context.

Auto-suppression has a hidden cost

Suppressing more than 80% of AI alerts lowers the workload, but an overly broad suppression rule can also hide the ngrok tunnel or the keychain dump. The goal is to suppress noise precisely while building a targeted hunting capability for risky usage.

As much a governance issue as a detection one

Several of the exposures identified (data sent to third-party models, OAuth consents, agents without guardrails) are first and foremost usage-policy questions. The SOC can detect them, but it cannot decide on its own what is allowed. Without a defined framework, every alert becomes a case-by-case judgment call.

Recommendations

The recommendations below build on Intezer’s suggestions, complemented by our experience of SOC environments.

1. ImmediateTune the noisiest legacy detections

   Identify rules that fire at high severity on legitimate AI installers and agents (Squirrel/Electron installs, agent CLIs). Add precise exclusions based on signature and process chain rather than blanket suppressions.

2. ImmediateHunt for risky usage

   Search your EDR telemetry for --yolo and --dangerously-skip-permissions flags, ngrok or other tunnels launched from an IDE, and calls to security dump-keychain.

3. Short termMake “AI agent” attribution part of triage

   Enrich alerts with the parent process and the identified AI tool. Document in your playbooks how to tell apart a user, an agent and an attacker.

4. Short termMonitor OAuth consents and data flows to AI

   Review consents granted to AI applications in your cloud directory and first sign-ins to new services. Align these controls with your DLP rules on uploads.

5. Medium termIsolate AI agents

   Run coding agents in dedicated containers or virtual machines, and use harnesses that block risky commands when approvals are disabled.

6. Medium termFormalize an AI usage policy

   Define which data may be shared with third-party platforms and which tools are approved, and train staff to recognize lures abusing the Anthropic, OpenAI or Google brands.