AI alerts in SOC grow 685% between February and June 2026; most is noise

In recent months, security operations in companies have started to receive a new kind of alerts: those generated by the internal use of IA tools and agents. An analysis of approximately 16.9 million SOC alerts reveals that about 73,000 (the 0.43% of the total) were labeled as related to IA, and that portion has grown continuously: between February and June 2026 increased a 685%. That is, today the IA alerts are a moderate fraction of the global flow, but they are the fastest growing portion and pose operational challenges that are already affecting detection and response teams.

These are the confirmed facts that emerge from the analyzed data set: most alerts originating from agents or IA tools do not represent intrusions; they are divided into three categories by composition: 94.1% noise(legitimate activity that triggers old rules), 5.8% risk(unsafe use of the tool that exposes data or credentials) and 0.02% actual attacks(confirmed commitments). In addition, when these alerts pass through automatic triage platforms, 79.8% receive a benign verdict, 81.7% are automatically deleted and only 5.4% end up climbing to a human analyst.

Technically, why do IA tools generate so many false alarms? Development agents and automated assistants perform actions that we traditionally associate with an intruder: create shells, launch PowerShell, write temporary scripts, open outgoing tunnels (e.g. with ngrok) and access to credentials stores. These same signs - child processes that launch interpreters, tunnel creation, keychain readings - match the signatures of side motion and exfiltration tools, so the pre-IA detection rules label the activity as high severity even if it is legitimate. The actual operating cost does not, so far, come from massive gaps caused by IA agents; it comes from a tide of credible alerts that consume time from analysts and hide real exposures.

Cases categorized as risk deserve special attention because they are not false positive: they are patterns of use of agents that create tangible exposures. Recurrent observations include agents launched with flags that remove user confirmations (e.g. -- yolo or --dangerously-skip-permissions in several environments), public reverse tunnels created with employee's own tokens, keychain spins (e.g. -keychain > / tmp /) and indiscriminate OAuth permissions to third-party IA applications. These scenarios are not incidents by themselves, but leave the organization in a high-probability operating position if the code or flow being automated is malicious or if the third party account is compromised.

In the few real attacks detected in the sample, the vector was not an "internal IA" that took control, but external campaigns that took advantage of the familiarity of staff with IA marks to build very credible phishing baits: issues and texts that mentioned suppliers such as Anthropic, Gemini or OpenAI to legitimize payment requests or invitations. This technique exploits a cultural change (employees expect legitimate messages from these platforms), and confirms that the adoption of IA can create areas of deception without the tool itself being compromised.

There are concrete technical examples that illustrate how the border between normal and dangerous has become blurred: a legitimate installer of Claude's desk, signed by his manufacturer, activated rules that label electron / Squirrel installer behaviors as "ransomware operations"; an IDE or editor with agent opened a ngrok tunnel and posted an Internet port with the developer's token; an agent searched the macOS credentials warehouse to recover tokens and turned secrets to temporary files. In all these inspections the criticism is consistent: without context, the detections produce high-severity alarms over behaviors that can be both benign and dangerous.

What should SOC organizations and teams do right now? I offer specific and applicable recommendations:

1) Adjusting and prioritizing legal detection rules. Immediate Tuning of the rules that generate the most noise against known agent flows: reduce severity, add exceptions for signed binaries and legitimate installer processes, and introduce process-parent context and execution directory before marking as critical. This is the most return action to reduce the fatigue of analysts.

2) Detect and block flags of "skip-permissions" and dangerous execution patterns. Monitor invocation with flags that deactivate prompts, and treat these executions as high risk indicators for priority research. Actively hunt processes that launch ngrok, ngrok-equivalent or other reverse tunnels using user tokens.

3) Seal the agents. Run IA tools and agents with running capacity in contenedorized environments or virtual machines with restrictive policies (e.g. Docker or VM) to limit access to sensitive credentials and resources. Containment reduces the scope of any automated execution; see container safety guides in https: / / docs.docker.com / security /.

(4) Restrict and audit OAuth concessions and data loads to third parties. Apply allowlist / denylist policies for OAuth applications, activate corporate consent reviews and record each first login to external apps. Organizations should treat IA integrations like any other SaaS provider with DLP and CASB controls in the data chain.

5) Automate triage with IA-oriented forensic analysis. Teams need tools that not only suppress noise, but provide forensic context (process tree, binary signature, token / tunnel correlation) to determine whether an action was ordered by a user agent or an attacker. This reduces the need for human intervention on benign events and releases the ability to investigate real exposures.

(6) Develop and adjust policies for use. Prohibit unsafe flags in productive environments, demand harnesses that limit the execution of dangerous commands and educate developers about risks of exposing secrets to automated agents. For tunnel tools and remote access, review the use of services such as ngrok and document exceptions; technical documentation is in https: / / ngrok.com / docs.

Limitations and areas of uncertainty: the numbers come from the analysis described and are solid for this sample, but the adoption and configuration of agents vary between sectors and geography, so the proportion and speed of growth may differ in specific organizations. There is also no evidence in the revised sample of an emerging pattern of internal agents being used by attackers to compromise large-scale environments; however, the combination of deleted permits and automation does constitute a proven opportunity for attack in previous incidents and therefore a real risk.

In short, the era of the IA in the endpoint poses a double problem: on the one hand, mass noise that threatens to saturate the SOC; on the other, a handful of silent exhibitions - tunnels, overturned secrets, excessive OAuth permissions - that can become concrete gaps if they are not managed. Prioritize the tuning of inherited detections, contain agents and monitor permiso-bypass and exfiltration indicators must be the immediate road map to avoid confusing noise with what really matters.