Where AI-IDE threats actually live: telemetry beyond the dark web

Defenders trying to monitor the AI-IDE threat surface — Cursor, Windsurf, the VS Code agent ecosystem, OpenVSX-distributed extensions — point dark-web sweeps at it and get clean negatives. The mistake is concluding the threat doesn't exist. It does. It just isn't on .onion. The threat is going through the legitimate marketplace, the legitimate registry, the legitimate dependency tree, and the legitimate repository. That's where the telemetry needs to be.

The wrong instrument

Pointing dark-web monitoring at the AI-IDE threat surface is a reasonable first instinct on a new threat class. Existing pipelines, existing sources, established alerting. The result is a clean negative: no broker pricing, no commodity exploit-kit packaging, no measurable trade volume in the criminal market. Empty.

The public record from the last fourteen months tells a different story. GlassWorm propagated malicious extensions through OpenVSX via a compromised maintainer account. SleepyDuck shipped a RAT in a VSX extension that uses Ethereum smart contracts as a sinkhole-resistant C2. A "vibe-coded" VS Code extension shipped through the legitimate marketplace with built-in ransomware. A critical OpenVSX registry flaw exposed millions of developers. An OpenVSX pre-publish bypass let malicious extensions reach the store. An audit of 100+ VS Code extensions exposed developers to hidden supply-chain risk. The Rules File Backdoor poisoned .cursorrules and .windsurfrules. Malicious npm packages with Cursor-specific install hooks backdoored 3,200 users. Cursor IDE itself accumulated nineteen CVEs in eight months.

The dark web is empty because the threat isn't going through the dark web. It's going through the legitimate channels. That's where the telemetry needs to be.

Where AI-IDE threats actually live

Four telemetry surfaces, in roughly decreasing order of how much you'd catch by watching them: extension marketplaces, repository-level signals, build-time signals, and AI-agent runtime sandboxes.

1. Extension marketplaces (VS Code Marketplace, OpenVSX)

This is the first place a malicious extension touches your users. The attack pattern is consistent across GlassWorm, SleepyDuck, and the vibe-coded ransomware extension: an attacker either compromises an existing publisher account or registers a new one with a plausible-looking name, publishes an extension that performs whatever its description says it does plus the malicious payload, and waits for installs.

• New versions from dormant publishers — publishers who haven't published in 90+ days suddenly shipping an update is a high-base-rate suspicion signal. The compromised-maintainer pattern fingerprints here.
• Unusual capability sets — full filesystem access, network egress to non-marketplace domains, child-process spawn rights. Capability requests are declared in package.json; you can audit them before installation.
• JavaScript that resolves URLs from on-chain sources — Ethereum smart contracts, IPFS, blockchain RPC endpoints. SleepyDuck used this; the pattern is fingerprintable in the extension's bundled JS.
• Postinstall and activation hooks that touch credential paths — ~/.ssh, ~/.aws, ~/.npmrc, ~/.config/gh, OS keychain APIs, browser cookie databases. Almost never legitimate for an IDE extension.
• Network egress in the extension's first 60 seconds of activation, to destinations that aren't the extension's declared backend. Out-of-distribution egress is the cleanest single signal you can collect.

Collection: subscribe to marketplace publish feeds (both VS Code Marketplace and OpenVSX expose them). Run static analysis on the bundled JS and package.json of every new publish. Run dynamic capability tracing in a throwaway sandbox on a sampled fraction. The signal-to-noise on capability tracing is high enough that you can alert on the unusual cases directly.

2. Repository-level signals

The Rules File Backdoor demonstrated that the malicious payload can sit in the repository the agent is instructed to operate on. .cursorrules, .windsurfrules, .github/copilot-instructions.md, devcontainer.json, .vscode/tasks.json, .devcontainer/Dockerfile — all of these are files the agent reads as instructions, and any of them can be modified to redirect the agent's behavior.

• Modifications to rules files by non-human committers. Bots and automated scripts modifying .cursorrules / .windsurfrules / instructions markdown is almost always wrong.
• New files in .github/workflows/ with permissions that exceed apparent purpose — id-token: write, contents: write, packages: write on a workflow that says it's just running tests.
• VS Code task and launch config additions — modifications to .vscode/tasks.json and .vscode/launch.json that introduce new shell-out commands. These run in the developer's shell context with the developer's credentials when the IDE opens the workspace.
• Devcontainer postCreateCommand and postStartCommand additions. Same risk profile as npm postinstall, but at container start instead of package install.

