Developers and analysts are installing Claude, OpenAI Codex and Cursor directly onto corporate endpoints, frequently without going through procurement or a security review. Intezer's review of roughly 16.9 million enterprise SOC alerts found about 73,000 tied to AI tools and agents, and that volume grew 685% between February and June 2026. Details in this article come from analysis published by The Hacker News.

What matters for your security operations is what these tools actually do on a machine. A coding agent working normally will spawn shell processes, read credential stores, download packages, invoke Windows system binaries and open outbound network connections, all in the course of finishing a task a developer asked it to finish.

Every one of those behaviours is also what an intruder does in the first hour of a compromise. Your endpoint detection engine sees a process tree, a command line and a network call. It has no way of knowing that a developer typed a prompt thirty seconds earlier.

That is the core problem. Detection logic in most environments was written before coding agents existed, so it describes agent installer activity and agent shell activity in the vocabulary of ransomware, lateral tool transfer and reverse shells. Intezer observed the signed Anthropic Claude Desktop installer triggering "Ransomware Operations detected" and "Encoded PowerShell Download and Run" rules across several customers.

There is a second, quieter half of AI adoption that endpoint tooling barely registers. Staff grant OAuth consent to third-party AI applications and paste documents into generative-AI tools, which moves corporate information to an external model without generating anything that looks like an endpoint event.

For a CIO, the practical translation is straightforward. AI adoption in your organisation is currently producing a large volume of high-severity alerts that describe legitimate work, and a smaller set of genuine exposures that sit underneath them. Both arrived through ordinary business use, not through an attack.

Why AI Agent Activity Resembles Attacker Tradecraft

Detection engines flag AI agent behavior because the behavior genuinely matches intrusion tradecraft. When an agent completes a task, it spawns child processes from an editor or terminal, calls interpreters, reaches into credential stores and opens outbound connections. Every one of those actions maps cleanly to a MITRE ATT&CK technique that a human intruder would also use.

The clearest case Intezer documented involves an AI IDE that moved from coding work into low-level system actions. The process chain ran Cursor.exe → powershell.exe → rundll32.exe, dropped temporary .ps1 scripts, and invoked the MiniDump function exported by comsvcs.dll. That is the same LSASS memory dumping path used by mimikatz and mapped to T1003.001, OS Credential Dumping. The agent appears to have been troubleshooting a debugging task, so no attacker was involved, yet process memory secrets were still written to disk on that endpoint.

This is the distinction that matters for triage. The activity was not an attack, and it was also not safe. Any credentials resident in the dumped process are exposed to whatever reads that file next.

Living-off-the-land binaries produce the same collision. A single detection at one customer generated 55% of all critical-verdict alerts flagging the Windows binary Expand.exe as lateral tool transfer (T1570). On inspection, a developer's coding agent was setting up a shell environment, and the binary use was routine for that work. Severity labels on AI activity do not correlate with actual danger.

Command-line patterns extend the overlap:

• Interpreter chaining: a signed Codex sandbox binary spawning powershell.exe, which in turn launched cmd.exe, python.exe and conhost.exe, tripping a "PowerShell created possible reverse TCP shell" rule (T1059.001).
• Protocol tunneling: an AI code editor spawning PowerShell that launched ngrok and opened a named reverse tunnel to the public internet using the user's own auth token (T1572).
• Password store access: an agent running security dump-keychain > /tmp/ to retrieve one stored token, writing every stored macOS secret to a temp file in the process (T1555.001).
• Installer behavior: the signed Claude Desktop installer chaining Claude Setup.exe → Update.exe → squirrel.exe, which EDR rules described using ransomware vocabulary.

The deciding factor is context, and specifically four pieces of it. First, process lineage: whether the parent is a signed agent binary invoked by a developer, or an unrelated process. Second, command-line legibility. The reverse-shell alert resolved to noise because the PowerShell command was in clear text and showed benign orchestration, checking ports on 127.0.0.1, selecting an available one, starting a Python script from the project directory and writing stdout and stderr to local log files. Third, the working directory, which ties execution to a real project rather than a staging path. Fourth, whether outbound traffic terminates at a model provider API or at attacker-controlled infrastructure.

Across the noisiest AI activity detections, the benign share ranges from 77% to 99%. The exception is the ClickFix cluster at 37% benign, and it leans severe because it fires on agents launched with --yolo or --dangerously-skip-permissions, where the approval prompt has been turned off.

The practical consequence for your analysts is a new first question in every investigation. Before AI, suspicious activity running under a user's account without their knowledge usually meant the machine was under someone else's control. Now the same alert may mean the user typed a prompt and walked away.

Alert Fatigue, Data Exposure and Governance Gaps

The composition of AI-related alerts is what drives cost, and it is lopsided. Intezer's classification put 94.1% in the noise bucket, 5.8% as genuine security risk, and 0.02% as real attacks. For your SOC that ratio means the overwhelming majority of analyst time spent on AI activity produces no finding at all.

In environments running automated triage, 79.8% of these alerts received a benign verdict and 81.7% were closed automatically without an analyst ever opening them. Only 5.4% reached a human. If your team triages manually, those suppressed alerts are not disappearing, they are sitting in your queue, and each one is a process tree that takes real time to walk.

The more expensive consequence is what habituation does to judgment. Once your analysts have closed enough memory-dump and reverse-shell alerts as "that's just the coding agent," the same techniques executed by an actual intruder get the same quick dismissal. Intezer found genuine exposures sitting inside that noise: an AI code editor that spawned PowerShell to launch ngrok and open a named reverse tunnel to the public internet using the user's own auth token, and an agent that ran security dump-keychain > /tmp/ to retrieve one token, writing every stored macOS secret to a temp file in the process. Neither was an attack. Both created exposure your incident responders would want to know about.

