Intezer AI SOC Alerts Surged, but Almost All Were Noise

Intezer AI SOC alerts rose 685% from February through June 2026, despite representing just 0.43% of the security alerts in its study. The conflict is already clear. Enterprise AI has not produced the wave of agent-driven breaches many security teams feared. It has produced a fast-growing stream of legitimate activity that often resembles an intrusion.

Intezer examined about 16.9 million alerts across multiple enterprise environments. Roughly 73,000 involved AI tools or agents. Its researchers classified 94.1% as noise, 5.8% as genuine security risks, and only 0.02% as real attacks.

That imbalance puts established detection logic on one side and normal AI-assisted work on the other. Claude, Codex, Cursor, ChatGPT, and similar tools can launch processes, handle files, invoke shells, and connect to services. Those actions resemble attacker behavior when viewed without the user's intent.

The result is not simply more work for a security operations center, or SOC. It is a context problem. Teams must distinguish legitimate agent activity from unsafe agent behavior before false alarms bury the exposures that matter.

Intezer AI SOC Alerts Climbed Faster Than Their Share Suggests

The important number is not AI's current share of alert volume. It is the speed and composition of that growth.

According to Intezer's AI alert study, AI-related activity generated about 73,000 of the 16.9 million alerts reviewed. That makes the category small beside endpoint, identity, email, cloud, and network alerts already reaching enterprise SOCs.

However, monthly AI-related volume increased throughout the stable reporting period. Intezer measured 685% growth between February and June 2026. The company described the pattern as monotonic, meaning every complete month exceeded the previous one.

That trajectory matters because enterprise adoption does not require a formal company-wide deployment. Employees can connect a consumer chatbot through OAuth, which lets an application access approved account resources. Developers can install coding agents that immediately begin interacting with local systems.

Each action adds a new source of telemetry. It can also activate rules created years before general-purpose agents began operating on employee computers.

Intezer divided the resulting alerts into three categories. Noise covered legitimate activity that triggered an existing detection. Security risk covered unsafe behavior or exposure without a confirmed compromise. Real attacks required evidence of an actual attacker operation.

Noise dominated at 94.1%. Security risks accounted for 5.8%, while confirmed attacks represented about 0.02%. These classifications came from Intezer's platform and methodology, so independent studies may produce different ratios.

The internal handling data showed another layer of the same pattern. Intezer said 79.8% of the AI-related alerts received a benign verdict. Its automated system suppressed 81.7%, closing them without presenting them to a human analyst.

Only 5.4% were escalated to an analyst. The remaining alerts were flagged for follow-up rather than immediately treated as incidents.

Those results support automated triage, but they also expose a dependency. Automation must understand the relationship between an agent, its user, and the task being performed. A process name or command alone rarely supplies that context.

One customer generated 55% of all AI-related alerts labeled critical in the dataset through a single detection. That rule identified the Windows binary Expand.exe as a possible lateral transfer tool.

Closer inspection found a coding agent preparing a shell environment. The activity was normal for that workflow, even though its individual technical signals resembled attacker behavior.

A traditional severity label would have placed those alerts near the front of an analyst's queue. Context moved them toward automatic closure. That difference becomes expensive when the same pattern repeats across thousands of endpoints.

The study does not show that all high-severity AI alerts are harmless. It shows that severity loses meaning when detection logic cannot recognize normal agent behavior.

This is the first operational change for SOC leaders. AI activity needs its own baseline, including approved tools, expected parent processes, usual destinations, and permitted actions. Without that baseline, growth in adoption becomes growth in false urgency.

Company-Wide AI Adoption Changes the Shape of the Alert Stream

Enterprise AI creates two security streams at once: loud agent execution and quiet movement of corporate data.

The loud stream comes mainly from technical users. Coding agents can create scripts, start interpreters, install packages, inspect repositories, open ports, or execute development tools. Each action can resemble one stage of an intrusion.

A developer might ask an agent to launch a local test server. The agent could start PowerShell, locate an unused port, run Python, and redirect output into project logs. An endpoint product sees an unusual process chain before it sees a benign development goal.

Intezer found that a signed OpenAI Codex sandbox binary produced this pattern. PowerShell then launched cmd.exe, python.exe, and conhost.exe while preparing a local project environment.

A conventional rule interpreted the sequence as a possible reverse shell. The command text instead showed local orchestration on 127.0.0.1, the loopback address used to reach the same computer.

Installers create similar collisions. Intezer reported that the legitimate Claude Desktop installer activated detections associated with ransomware behavior and encoded PowerShell execution. Its code signature confirmed the package's identity, but behavioral rules still treated the installation sequence as suspicious.

That does not make behavioral detection obsolete. Signed software can become malicious, and trusted applications can be abused. It means the detection requires supporting context before an analyst can assign intent.