Collection: treat these files like .github/workflows/*.yml — security-sensitive configuration that requires explicit review. CI hook on PR open that diffs the rules-file content and requires a human-approved label before merge. Most orgs already have this pattern for workflow files; extend it.

3. Build-time signals

Every npm install is a code-execution event. The recent npm registry compromise (CVE-2026-12091) made this concrete with a 38-million-weekly-downloads compromise, but the pattern was true before the CVE was disclosed and will be true after the patch ships.

• Postinstall and preinstall scripts that touch credential paths or perform network egress. Most packages have neither; the ones that do are the high-value audit set.
• Lockfile diffs pulling in versions from compromised windows. One-time scan against the published list of bad versions, but worth doing across every active repository.
• Postinstall scripts running outside the build's nominal host. If your CI runs npm install in container A and the postinstall script tries to reach the cloud metadata service from container A, that's evidence of attempted credential theft.
• New postinstall script content in dependency updates. Mass changes to a previously-stable script are suspicious.

Collection: instrument your CI runner to log all postinstall and preinstall commands and outbound network attempts during install. Most CI vendors expose audit logs sufficient for this. For local developer machines, the most defensible answer is "developers should run npm install inside a sandboxed container with no credential mounts," which most orgs are not yet doing but should be.

4. AI-agent runtime sandboxes

Once an agent is running on your infrastructure, the question is what it can reach. This is the runtime equivalent of the marketplace question — you've passed the perimeter, now watch what happens inside.

• Cloud-API calls from agent sandboxes that don't match a user-dispatched task. An agent asked to refactor a TypeScript file should not be calling iam:GetUser or reading the cloud metadata service.
• kubeconfig reads, Docker socket access, and credential-path reads from agent processes. These are confused-deputy fingerprints.
• Outbound network connections to destinations outside the agent's allowed set — package registries, model registries, the LLM API endpoint. Anything else is suspicious by default.
• Privilege-escalation patterns inside the sandbox — setuid binary execution, kernel module probes, container-escape primitives.

Collection: runtime security tooling on the host or per-pod (eBPF-based runtime sensors are the standard answer). Signal volume is moderate; the false-positive rate is manageable if you scope alerting tightly to the credential-path-read and out-of-task-cloud-API patterns specifically.

Detection-engineering rollout order

The work split among the four sources is roughly: marketplace ingestion is highest-leverage (one pipeline catches every malicious extension before it reaches a single user). Repository signals are medium-leverage and easy wins (most controls extend existing PR-review hygiene). Build-time signals are medium-leverage and require CI integration. Runtime sandbox monitoring is high-leverage but expensive — required if you run agents in production with real privileges, less critical if your agents are toy assistants.

A reasonable rollout order for an org starting from zero is marketplace ingestion first, repository hooks second, CI install instrumentation third, runtime sandbox monitoring fourth. The first two have low setup cost and high coverage; the last two require infrastructure investment that should be informed by what the first two are catching.

What to retire

Pointing dark-web monitoring at the AI-IDE threat surface is not wrong, but it's not where the signal is. Keep the dark-web pipeline running for what it's good at — credential leakage, infostealer harvests, ransomware leak sites, broker price sheets for commoditized exploit kits. Add the four telemetry sources above for AI-IDE specifically. Don't expect the dark-web pipeline to fire on this bug class; the criminal market hasn't picked it up because the criminal market doesn't need to. The attacker can publish to OpenVSX directly.

The right detection-engineering posture for AI-IDE in 2026 is to assume the threat is going through legitimate channels, build telemetry for those channels, and treat the dark-web absence as confirmation that you're looking in the right places — not as evidence that there's nothing to look for.

For the contrasting case — what dark-web crossing actually looks like when the bug class supports commoditization — see the CopyFail time-to-criminalization analysis. A Linux page-cache LPE with the right reliability properties showed up on a carding forum's Exploits section seven days after disclosure. Same pipeline, opposite shape. The two outcomes together describe what the dark-web sensor is measuring and what it isn't.