The quieter half of the problem rarely touches endpoint tooling at all. Intezer observed OAuth application consent granted to ChatGPT across multiple tenants, "first sign-in to a new application" events for OpenAI, and at one customer a sizeable cluster of data-protection alerts for generative-AI uploads. When an employee grants that consent, your corporate data starts flowing to a third-party processor through an API, and your EDR has no visibility into what left.

That creates governance questions your legal and compliance teams will eventually have to answer, usually during an audit rather than in advance:

• Which AI vendors hold standing OAuth grants against your tenant, and who approved them?
• Does the consumer tier your staff signed into permit retention of prompts for model training, and does your contract with clients allow that?
• Where is the processing happening, and does that satisfy the data residency commitments you made to customers in regulated jurisdictions?

Shadow AI adoption moves faster than policy drafting, which is why most organizations discover the answers after the data has already moved. If you operate in healthcare, financial services, or legal, source code, client files, and contract terms sent to an unapproved processor are a disclosure question, not just a hygiene one.

There is also an attribution problem that changes how you read your own logs. AI tools execute commands on the user's machine with the user's credentials, so alerts are attributed to the employee, and in many cases the employee had no idea the action happened. Before agents, unexplained activity under a user account was a strong indicator that someone else had control of the machine. That inference no longer holds on its own.

Finally, the AI brand names your staff now trust are being used as phishing pretext. Intezer documented an invoice fraud lure referencing a supposed Anthropic engagement approval to justify a large payment request, a fake Gemini Ads workspace invitation sent from gemini-advertisers[.]com, and an "OpenAI Partner Summit 2026" invitation delivered through legitimate zoom.us infrastructure. Those land with your finance and operations staff, not your developers.

Tuning Detection for Claude, Codex and Cursor

Inventory which endpoints are running coding agents before you touch a single detection rule. Without that list, your tuning suppresses alerts blindly, and a keychain dump gets closed as benign. The order below maps to the NIST Cybersecurity Framework functions.

Identify

Pull a software inventory keyed on the install paths these tools actually use, then map each installation to a named owner and a business justification. Baseline the normal parent-child chains per client: a signed agent binary spawned by node.exe, PowerShell called from an editor sandbox, Python started from a project directory. You need those known-good trees documented before they become exceptions, because an exception you cannot describe is an exception you cannot review.

Protect

Run agents inside an isolated environment with restricted reach, such as a Docker container or a dedicated virtual machine. Isolation does two things at once: it keeps the agent away from credential stores and sensitive files it was never meant to touch, and it separates the agent's behavior from the user's own activity in your telemetry. Where developers insist on running agents with permission prompts disabled, require a harness that programmatically blocks risky commands before execution.

Pair that with egress controls. Block or alert on tunneling utilities reaching the public internet from developer endpoints, and write DLP rules that cover source code, private keys, and token files leaving to third-party model endpoints.

Detect

Enable command-line auditing and PowerShell script block logging on every endpoint in the inventory. Without full command lines you cannot tell the difference between benign orchestration logic and a real reverse shell, and the two produce identical process trees. Then rewrite your allow-list logic:

• Key exceptions on signed binary path plus user context plus parent process, never on process name alone. A rule that trusts anything named for a coding agent is a rule an attacker can satisfy by renaming a file.
• Keep credential-access detections at full severity regardless of parent. Process memory dumping via comsvcs.dll MiniDump and the macOS security dump-keychain pattern stay high priority even when an agent invoked them, because the exposure is the same either way.
• Alert specifically on agent processes spawning credential-adjacent children, opening named tunnels with a user's own auth token, or launching with --yolo or --dangerously-skip-permissions. Hunt for those flags on a schedule instead of waiting for a detection to fire.
• Capture outbound API destinations from developer hosts so you can tell an approved model provider from an unapproved one.

OAuth consent grants and first sign-in events for new AI applications never touch endpoint tooling at all. In environments Capstone manages, Adlumin watches those identity events, so a consent grant that hands a third-party application standing access to mailbox or file data surfaces as an identity finding rather than disappearing into tenant logs.

Respond

Add one question to the front of your triage runbook: was this action taken by a human or by an agent acting with that human's credentials? Confirm it against the process tree and the agent's session before you escalate as account compromise. That single step removes most of the wasted investigation time.

Recover

Publish an AI tooling policy with an approved client list, sanctioned model endpoints, and a rule that permission-bypass flags require a harness. Review your suppression rules monthly against new agent versions, since installer and update behavior changes with each release.

Establishing a Baseline Before Expanding AI Use

The change enterprise AI adoption has made to your security operations is quieter than a new attack technique. Commands still arrive under a user's account, from a user's machine, with that user's permissions, but the person named in the alert may not have known the action happened. Your first investigative question has shifted from "did an attacker take this machine" to "was this a person or an agent."

Answering that question quickly depends entirely on whether you wrote down what normal looks like beforehand. The single most valuable thing you can do is document legitimate AI assistant behaviour on your managed endpoints while the footprint is still small enough to describe accurately: which agents are installed, who runs them, what process chains they produce during ordinary work, and what outbound activity is expected. That record is what lets an analyst separate a developer's debugging session from a genuine credential-access event.

The reason to build it before adoption widens is practical. Every additional team that picks up an agent adds new behaviour to the baseline, and reconstructing normal after the fact is slower and less reliable than capturing it as it appears. A SOC that never establishes that reference point ends up treating agent activity as uniformly suspicious, which buries the small number of alerts that reflect real exposure.

AI use inside your organization will keep producing activity that resembles intrusion tradecraft, because functionally it is the same activity performed for different reasons. Knowing which of your endpoints run agents, and what those agents normally do there, is what keeps the difference legible to the people reading your alerts.