The quiet stream comes from nontechnical adoption. Employees can grant an AI service access to corporate accounts, upload documents, or paste sensitive material into prompts. These actions may never create an unusual endpoint process.

Intezer observed OAuth consent granted to ChatGPT across multiple tenants. It also saw first sign-ins to an OpenAI application and a cluster of data-protection alerts involving generative AI uploads at one customer.

Most events were benign. Still, they represented corporate information moving into services outside the endpoint's immediate control.

This distinction explains why blocking a few executables cannot solve enterprise AI security. One part of the risk lives in processes. Another lives in browser sessions, identity permissions, software integrations, and data flows.

A useful inventory therefore needs more than an approved application list. It must connect users, identities, agents, extensions, OAuth grants, data destinations, and the resources each tool can access.

That work reaches beyond the SOC. Identity teams manage consent and access. Data governance teams define sensitive information. Engineering leaders decide which agent configurations are acceptable.

Procurement and legal teams evaluate third-party handling terms. Business managers determine whether employees have workable approved alternatives.

The SOC remains the point where these signals converge. It receives the alerts when a tool launches a suspicious command, opens a tunnel, or touches protected information.

Company-wide adoption also changes the meaning of attribution. Before general-purpose agents, a command executed under a user's account usually reflected either the user or an attacker controlling that account.

An agent introduces a third actor. It operates with the user's authority but may select commands the user never reviewed. The activity belongs to the account without fully reflecting the account holder's direct action.

That gap is especially important for incident timelines. Analysts need to know whether a human typed a command, an approved agent generated it, or malicious content manipulated the agent.

Security teams also need durable organizational context. A searchable engineering knowledge base can preserve approved workflows and local technical decisions. However, documentation must connect with current identity and endpoint evidence to support triage.

The operational objective is not perfect visibility into every prompt. It is enough verified context to separate approved work, unsafe behavior, and adversarial activity without watching employees more broadly than necessary.

Legacy Detection Logic Is Colliding With Normal Agent Behavior

The main contest is legacy detection logic versus AI agent context, not human analysts versus automation.

Security products often detect techniques rather than intent. Credential access, command execution, persistence, tunneling, and data collection remain dangerous regardless of which application initiates them.

AI agents complicate that model because legitimate tools now perform combinations once associated mainly with administrators, penetration testers, and attackers. The overlap is structural, not accidental.

Intezer found benign rates ranging from 77% to 99% among the noisiest AI-related detection groups. Several rules were wrong on AI-generated behavior more than four times out of five.

One example involved OpenAI Codex launched through Node.js with flags such as --yolo or --dangerously-skip-permissions. The resulting activity triggered detections related to ClickFix, disabled tools, and DLL injection.

Permission-bypass flags remove approval prompts before an agent takes actions. Developers use them to reduce interruptions, but the same convenience weakens an important control boundary.

The ClickFix cluster was an exception within Intezer's noise findings. Only 37% of those alerts were benign. That result does not make every alert an attack, but it gives the cluster more investigative value.

This is where simple allowlisting fails. Declaring Codex, Claude, or Cursor trusted would reduce noise, but it could also conceal unsafe actions launched through those tools.

The safer approach evaluates the full chain. The SOC should consider the signed application, initiating user, agent configuration, requested task, child processes, accessed resources, network destination, and resulting data movement.

MITRE's AI threat matrix reflects this broader view. It includes agent tool invocation, credential harvesting, prompt injection, reverse shells, and exfiltration through AI-related mechanisms.

Those techniques show why an approved agent cannot receive permanent blanket trust. The tool may be legitimate while a particular invocation remains unsafe.

Detection engineering must therefore become more conditional. A local server started inside a known development repository may be routine. The same interpreter creating an external tunnel from a finance workstation deserves different treatment.

A coding agent reading its own configuration token may be expected. Dumping the complete macOS keychain into a temporary file is not proportionate to that task.

Intezer observed that exact pattern. An agent used security dump-keychain and redirected the output to a temporary location while trying to retrieve stored credentials.

The intended task did not require malicious intent. The chosen method still exposed more information than necessary and created a valuable target on disk.

Another case involved an AI code editor that launched PowerShell and then ngrok, a service that creates internet-accessible tunnels. It opened a named reverse tunnel using the employee's authentication token.

The user's purpose may have been legitimate troubleshooting or development. Yet the action created a real path from the public internet into an enterprise environment.

A third example involved Cursor initiating a process chain that used a known memory-dumping method. Cursor launched PowerShell, which called rundll32.exe and the MiniDump functionality in comsvcs.dll.

That technique can extract secrets from process memory. Even when an agent selects it for debugging, the behavior creates a credential-access risk that deserves investigation.

These examples support a policy based on actions and boundaries, not just product names. Approved agents should still face restrictions on credential stores, production systems, public tunnels, and sensitive repositories.

