AISecOps detection note 01
Nine of Fourteen Behaviors, Two That Alert
CrowdStrike found viable detection signals for nine of fourteen SANDWORM_MODE behaviors, but only two were reliable enough to alert. The result shows where behavioral detection weakens and where provenance still helps.
CrowdStrike investigated fourteen behaviors used by an AI-toolchain worm. Nine could produce some detection signal. Only two met the fidelity threshold for customer-visible alerts.
Five produced no viable signal in the investigation.
That does not mean endpoint detection is useless. It means a coding environment has begun to normalize many of the actions an attacker wants to hide inside: shell execution, file changes, dependency installation, environment-variable reads, repository access, network calls, and tool configuration.
The SANDWORM_MODE analysis is unusually candid about the gap between an attack behavior, an observable event, and an alert an analyst can act on.
That gap is worth measuring in every AI-assisted development environment.
The worm is less interesting than the coverage math
Socket first reported SANDWORM_MODE in February 2026. CrowdStrike describes a campaign spanning nineteen malicious npm packages published through two aliases.
The worm used several stages:
- an obfuscated loader triggered on package import;
- delayed execution intended to outlive short telemetry windows;
- persistence through rogue MCP server configuration;
- collection of LLM provider keys, developer credentials, password-manager data, local notes, messages, and clipboard history;
- several exfiltration paths;
- destructive behavior if propagation and theft both failed.
The campaign targeted the trust relationships inside AI-assisted development. It modified configuration for tools such as Claude Desktop, Cursor, VS Code, and Windsurf so a rogue MCP server would appear to be a trusted provider.
The individual techniques are not all new. Delayed execution, credential theft, configuration tampering, data exfiltration, and destructive fallback have long histories. What changes is the environment around them. Coding assistants and CI systems legitimately perform broad, user-directed operations, often with access to repositories, build credentials, package registries, and external services.
CrowdStrike’s most useful finding is the ratio:
| Coverage stage | Behaviors |
|---|---|
| Investigated | 14 |
| Produced some viable signal | 9 |
| Met the customer-alert fidelity threshold | 2 |
| Produced no viable signal in the investigation | 5 |
That is not a universal score for every endpoint product. It is one vendor’s analysis of one campaign. It is still a good template for measuring local coverage.
Why ordinary anomaly rules weaken
Detection engineering often looks for a seam between normal work and malicious work. AI-assisted development can make that seam harder to see.
The parent process is already powerful
A coding assistant may spawn shells, edit files, run package managers, execute tests, read configuration, and call network services as part of its ordinary job.
A rule that treats any one of those actions as suspicious will generate noise. A rule that allows all of them gives an attacker room to blend in.
Machine-scale volume is normal
A developer touching forty files and launching twelve processes in ninety seconds once looked unusual. An agent performing a repository-wide refactor may do that legitimately.
Volume still matters, but the baseline has to distinguish among a human terminal, an interactive assistant turn, an autonomous loop, a CI job, and an unknown process. One threshold cannot describe all of them.
Agent attribution is often missing
At the operating-system layer, a command proposed by a model and approved by a user can look identical to a command selected autonomously. The process tree may show the same application and the same developer identity.
Useful telemetry needs to preserve:
- the initiating user or service;
- the assistant and model version;
- the conversation or task identifier;
- whether the action was directly requested, proposed for approval, or selected autonomously;
- the tool name and normalized arguments;
- the credential and authorization decision used for the effect.
If those fields do not exist, detection cannot reliably use them.
CI makes dangerous behavior look routine
A pipeline installs dependencies, reads secrets, calls source-control APIs, produces artifacts, and pushes releases. Those actions are expected inside the job.
An attacker who compromises the job may not need a strange parent process or an unusual command. The more useful questions become whether the dependency, destination, credential, repository, and release action match the declared job.
Where useful signal survives
Behavior is not the only source of detection context.
Packages have registry histories. Credentials have issuers and scopes. Repositories have ownership and signing patterns. Network destinations can be compared with declared dependencies. MCP servers have identities, configuration sources, and expected tool sets.
These external reference points make several stronger checks possible:
- a package was published after an assistant first recommended its name;
- an install bypassed the approved registry or pull-through proxy;
- a workload identity was used by an undeclared consumer;
- a build contacted a destination outside its dependency and telemetry allowlist;
- an MCP server appeared without an approved configuration change;
- a release was signed by an identity not previously used for that repository;
- a lockfile changed its resolution source;
- an agent read a credential unrelated to its declared task.
None of these signals is perfect. Package accounts can be compromised. Signatures can be stolen. Approved destinations can turn malicious. Provenance is a more stable reference point, not an invulnerable one.
The broader lesson is to compare activity against declared authority and origin, not only against an average process pattern.
Build a baseline for the assistants you actually run
A generic industry baseline cannot describe one organization’s models, tools, repositories, and delivery paths.
Start by instrumenting representative legitimate work.
Capture normal sessions
Run controlled examples such as:
- a dependency update;
- a repository-wide refactor;
- a test-and-fix loop;
- generation of a new service;
- an MCP-assisted documentation task;
- a CI build and release.
Record endpoint, network, identity, source-control, package, and agent tool-call telemetry. The result is a benign corpus tied to known tasks.
Replay relevant attack behaviors
Use an isolated environment to test the SANDWORM_MODE behaviors that apply locally. Measure three separate outcomes:
- Did the control prevent the behavior?
- If it ran, did any usable telemetry appear?
- Did the telemetry produce an alert someone would act on?
“An analyst could find it during a retroactive hunt” is not the same as alert coverage.
Publish the miss list
The missing signals should not remain inside the detection team.
A behavior that cannot be distinguished at runtime may need a preventive control owned by the developer platform, identity, network, or package-security team. The miss list defines where monitoring alone is carrying too much responsibility.
Track the ratio over time. The value is not matching CrowdStrike’s number. It is showing whether local prevention, telemetry, and alerting are improving.
When detection cannot decide, move the control
Some questions become easier when the architecture restricts the possible answer.
Limit the toolchain
An assistant that can install only through an approved proxy, call only registered tools, and reach only declared destinations has fewer invisible paths available.
This is the same least-agency argument used in Zero Trust Is the Foundation AI Agents Need. Narrow authority does not require a detector to classify every request correctly.
Check package provenance before installation
Registry allowlists, signatures, attestations, maintainer history, and risk-based age policies can stop a questionable dependency before its code runs.
Five Models, One Hallucination describes one concrete version of this problem: several models producing the same names for packages that did not exist. The right place to decide whether those packages are allowed is the package path, not an endpoint alert after installation.
Separate assistant identity from developer identity
An agent should not automatically receive every permission available in the developer’s session.
Where possible, issue a short-lived credential for the named task, repository, and operation. A stolen credential is still a problem, but a narrow credential creates a smaller blast radius and a clearer expected-use envelope.
Restrict build egress
A build job’s authority should cover what it needs to fetch and publish, not every destination on the internet.
Default-deny egress with explicit dependency, source-control, artifact, and telemetry routes makes an unexpected destination a policy decision instead of a behavioral guess.
Govern MCP configuration
SANDWORM_MODE used rogue MCP server configuration as persistence and as a path into assistants.
Treat MCP configuration as code:
- store approved definitions in a controlled repository;
- require review for additions and scope changes;
- monitor local configuration files for drift;
- authenticate the server;
- verify its provenance and version;
- constrain what credentials and data the server can access;
- alert when an assistant loads an unregistered provider.
A tool description is metadata. It is not proof that the tool is safe.
What to do this quarter
Four actions would make the CrowdStrike result useful rather than merely alarming.
- Measure local coverage. Select applicable behaviors and record prevention, telemetry, and alert outcomes separately.
- Add agent attribution. Determine whether tool-call records can distinguish a user request, approved proposal, and autonomous action.
- Move one blind spot into prevention. Package provenance, MCP registration, credential scope, or build egress are practical starting points.
- Retest old detections. Parent-process and volume rules may still help, but they need to be tested against legitimate agent workloads and tuned by execution mode.
The result should not be a promise to detect every malicious command. It should be a map showing which actions are impossible, which are observable, which alert, and which remain accepted risk.
SANDWORM_MODE is useful because it exposes a basic problem. AI-assisted development environments are designed to perform unusual operations on a developer’s behalf. Detection based only on unusualness has less room to work.
Detection grounded in identity, origin, declared authority, and provenance has more.