Isolation can help. Intezer recommends running AI tools inside constrained environments, including containers or virtual machines, when the workflow permits it.

A container packages a process with defined resources and access boundaries. A virtual machine provides a separate operating environment with stronger isolation in many configurations.

Neither control is absolute. Containers can be misconfigured, while virtual machines still need identity, network, storage, and update controls. Both can reduce the number of resources an agent reaches by default.

They also improve attribution. Activity originating inside an assigned agent environment is easier to distinguish from a user's ordinary desktop activity.

The change requires careful measurement. Teams should track false-positive rates by detection, agent, configuration, and business unit. They should also record which suppressions later required correction.

A blanket reduction in alert volume is not success. The useful measure is whether tuning removes predictable noise without hiding credential access, external exposure, or sensitive data movement.

The Quiet AI Security Risks Matter More Than the Loud Alerts

The most consequential AI risks in Intezer's data were often exposures, not confirmed compromises or maximum-severity alerts.

Intezer classified 5.8% of the AI-related population as genuine security risks. These events did not prove that an attacker had gained access. They showed conditions that could make a later compromise more damaging.

Permission bypass was a central example. An agent operating without approval prompts can execute a long sequence before a user sees the details.

That design becomes more dangerous when the agent reads untrusted code, websites, tickets, emails, or documents. Malicious instructions hidden in those sources can influence an agent's choices.

Prompt injection is an attempt to make a model follow hostile instructions embedded in its input. It becomes more serious when an agent can use tools or reach business data.

An indirect injection may arrive through content the user never considers an instruction. A webpage or repository file can contain text intended for the agent rather than the human reader.

NIST's generative AI profile recommends governing, mapping, measuring, and managing AI risks throughout the system lifecycle. That model fits enterprise agents because risk crosses technology and organizational boundaries.

An endpoint alert might reveal the final command while missing the content that influenced the model. An identity log might reveal an OAuth grant without showing which documents later entered the service.

A data-loss prevention product might see an upload but lack the business purpose. Each tool observes one fragment of the event.

The SOC needs correlation across those fragments. It should connect the user, agent, prompt source, permissions, process activity, destination, and data classification when the available telemetry permits it.

That does not require collecting every employee conversation. Privacy and proportionality remain important. Organizations should capture the minimum evidence needed to enforce established policy and investigate meaningful risk.

Clear policy also matters because the same action can carry different consequences across departments. Uploading public marketing copy is different from uploading customer records, unreleased financial information, or source code containing secrets.

Approved tools do not eliminate this difference. Enterprise licensing can improve administrative controls, but it cannot decide whether every piece of data belongs in every prompt.

OAuth consent deserves similar attention. OAuth allows a user to authorize an application without handing over a password. The resulting token can still provide substantial access to mail, files, calendars, or other services.

A legitimate AI application's requested scopes may exceed the immediate task. A compromised account or manipulated agent can then use those permissions in ways the employee never intended.

SOC teams should examine high-risk consent grants, unusual first-time applications, and permissions that cross sensitive systems. They should also provide a rapid path for users to request approved integrations.

If governance moves too slowly, employees will work around it. That creates shadow AI, meaning tools or uses that operate outside established organizational approval and oversight.

The answer is not an indiscriminate ban. A ban can reduce visible activity while pushing useful work into personal accounts and unmanaged browser sessions.

Security teams need a practical sanctioned path with appropriate controls. Employees should understand which tools they can use, what information they can share, and when an agent needs an isolated environment.

CISA and international partners placed similar emphasis on ownership, transparency, and secure design in their AI security guidelines. Those principles apply to vendors, but enterprise buyers also need to evaluate them.

Procurement questions should cover logging, retention, model training, access scopes, administrative controls, incident notification, and data deletion. Technical testing should verify important claims wherever possible.

SOC playbooks must then translate policy into investigation steps. An analyst seeing an unfamiliar tunnel should be able to identify the responsible agent, user, task, and destination quickly.

The playbook should not automatically close the event because an approved tool launched it. It should determine whether the action stayed within an approved boundary.

The same principle applies to credential access. An agent reading a limited secret through an approved broker is different from exporting an entire credential store.

This action-centered model preserves useful detections while reducing avoidable noise. It also aligns alerts with the risks the organization has actually decided to manage.

What Intezer's Data Does Not Yet Prove

Intezer's findings are a useful operational snapshot, but they are not a universal measurement of enterprise AI risk.

The study covers alerts visible across environments connected to Intezer's platform. It does not represent every company, security stack, industry, geography, or style of AI deployment.

Intezer did not publish a complete customer count or a detailed breakdown by sector in the article. It also anonymized customer, host, user, and identifier information.

That protects organizations, but it limits independent reproduction. Readers cannot determine how much one large environment influenced every category beyond the examples Intezer disclosed.

The research also measures alerts, not all AI activity. An action that never triggers a connected control may be absent from the dataset.

This matters most for browser-based tools, personal accounts, unsanctioned extensions, and data exchanges that endpoint products cannot observe. Quiet usage may be underrepresented beside executable agent activity.

The 94.1% noise figure should therefore guide detection tuning, not become a universal false-positive rate. Another organization may have different agents, policies, users, or telemetry.

The 0.02% attack share also needs careful interpretation. It does not show that AI agents are inherently safe or that agent-enabled attacks are negligible everywhere.

It shows that confirmed attacks were extremely rare within this specific AI-related alert population. Intezer said none of those confirmed attacks resulted from an organization's own agent causing a compromise.

The genuine attacks it identified used familiar AI brands as phishing lures. Attackers impersonated names such as Anthropic, Gemini, and OpenAI because employees increasingly recognize and trust them.

One email referenced a supposed Anthropic engagement and payment request. Another used a fake Gemini advertising invitation with infrastructure unrelated to Google.

A third impersonated an OpenAI partner event while using legitimate Zoom infrastructure to make the invitation appear credible. In each case, AI adoption strengthened the pretext rather than supplying a new attack technique.

That distinction is useful, but it can change. Wider agent permissions, stronger autonomous capabilities, and deeper business integrations increase the consequences of manipulation.

The absence of many confirmed agent-caused compromises in this dataset is not evidence that future deployments will remain safe. It is a baseline for watching the transition.

Vendor incentives also deserve attention. Intezer sells an AI SOC platform and automated triage services. Its research naturally highlights problems that contextual investigation and automation can address.

That does not invalidate the data. It means buyers should compare the results with their own telemetry, red-team findings, and incident history before changing controls.

Security teams should test whether automated verdicts remain accurate on their environment. They should sample suppressed alerts, review uncertain classifications, and monitor later evidence that contradicts an earlier decision.

They should also document the difference between verified results and vendor claims. For example, Intezer says its wider platform can investigate alerts at scale, but this study does not independently validate every performance claim.

The more difficult question concerns missing signals. A SOC can tune away visible noise and still lack coverage for unauthorized browser tools or risky data sharing.

This is why alert reduction cannot serve as the only success metric. Teams also need agent inventory coverage, risky permission counts, sensitive upload trends, and time required to trace an action back to its source.

An organization with fewer alerts but no visibility into OAuth or browser activity has not necessarily improved its security. It may have moved risk outside the measured channel.

Three Signals Will Show Whether SOCs Are Adapting

The next test is whether security teams can improve context faster than AI activity expands.

The first signal is false-positive performance for agent-related detections. SOC leaders should measure benign rates before and after tuning the noisiest rules.

A successful change will reduce repeated alerts from known installers, local development servers, and approved process chains. It will preserve review for permission bypass, credential dumping, external tunnels, and unusual data movement.

If benign rates fall without a rise in missed incidents, the SOC is learning normal AI behavior. If analysts keep closing the same patterns manually, adoption is still outrunning detection engineering.

The second signal is enterprise coverage across identity, browser, endpoint, cloud, and data controls. A list of installed coding agents is not a complete AI inventory.

Teams should look for new OAuth grants, first-time AI application sign-ins, unmanaged extensions, personal account usage, and connections between agents and sensitive repositories.

Improved coverage will reveal more quiet exposure at first. That temporary increase should not be mistaken for worsening security. Better measurement often makes existing risk visible before controls reduce it.

The third signal is whether agent deployments adopt constrained execution by default. Permission prompts, restricted credentials, isolated environments, and limited network access provide measurable boundaries.

Organizations should watch the proportion of agents launched with bypass flags. They should also monitor how often agents attempt prohibited commands, even when a control blocks execution.

A falling bypass rate would strengthen the case that governance is becoming operational. Continued growth would show that convenience still outranks containment.

Security testing should include realistic agent workflows, not only model prompts. An assessment can place untrusted instructions in code, documents, tickets, or web content and observe the agent's response.

The goal is to test the entire system. That includes identity permissions, tools, memory, external content, execution controls, logging, and human approval.

Intezer AI SOC alerts offer an early view of this transition. The headline result is reassuring only at first glance. Confirmed attacks were rare, but exposure and operational noise were already growing quickly.

For SOC teams, the immediate question is concrete: can they identify normal agent behavior without granting agents blanket trust?

Start with the detections that generate the most repeated benign alerts. Then compare that tuning against permission bypass, credential access, tunnels, OAuth grants, and sensitive uploads. If those higher-value signals become easier to see, the SOC is adapting. If alert counts decline while visibility stays fragmented, the apparent improvement is only quieter uncertainty.