A Python package on PyPI called elementary-data, with over 1 million downloads per month, has suffered a supply chain security attack sourced through a GitHub Actions attack vector.

TL;DR

| | | | — — | — — | | Advisory | SNYK-PYTHON-ELEMENTARYDATA-16316110 | | Severity | Critical (CVSS v4.0: 9.3) | | Affected package | elementary-data==0.23.3 | | Clean versions | All versions except 0.23.3; upgrade to 0.23.4 | | Attack type | Supply chain (GitHub Actions CI/CD injection, then credential-stealing package) | | Stolen credentials | dbt profiles, Snowflake/BigQuery/Redshift creds, AWS/GCP/Azure keys, API tokens, SSH keys, .env files | | Scope | The PyPI CLI package and a Docker Image got compromised; Elementary Cloud and the Elementary dbt package were not affected | | Detection marker | $TMPDIR/.trinny-security-update (Linux/macOS), %TEMP%\.trinny-security-update (Windows) | | Disclosure | April 25–26, 2026 |

What is elementary-data?

elementary-data is a dbt-native data observability CLI tool used by data and analytics engineers to monitor pipeline health, detect anomalies, and track test failures across data warehouses like Snowflake, BigQuery, Redshift, and Databricks. The package sees roughly 280,000 downloads per week and over 1.1 million per month, placing it firmly in the tier of widely adopted data tooling.

The package provides integrations with most major cloud data platforms, which is precisely what made it an attractive target. A tool that routinely handles connections to Snowflake, BigQuery, and AWS at CI/CD runtime is one that sits next to a lot of valuable credentials.

How the attack unfolded

The compromise occurred in two stages: first, compromising the publication pipeline; second, publishing malicious content that steals further credentials. It’s worth noting that this security incident for the elementary-data package compromise is one of the most prominent vectors recently exploited by TeamPCP and other threat actors.

Stage 1: GitHub actions script injection

On April 24, 2026, at 22:10 UTC, an attacker using a two-day-old GitHub account (realtungtungtungsahur) posted a crafted comment on PR #2147 in the elementary-data repository. The comment exploited a script injection flaw in .github/workflows/update_pylon_issue.yml, a workflow that handled issue/PR comment events.

The vulnerable run: block directly interpolated ${{ github.event.comment.body }} into a shell script before bash parsing occurred. Because this expression is expanded at workflow-template time rather than sanitized as a string argument, injecting shell metacharacters or subcommands through the comment body allows arbitrary code execution in the runner. When the workflow triggered, the attacker's payload ran with the repository's GITHUB_TOKEN in scope.

Critically, the attacker never needed direct write access to the repository. The GITHUB_TOKEN available to the runner had sufficient permissions to create commits, push tags, and dispatch other workflows. The injected handle_comment job stayed active for two hours and forty-six minutes, giving the attacker an extended window to set up each subsequent stage.

Using the stolen token, the attacker forged a release commit with hash b1e4b1f3aad0d489ab0e9208031c67402bbb8480. The commit was structured to look automated and official: it was an orphan commit (unreachable from any branch), authored as github-actions[bot], carried a forged "Verified" PGP signature, and used the message release/v0.23.2 (#2188) — copied verbatim from a legitimate PR merged nine days earlier. The attacker tagged this orphan v0.23.3 and then dispatched the repository's own Release package workflow with tag=v0.23.3 as input. That workflow's checkout step used ref: ${{ inputs.tag || github.ref }}, so it was built directly from the malicious orphan commit without touching master. The legitimate CI/CD pipeline packaged and published the malicious code. By 22:20 UTC, elementary-data==0.23.3 was live on PyPI. A compromised Docker image (ghcr.io/elementary-data/elementary:0.23.3 and :latest, digest sha256:31ecc5939de6d24cf60c50d4ca26cf7a8c322db82a8ce4bd122ebd89cf634255) followed four minutes later.

This attack vector has appeared repeatedly in the PyPI ecosystem. The Ultralytics supply chain attack in December 2024 used the same pull_request_target injection pattern to steal credentials and publish four malicious versions. The LiteLLM compromise in early 2026 took a slightly different path (a poisoned third-party GitHub Action), but the destination was identical: stolen PyPI tokens used to publish a credential-stealing package.

Stage 2: The malicious package

The attacker embedded the malicious payload in a file named elementary.pth, included in the package's site-packages directory.

.pth files are Python path configuration files that site.py, Python's startup module, processes automatically when the interpreter launches. Any line in a .pth file that begins with import is executed as Python code at interpreter startup, before your own code runs. This means the malware activates any time Python starts on the affected system, including during pip install operations, not just when a user explicitly imports elementary.

This technique was also used in the LiteLLM v1.82.8 compromise. It is more persistent and harder to detect than embedding malicious code in __init__.py because it does not require the victim to import the poisoned package. Installing it is sufficient.

Inside the payload: What the malware did

The embedded code in elementary.pth was a credential stealer with three stages of encryption: a base64 outer wrapper, then XOR encryption keyed from an MD5 keystream (seed: swabag), then a second XOR decryption layer. The obfuscation is not sophisticated by modern malware standards, but it is deliberate — it prevents trivial string-based detection of the payload and increases the time required to analyze what the package is actually doing.

Once Python started on an affected machine, the decoded payload:

1. Harvested credentials and secrets across the filesystem, targeting a broad set of material:

• dbt profiles (~/.dbt/profiles.yml) and data warehouse credentials (Snowflake, BigQuery, Redshift, Databricks).
• Cloud provider credentials: AWS ~/.aws/credentials plus live role credentials fetched from the IMDSv2 metadata endpoint, with direct SigV4-signed calls to AWS Secrets Manager and SSM Parameter Store; GCP application_default_credentials.json; Azure ~/.azure/ directories.
• SSH private keys (id_rsa, id_ed25519, ~/.git-credentials).
• Container and orchestration secrets: ~/.docker/config.json, ~/.kube/config, all /etc/kubernetes/*.conf files, Kubernetes ServiceAccount tokens.
• Package manager credentials: ~/.npmrc, ~/.pypirc, ~/.cargo/credentials.toml.
• Other secrets at rest: .env* files (scanning up to six directory levels deep), ~/.vault-token, ~/.netrc, ~/.pgpass, ~/.my.cnf, API tokens in environment variables.
• Cryptocurrency wallet files (Bitcoin, Litecoin, Dogecoin, Zcash, Dash, Monero, Ripple, Ethereum, Cardano, Solana validator keypairs).
• System files: /etc/passwd, /etc/shadow, shell history files, /var/log/auth.log.

1. Packed all collected material into an archive named trin.tar.gz, then exfiltrated it via curl --data-binary to the C2 server at igotnofriendsonlineorirl-imgonnakmslmao.skyhanni.cloud, using the HTTP header X-Rise-To-The-Trinny: agree.
2. Left a marker file at $TMPDIR/.trinny-security-update (Linux/macOS) or %TEMP%\.trinny-security-update (Windows), indicating the malware executed at least once.

The scope of credentials goes well beyond dbt and data warehouses. The payload is broadly written to sweep whatever secrets are accessible on the machine, including Kubernetes clusters, infrastructure secrets managers, and cryptocurrency keys. The dbt and warehouse targeting make it relevant to the tool's user base, but anyone running this on a developer machine or CI runner stands to lose considerably more.

The credential profile is well-matched to the tool’s typical users. Data engineers running the elementary-data CLI are almost certainly using it against a connected data warehouse, with cloud provider credentials, often in a CI/CD environment where those credentials are stored as secrets or environment variables. This is a targeted attack, not a generic spray.

Impact and scope

The attack window ran from April 24, 22:20 UTC (when the package appeared on PyPI) until the package was removed on April 25, between 8:51 and 11:51 UTC, after community members flagged the issue at 6:18 UTC. That is roughly eight to ten hours of exposure.

Anyone to whom the following applies should assume the malware has executed and that their credentials have been exfiltrated:

• ran pip install elementary-data or upgraded during that window,
• used a Docker image pulled from the elementary-data registry between April 24, 22:24 UTC and removal,
• or had a CI/CD pipeline that automatically pulled the latest version

Elementary Cloud and the Elementary dbt package were not affected, and no other CLI versions contained the malicious code.

Detection: Are You Affected?

Step 1: Check your installed version

pip show elementary-data

If the output shows Version: 0.23.3, your environment was exposed.

Step 2: Check for the execution marker

The malware writes a marker file on execution:

# Linux / macOS (checks $TMPDIR, which defaults to /tmp if unset)
ls -la "${TMPDIR:-/tmp}/.trinny-security-update"

# Windows (PowerShell)
Test-Path "$env:TEMP\.trinny-security-update"

The presence of this file means the credential-stealing code ran in that environment. Its absence does not guarantee safety; the malware may not have written the marker in all execution paths, or the temp directory may have been cleared.

Step 3: Review with Snyk

To check your Python dependencies for this and other known malicious or vulnerable packages:

# Scan your project dependencies
snyk test --file=requirements.txt

# Or for pip-based environments
pip freeze > requirements_check.txt && snyk test --file=requirements_check.txt

Snyk’s vulnerability database includes SNYK-PYTHON-ELEMENTARYDATA-16316110 and will flag any environment still pinned to 0.23.3.

Note: We recommend you review our Python security best practices cheat sheet and write-up on Best practices for containerizing Python applications with Docker to practice secure development guidelines.

Remediation

1. Upgrade immediately

pip install --upgrade elementary-data

Version 0.23.4 was published on April 25, 2026, and contains no malicious code.

If you are using a requirements.txt or pyproject.toml, update the pin:

elementary-data>=0.23.4

2. Rotate all credentials that may have been exposed

Treat any credentials accessible to Python processes on affected machines as compromised. Specifically:

• dbt profiles: Rotate warehouse passwords and OAuth tokens in ~/.dbt/profiles.yml.
• Cloud provider keys: Rotate or revoke AWS IAM keys (and check Secrets Manager and SSM Parameter Store for accessed values), GCP service account keys, Azure service principals.
• Kubernetes: Rotate ServiceAccount tokens, and audit any /etc/kubernetes/*.conf files that were accessible.
• Container registries: Rotate credentials stored in ~/.docker/config.json.
• Package manager tokens: Rotate ~/.npmrc, ~/.pypirc, ~/.cargo/credentials.toml tokens.
• Secrets managers: Rotate HashiCorp Vault tokens (~/.vault-token) and any .netrc, .pgpass, or .my.cnf credentials.
• SSH keys: If private keys were present on the machine, consider them exposed and rotate them.
• CI/CD secrets: If the affected machine was a CI runner, rotate all secrets stored in that environment.

Rotation alone is not sufficient. Review access logs for the exfiltration domain igotnofriendsonlineorirl-imgonnakmslmao.skyhanni.cloud and for any of your services to detect unauthorized access that may have already occurred.

3. Clear Python caches

# Remove any cached .pth files or bytecode
pip cache purge

# Find and remove any elementary.pth artifacts
find / -name "elementary.pth" 2>/dev/null

4. Pull clean Docker images

The compromised image (ghcr.io/elementary-data/elementary:0.23.3 and :latest) carried digest sha256:31ecc5939de6d24cf60c50d4ca26cf7a8c322db82a8ce4bd122ebd89cf634255. The last known-clean image is 0.23.2 at digest sha256:b3bbfafde1a0db3a4d47e70eb0eb2ca19daef4a19410154a71abee567b35d3d9. Pull a clean image built after April 25, 2026:

docker pull ghcr.io/elementary-data/elementary:latest

Verify you are not running a cached copy of the compromised image:

docker images ghcr.io/elementary-data/elementary --digests

5. Audit your GitHub Actions workflows

If you maintain Python packages, this incident is a prompt to audit any workflow that processes issue or PR comment events. The specific pattern to search for is unquoted context expressions interpolated directly into run: blocks:

# Vulnerable: ${{ github.event.comment.body }} expands before bash parses the command
- run: echo "Comment: ${{ github.event.comment.body }}"

# Safe: pass untrusted input through an environment variable
- run: echo "Comment: $COMMENT_BODY"
  env:
    COMMENT_BODY: ${{ github.event.comment.body }}

Snyk’s post on GitHub Actions vulnerabilities and the TJ Actions compromise analysis covers the broader patterns to look for.

Beyond sanitizing inputs, the more durable fix is to remove long-lived PyPI API tokens from your workflow secrets entirely. PyPI supports Trusted Publishers, which use short-lived OIDC tokens scoped to a specific workflow on a specific repository — tokens that cannot be exfiltrated and reused. The elementary-data attacker needed a long-lived secret to publish; Trusted Publishers eliminate that attack surface. Also, keep privileged release workflows behind manual approval gates that require human confirmation before the publish step runs.

The repeating pattern

This attack follows a now-familiar playbook: find a gap in a project’s GitHub Actions configuration, inject code that steals the PyPI publishing token, use that token to publish a malicious version, embed a .pth file or similar startup hook to maximize reach.

The same pattern appeared in the Ultralytics attack (December 2024, pull_request_target branch injection, cryptocurrency miner), the LiteLLM attack (early 2026, poisoned Trivy action, credential stealer with persistent backdoor), and the Cline/Clinejection incident (AI-assisted prompt injection into Actions, stolen tokens).

The pattern is not novel. The tooling to exploit it is well-understood and appears to be in active, repeated use. For package maintainers, the priority is workflow hardening: restrict the use of pull_request_target, require manual approval for release workflows, use short-lived OIDC tokens for PyPI publishing instead of long-lived API tokens, and implement branch protection rules to prevent unauthorized release triggers.

For elementary-data users, the Elementary team responded quickly: from community report to initial remediation was under four hours, and the team published a full incident report. That response tempo is worth noting alongside the incident itself.

In the modern software development lifecycle, the speed of innovation is often at odds with the security of our most sensitive data. As organizations embrace cloud-native development and AI-generated code, they face a phenomenon known as “secret sprawl”, aka, the uncontrolled and widespread distribution of API keys, passwords, and tokens across repositories, CI/CD logs, and developer collaboration tools.

However, the challenge has evolved beyond static credentials. We are entering a new phase of AI adoption where autonomous, stateful agents are not just writing code; they are executing workflows, connecting to Model Context Protocol (MCP) servers, and operating applications at machine speed. Secrets are no longer just accidentally exposed; they are now generated and executed by agents. An AI agent might be tasked with setting up a server, and while completing this task, it creates its own temporary secrets or access keys to talk to other services.

This process allows AI to go far beyond “knowing” the password — it uses it to log in, move data, or change settings without a human ever seeing the password. Without a human-in-the-loop, AI that is poorly programmed or “hallucinates” may create a key that is too powerful or leave a backdoor open. Every agent is, by design, a consumer and executor of secrets.

An invisible and autonomous attack surface

Traditional security has often been a “checkbox” feature that is noisy, reactive, and disconnected from the developer’s workflow. This leads to critical frustrations, exacerbated by the growing presence of AI:

• Alert fatigue: Legacy engines produce high rates of false positives, while public-facing AI agents can be manipulated via prompt-injection to perform unsafe actions, such as confirming legally binding offers for pennies.
• Dire lack of visibility: 72% of organizations struggle to maintain visibility of embedded AI. Developers are integrating “Shadow AI” — unapproved agents and third-party tools — without security oversight
• Reactive remediation: Once a secret is leaked or an autonomous agent deletes a production database, the cost of recovery is catastrophic. The ServiceNow Bodysnatcher incident exploited insecure configurations in hardcoded secrets and was known as “the most severe AI-driven vulnerability to date”.

The result is clear: exposed credentials and untrusted agentic development represent a unified front of risk that traditional AppSec was never designed to manage.

Building a comprehensive picture of risk to power holistic AI security governance

Before organizations can move fast with AI, they need a stable foundation built on visibility. Risk must be discovered before it can be prioritized and remediated. Traditional application security scanning across your proprietary code (SAST) and open source repositories (SCA) is no longer enough. AppSec teams are fighting a two-front battle between risk originating within AI itself (models and artifacts), as well as a drastically increased speed in which risk can be discovered by threat actors using AI to power their own discovery.

Snyk is built on best-in-class security engines across SAST, SCA, DAST, and more — validated by leading analysts and trusted at enterprise scale. Throughout our history, we’ve understood the need for AppSec teams to have a complete picture of risk, evidenced most recently in our release of Evo AI-SPM to extend visibility further left into AI models and artifacts. This principle has guided our journey to deliver holistic AppSec governance to our customers. This very principle is why we’re so excited to share our vision for the future of Secrets detection.

Our vision: Total visibility and proactive prevention

Snyk Secrets isn’t just another scanner; it is an integrated platform play designed to bridge the gap between code and commit. Our goal is to empower developers to stay fast while ensuring sensitive data remains hidden. Let’s take a look at how we will deliver on this:

1. High-precision detection powered by AI

We are moving beyond simple pattern matching. Snyk Secrets leverages a best-in-class engine that combines ML-driven semantic and contextual analysis with high-entropy scanning and regex. By understanding the surrounding code and metadata, we can dramatically reduce false positives and provide a high-fidelity signal that developers can trust.

Organizations also tend to have proprietary Secrets (such as DB passwords), so ensuring that you can supplement the Snyk Secrets engine with custom regex and patterns to scan, you can feel confident that we’ll detect Secrets across all of your plain-text code files in your repos.

2. Shifting left to prevention

The most effective way to manage a leak is to prevent it from occurring in the first place. Snyk’s shift-left strategy has been our beacon over the last ten years, and Secrets is no exception. Real-time feedback directly within developers’ native tools is essential:

• Prevention: By scanning through the IDE and CLI, you can prevent Secrets from ever reaching a commit, saving time and improving your security posture
• Detection: You can scan for Secrets in PR checks to ensure they never merge to a major branch, and by integrating with the SCM and CI/CD pipeline, you can detect Secrets at build time and through scheduled testing.

3. Unified visibility and integrated governance

Security cannot properly be managed through a fragmented lens. Snyk Secrets fits seamlessly into Snyk’s single pane of glass approach to providing AppSec teams to manage risks across all repos:

• Unified reporting: Track trends in detection and remediation (MTTR) across your entire organization, with the ability to export them to provide you with a single pane of glass view of your security posture.
• Ignore approval workflow: Democratize the ability to request and triage ignores whilst consistently managing and governing risk acceptance for false positives through a centralized dashboard.

Join the journey

The secret-scanning market has matured, and value lies not just in finding secrets but in finding the right ones and preventing exposure at the source. Snyk is energized and committed to helping customers consolidate secrets sprawl into our unified platform, closing an essential visibility gap in the age of AI.

However, secrets are only one piece of a much larger puzzle. As organizations move toward agentic development, where autonomous systems plan, execute, and interact across tools and environments, the attack surface expands beyond static code to include agent inputs, tool usage, and runtime decision-making. Snyk Secrets is a foundational component of our broader AI Security Fabric. It is an invisible, intelligent layer providing continuous, context-aware security across code, agents, and AI-native systems.

By integrating Secrets into the Snyk AI Security Platform, we ensure that your security posture keeps pace with agents operating at machine speed. Our vision for the future of Secrets is tied directly to the core principles of Agentic Development Security: validating what agents use, controlling what they do, and preventing insecure output.

Interested in what Snyk Secrets and the Snyk AI Security Platform can do for your team? Book a demo and be sure to stay tuned for more excitement to come!

Key takeaway

JPMorganChase’s Global Technology Leadership published “Fortifying the enterprise: 10 actions to take now for AI-ready cyber resilience” on April 17, 2026. It’s a CISO mandate for every large enterprise. Snyk directly addresses 8 of those 10 actions — out of the box, in the developer workflow, with one platform.

Why this directive landed with a thud

When JPMorgan’s global technology leadership publishes a public cyber checklist, security teams at large enterprises take notice. JPMorgan spends roughly $15 billion a year on technology and runs one of the most battle-tested security programs on the planet. When they say “do these 10 things,” it lands less like advice and more like a preview of what regulators and boards will soon require.

The timing is no accident. AI is rapidly narrowing the window between a vulnerability’s discovery and exploitation. Processes designed for quarterly release cycles are now a liability. The JPMC directive acknowledges this directly — as does Anthropic’s companion security post from April 10, which describes AI models as increasingly effective at chaining known bugs into working exploits.

“Adversaries are scaling attacks, compressing the time from vulnerability discovery to exploitation, and increasing the volume of threats that enterprises face each day.”

— JPMorganChase Global Technology Leadership, April 17, 2026

All 10 actions, explained simply

Here’s what JPMorgan said, what it means in practice, and where Snyk fits.

1. Run the latest software versions

✅ Snyk helps

JPMC requirements: Stop using outdated open source packages and end-of-life libraries. Only use current, well-maintained releases from trusted repositories.

How Snyk helps: Snyk SCA continuously scans every open source dependency, flags outdated or vulnerable packages, and opens automated fix pull requests — at every commit, before anything ships.

2. Manage assets and software components

✅ Snyk helps

JPMC requirements: Know exactly what’s in every application. Build a Software Bill of Materials (SBOM) for each one, enriched with who owns it and how critical it is.

How Snyk helps: Snyk generates SPDX and CycloneDX SBOMs for every application and container, maps all open source dependencies, and integrates with tools like ServiceNow and Jira for ownership tracking.

3. Build a robust vulnerability management program

✅ Snyk helps

JPMC requirements: Fix known vulnerabilities in priority order — internet-facing systems first. Scan continuously, not quarterly. Factor in real-world exploit availability and CISA’s Known Exploited Vulnerabilities (KEV) list.

How Snyk helps: Snyk scans every PR and build, prioritizes based on reachability and exploit maturity, natively ingests CISA KEV data, and uses Agent Fix to auto-generate remediation PRs that developers can accept with one click.

4. Stress-test incident response plans

⚠️ Foundational

JPMC requirements: Run tabletop exercises and live simulations. Test backup and recovery. Include legal, comms, and business leaders — and close the gaps you find.

How Snyk helps: IR planning is a program function, not a code scanner’s job. Snyk supports post-incident reviews through audit trails, exception tracking, SBOM lineage, and compliance reporting. Pair with a dedicated IR platform for the exercises themselves.

5. Know your SaaS and outsourced dependencies

✅ Snyk helps

JPMC requirements: Maintain a current register of every third-party service your critical systems depend on. Assess their security posture. Have an exit plan.

How Snyk helps: Snyk Evo AI-SPM inventories AI models, third-party AI services, agent frameworks, and MCP servers, extending supply chain visibility into the AI layer that most security teams still can’t see. Discovery data shows 28% of enterprises already run agentic AI in production, most of it invisible to their security teams.

6. Speed up change management

✅ Snyk helps

JPMC requirements: Know how long it takes a patch to reach production. Automate testing and staged rollouts. Make security scanning a built-in quality gate — not a separate bottleneck.

How Snyk helps: This is the core Snyk use case. Native integrations with GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins, CircleCI, and more. Security gates run automatically at PR, build, and deploy. JPMC is describing, in their own words, the category Snyk created.

7. Aggressively filter outbound traffic

⚠️ Foundational

JPMC requirements: Default-deny outbound traffic from production environments. Only allow approved endpoints. JPMC notes that this single control would have substantially mitigated both Log4Shell and SolarWinds.

How Snyk helps: Network egress is enforced by firewalls and cloud network policy — not code scanners. However, Snyk IaC catches misconfigurations that silently weaken those controls: overly broad NAT gateways, unrestricted 0.0.0.0/0 rules in Terraform, and Kubernetes NetworkPolicy drift.

8. Remove standing privileges

✅ Snyk helps

JPMC requirements: Eliminate persistent admin access. Use just-in-time entitlement. Require MFA and session recording. Pay special attention to service accounts — they’re the most targeted.

How Snyk helps: PAM tools handle the identity plane. Snyk handles the upstream of the problem: Snyk Secrets detection finds embedded credentials, API keys, cloud tokens, and SSH keys in code and containers before they ever merge — removing the most common source of standing privilege leakage.

9. Manage remote access and segment networks

✅ Snyk helps

JPMC requirements: Require MFA for all remote access. Segment environments by trust level. Authenticate every system-to-system connection. Test with red team exercises.

How Snyk helps: Snyk IaC validates zero-trust and segmentation controls as code — VPC peering, private endpoints, service mesh mTLS, network ACLs, and firewall rules. Drift between your policy-as-code and the deployed network is caught at merge time, not after a red team finds it.

10. Embed security into AI development and deployment

✅ Snyk helps

JPMC requirements: Threat-model AI systems. Treat AI models and training data as high-value assets. Validate AI-generated code the same way you’d validate human-written code. Red-team for prompt injection and data poisoning.

How Snyk helps: Snyk Evo delivers the full AI security lifecycle: Agent Scan (scan AI-generated code), Snyk Studio (secure-by-default guardrails for coding agents like Cursor, Claude Code, Copilot), AI-SPM (model and agent inventory), Agent Red Teaming (adversarial testing for prompt injection), and MCP/agent supply chain security.

Why this is more urgent than it looks

The JPMC directive wasn’t written in a vacuum. It’s a direct response to AI changing the economics of cyberattacks. “We need to know that we can release it safely, and it’s not exactly clear how we can do that with full confidence,” said Logan Graham, the head of Anthropic’s Frontier Red Team, which evaluates AI for risks.

Both documents land on the same conclusion: defenders must use AI at the code level, continuously, at the speed of change. Quarterly scans and manual triage simply won’t keep pace with automated exploitation at scale.

External research reinforces the stakes: BaxBench (ETH Zurich, UC Berkeley, 2025) found that 62% of frontier LLM-generated backend code is incorrect or insecure. As teams lean more heavily on coding agents, the volume of security issues entering codebases is rising — without automated scanning designed to detect AI-generated patterns.

How to operationalize this in 90 days

If you’re a security team that needs to demonstrate progress against the JPMC 10, here’s a practical phased approach:

| | | | — — | — — | | Days 1–30 | Close the most urgent code gapsDeploy Snyk Open Source, Snyk Code, and Snyk Secrets across your top 25 revenue-critical applications. Covers Actions 1, 2, 3, and the secrets portion of Action 8. | | Days 31–60 | Extend to cloud infrastructure Roll out Snyk IaC across production cloud accounts. Covers Actions 6, 7 (adjacent), and 9 — catching misconfigurations before they reach runtime. | | Days 61–90 | Secure the AI development layer Deploy Evo AI-SPM, Agent Scan, and Snyk Studio guardrails across active coding-agent deployments. Covers Actions 5 and 10. By day 90, 8 of 10 Actions are instrumented on one control plane. |

JPMorganChase published the mandate, and Anthropic published the mechanics behind why it’s urgent. Snyk is the platform that operationalizes both — natively in the developer workflow, across 8 of the 10 actions — at the speed AI is now generating code.

If you’re a CISO, AppSec lead, or procurement owner mapping vendors to the JPMC 10, the table above is your RFP foundation. If you’re a security team preparing for an order-of-magnitude increase in vulnerability volume, Snyk is the platform already instrumented for it.

A few weeks ago, Anthropic launched Glasswing, a $100 million initiative to use AI to identify vulnerabilities at scale. Around the same time, they introduced Claude Mythos, a system that can autonomously discover and exploit software flaws.

I wrote about this trajectory in my previous analysis: AI accelerates discovery, but enterprise trust still depends on deterministic validation, remediation automation, and governance at scale. Everything that’s happened since has reinforced that thesis and made the next step more urgent: we need to move from detection to control.

Anthropic’s System Card: Claude Mythos Preview (PDF) says it plainly: this class of system is not ready for broad release. The breakthrough and the risk arrive at the same time, and that tension defines the new era of enterprise AI security.

More capability doesn’t mean more security

Every time something like this drops, the conversation splits into two camps. Is AI good for security, or does it introduce new risks? The answer is more consequential than either side wants to admit: it’s both. Systems like Mythos can surface vulnerabilities that have gone undiscovered for decades, reason across complex environments, and operate at a speed no human team can match.

But at the same time, code is being generated faster than it can be reviewed, behavior is becoming less predictable, attack surfaces are expanding, and autonomous systems are starting to take real action inside production environments.

Discovery without control creates risk

Experienced security leaders reacted to these announcements quickly and with some useful context. As one former enterprise CISO put it: “When the metric every practitioner asks for is missing, the vulnerability count starts to read like a prospectus.”

Security leaders inside systemically important financial institutions are already thinking this way, recognizing that as software supply chains accelerate, governance (not discovery) becomes the limiting factor in managing systemic risk.

Here’s what that actually means in practice: detection without validation creates noise, discovery without prioritization creates backlog, and capability without governance creates risk. Security is defined by what you can control, not just by what you can find.

Your AI system is now part of your threat model

The most important signal here isn’t just what these systems can do. It’s what their creators are telling us about them.

In their own preview documentation, Anthropic describes models that have escaped constrained environments, accessed external systems, retrieved sensitive credentials that were intentionally out of scope, modified running processes, and leaked internal artifacts. In some cases, these systems showed signs of concealing behavior and manipulating evaluation mechanisms.

Let that sink in for a second. The company building these systems is publicly stating: “This is the highest alignment risk of anything we’ve ever released, and you should not deploy it in environments where its actions could cause irreversible harm.”

Recent events make this even more concrete. When the internal workings of AI development tools get exposed (as with the Claude Code leak), the effort required to find and exploit their weaknesses drops significantly. What was opaque becomes analyzable, and therefore attackable.

As IDC has noted, the industry has focused heavily on securing the code AI produces, but far less on securing the tools themselves within the software supply chain.

Think about what that means. The same systems that generate production-ready code, discover vulnerabilities, and orchestrate complex workflows can also operate outside intended boundaries, access sensitive systems, and make decisions that are hard to predict or audit.

As systems become more capable, they become less deterministic and harder to govern. If the organizations building these systems are explicitly warning us about their behavior, the question for every enterprise is straightforward: who is responsible for governing them once they’re in your environment?

3 major category shifts in the age of AI

1: More signal increases risk without control

For years, the security industry operated under one constraint: we couldn’t find enough risk. That constraint is gone. We’re now in a world where detection is effectively infinite, code generation is accelerating, and AI is participating directly in the development process.

The more risk you can find, the harder it becomes to manage. That’s the paradox of AI in security: the bottleneck is no longer discovery, it’s control.

This is a fundamental shift in the operating model. Security leaders need to answer a different set of questions now:

• What matters in this environment?
• What behavior is allowed?
• How is risk prioritized?
• How is remediation enforced?
• How do you maintain governance across both human developers and AI systems?

2: AI can reason about risk, but it cannot enforce it

AI can find and fix, but it can’t be trusted to enforce. AI systems are getting very good at reasoning: identifying vulnerabilities, suggesting fixes, simulating attack paths. But enterprise security doesn’t run on reasoning. It runs on enforcement.

You can ask an AI to reason about risk. You cannot ask it to guarantee compliance. That means:

• Policies must be applied consistently.
• Controls must behave predictably.
• Remediation must be verified.
• Risk must be auditable.

3: Security has shifted from discovery to control

As detection becomes more prevalent, a new layer becomes essential: a control plane that translates signals into context, applies policy consistently, prioritizes what matters, orchestrates remediation, and enforces governance across both human and machine actors.

Discovery becomes input. Control becomes the system. Governance becomes the outcome. Security is no longer about finding risk. It’s about controlling it.

But here’s something that needs to be said directly, because it gets glossed over in this conversation: you can’t control everything, and it’s unrealistic to expect that you will.

Controls are critical, full stop. But the idea that a sufficiently robust control framework will prevent every breach and catch every vector? That’s a fantasy. The threat landscape moves too fast, systems are too complex, and AI is introducing failure modes we haven’t fully mapped yet.

So the question isn’t only “how do we prevent this?” It’s also: how fast can we detect and respond when something inevitably slips through?

Incident response is not a fallback. It’s a core competency, and it’s only going to matter more with each passing year. The teams that come out ahead won’t just have the tightest controls. They’ll be the ones that can contain, respond, and recover faster than an attacker can escalate. As AI systems get more autonomous and the blast radius of any given failure grows, that response muscle becomes a genuine competitive advantage.

And even prevention and response together aren’t the full picture. You need world-class security expertise, constantly iterating on and improving your posture, people who understand not just the technology but the adversary. That means deploying the best AI models (plural, not just one, because different models have different strengths and relying on a single one is a single point of failure), the best deterministic rulesets and bleeding-edge analysis techniques, and experienced security experts bringing human intuition and judgment to close the gaps automation alone can’t cover.

This combination of best-in-class AI, deterministic controls, and human expertise is exactly what we’re building at Snyk. Not because any single layer is sufficient on its own, but because the threat landscape is evolving too fast for any one approach to keep pace. We’re deploying the best tools available across every layer, working together as a complete security stack that can actually evolve alongside the threats it’s designed to address.

Meanwhile, AI is already in production, and governance isn’t. Organizations are shipping AI-generated code into production, embedding models into critical workflows, and allowing autonomous systems to act on their behalf.

Without a control layer, this leads to unbounded exposure, inconsistent remediation, limited visibility, and growing regulatory pressure. With the right model in place, risk becomes measurable, remediation becomes scalable, AI becomes governable, and security becomes a genuine strategic advantage.

Control will define the next era of security

Anthropic’s announcements signal something fundamental: the future of security won’t be defined by how much risk we can discover. It’ll be defined by how well we can control it.

In a world of infinite signals, detection becomes expected, and noise becomes dangerous. Control matters. Response speed matters. Continuous improvement driven by real expertise matters. The organizations that build for all three, in equal measure, will be ready for what security actually looks like in the age of AI.

That’s the shift the best platforms are building toward: turning raw signal into enforceable policy, verified remediation, and governance that scales alongside AI-driven development.

The boardroom reality

Here’s the bottom line: AI is changing what risk looks like, not just how we find it. The systems building your software today can act faster, smarter, and more unpredictably than ever before. That leaves boards, CISOs, and senior leadership with a straightforward question: who is accountable when AI misbehaves, and who governs it before it ships?

The organizations that get this right won’t be chasing every vulnerability. They’ll be controlling risk at scale, enforcing governance in real time, and turning infinite signals into actionable, auditable decisions. And when something inevitably breaks, they’ll respond fast enough that it doesn’t become a catastrophe.

That’s the shift the best platforms are building toward, turning raw signal into enforceable policy, verified remediation, and governance that scales alongside AI-driven development. This is the direction we’re actively building toward at Snyk.

In the age of AI, control isn’t optional. It’s the only path to trust.

In November, we shared our vision for the Future of Snyk Container, outlining a fundamental shift in how teams secure the modern container lifecycle. We promised a future where security doesn’t just “scan” but scales effortlessly with the speed of the AI-driven, agentic world.

Today, we are thrilled to announce that we are moving from vision to reality.

With the General Availability (GA) of Container Registry Sync and a suite of powerful new enhancements, we are delivering the milestones promised in November. As the velocity of software creation skyrockets, the need for scalable, developer-first container security has never been more critical.

One of the biggest challenges in container security is keeping up with the sheer volume of new images being pushed to your registries every single day — and dealing with the clutter of old images left behind.

With the GA launch of Container Registry Sync, Snyk is delivering a massive improvement that streamlines inventory management. Instead of manual, all-or-nothing imports, Snyk Container will automatically monitor your container registries and pick up new images to scan and secure, empowering you with customizable rules for both adding and pruning images.

You can define specific policies detailing exactly which new images should be automatically imported and scanned by Snyk when they hit your registry, and exactly which older images should be dropped — regardless of whether those old images still physically exist in the registry itself.

By automating the discovery of new images and the pruning of stale ones, your security visibility finally scales alongside your deployment speed. Your teams will no longer waste time on vulnerability notifications for images that aren’t in use, drastically reducing alert fatigue and keeping your focus where it belongs: on active code and, with signals from runtime, live containers.

Extending visibility and enhancing prioritization

Scaling our registry capabilities was just step one. We are also introducing several fundamental enhancements to the Snyk Container product experience, now available in beta. These new capabilities further extend visibility and redefine how you prioritize risk.

• A unified platform experience: We are rolling out a brand-new platform experience for visualizing, managing, and remediating container images. This unified view aggregates data irrespective of where the images were originally scanned, be it in your CLI, CI/CD, or registry, or how the image has been tagged. Gain a single source of truth for your entire container posture, eliminating the “visibility gap” between different stages of the SDLC.
• Runtime intelligence via 3rd-party signals: Not all vulnerabilities pose the same risk. By ingesting signals from our 3rd-party runtime partners, Snyk Container can now prioritize the scanning and remediation of images actually running in production. We help you cut through the noise to find what is truly exploitable in production. Stop asking developers to fix thousands of vulnerabilities; instead, give them the ten that actually pose a risk to your live environment.
• Broader support for multiple profiles: We’ve built in deeper, more flexible support for multiple profiles, giving enterprise teams the nuanced governance and access controls they need to manage complex, multi-tenant environments.

Built on a foundation of continuous innovation

These launches are supported by months of robust architectural improvements and ecosystem expansion that ensure enterprise-grade stability and robustness. Recent improvements to Snyk Container include:

• Hardened base images: Broader, more accurate support for hardened base images, ensuring you have the best starting point for secure applications. Snyk Container has been building support for hardened images with partners like Chainguard, Minimus, Canonical, and Docker.
• Expanded ecosystem support: We’re adding comprehensive support for the Go standard library, container scan support for cgo and stripped Go binaries, and pnpm lockfile support.
• Broader OS distribution coverage: Seamless scanning for the latest operating systems, including Ubuntu 24.04 (Noble Numbat) and 24.10 (Oracular Oriole).

Evo by Snyk: Guardrails for the agentic AI era

Why are these massive updates to Snyk Container so crucial right now? It all ties back to the AI Security Fabric and Evo by Snyk.

We are entering the era of agentic AI. Autonomous AI coding agents are generating code, pulling in dependencies, and spinning up containerized environments faster than humanly possible. As a result, the sheer volume of software — and its potential attack surface — is exploding.

In an AI-native world, you cannot rely on manual security reviews or disconnected point-in-time scans. You need guardrails that operate at the speed of AI. Snyk Container’s scalable visibility, runtime prioritization, and automated remediation provide exactly that. By connecting container context to the broader Snyk AI Security Fabric, we ensure that as you accelerate your AI use, you maintain absolute governance over your security posture. We are making sure that AI-generated sprawl doesn’t become an unmanageable risk.

Looking ahead

We are proud to have delivered on the promises we made in November, but we aren’t stopping there. We will build upon this foundation to continue to deliver innovative governance and remediation features that simplify Container security over the upcoming quarters.

Ready to experience true scale? Enable Container Registry Sync in your Snyk dashboard today, and reach out to your account team to opt into our new beta features to explore the unified platform experience!

On March 31, 2026, two malicious versions of axios, the enormously popular JavaScript HTTP client with over 100 million weekly downloads, were briefly published to npm via a compromised maintainer account. The packages contained a hidden dependency that deployed a cross-platform remote access trojan (RAT) to any machine that ran npm install (or equivalent in other package managers like Bun) during a two-hour window.

The malicious versions (1.14.1 and 0.30.4) were removed from npm by 03:29 UTC. But in the window they were live, anyone whose CI/CD pipeline, developer environment, or build system pulled a fresh install could have been compromised without ever touching a line of Axios code.

TL;DR

| | | | — — | — — | | Snyk Advisory | SNYK-JS-AXIOS-15850650 | | Affected versions | axios@1.14.1, axios@0.30.4 | | Root cause | Hijacked npm maintainer account | | Malicious dependency | plain-crypto-js@4.2.1 (SNYK-JS-PLAINCRYPTOJS-15850652) | | Payload | Cross-platform RAT (macOS, Windows, Linux) | | C2 server | sfrclak[.]com:8000 | | Published | 1.14.1 at 00:21 UTC; 0.30.4 at 01:00 UTC | | Removed | 03:29 UTC (March 31, 2026) | | Safe versions | Any version other than 1.14.1 or 0.30.4 | | Immediate action | Audit lockfiles for affected versions; rotate secrets if exposed |

How the attack was constructed

This is not a case of a typosquatted package or a rogue dependency slipping into a build. The attacker had (or gained) direct publishing access to the official axios package on npm, likely by compromising a maintainer's account. According to a collaborator in the official GitHub issue thread, the suspected compromised account belonged to maintainer @jasonsaayman, whose repository permissions were higher than those of other collaborators, complicating rapid remediation.

The attacker did not modify any Axios source files directly. Instead, they added a pre-staged malicious dependency, plain-crypto-js@4.2.1, to the package.json of the new axios releases. The plain-crypto-js package itself was purpose-built for this attack: an earlier "clean" version (4.2.0) had been published 18 hours prior, likely to give it a brief history on the registry. Version 4.2.1 contained the malicious payload.

When a developer or CI system runs npm install axios@1.14.1, npm resolves the dependency tree, pulls plain-crypto-js@4.2.1, and automatically runs its postinstall hook: node setup.js. That single script execution is where the compromise begins.

The dropper: Double-obfuscated and self-erasing

The setup.js postinstall dropper uses two layers of obfuscation to avoid static analysis:

1. Reversed Base64 encoding with padding character substitution
2. XOR cipher with the key OrDeR_7077 and a constant value of 333

Once deobfuscated, the script detects the host operating system via os.platform() and reaches out to the C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73) to download a second-stage payload appropriate for the platform.

After execution, the malware erases its own tracks: it deletes setup.js, removes the package.json that contained the postinstall hook, and replaces it with a clean package.md renamed to package.json. If you inspect node_modules/plain-crypto-js after the fact, you would find no obvious signs of a postinstall script ever having been there.

Platform-specific payloads

The second-stage payloads are purpose-built for each platform.

macOS

An AppleScript downloads a binary to /Library/Caches/com.apple.act.mond, deliberately spoofing an Apple background daemon naming convention to blend in. Once established, the RAT:

• Generates a 16-character unique victim ID
• Fingerprints the system: hostname, username, macOS version, boot/install times, CPU architecture (mac_arm or mac_x64), running processes
• Beacons to the C2 every 60 seconds using a fake IE8/Windows XP User-Agent string
• Accepts four commands from the attacker:
• peinject: receives a Base64-encoded binary from the C2, decodes it, writes it to a hidden temp file (e.g., /private/tmp/.XXXXXX), performs ad-hoc code signing via codesign --force --deep --sign - to bypass Gatekeeper, and executes it
• runscript: runs arbitrary shell commands via /bin/sh or executes AppleScript files via osascript
• rundir: enumerates filesystem metadata from /Applications, ~/Library, and ~/Application Support
• kill: terminates the RAT process

Windows

A VBScript downloader copies the PowerShell binary to %PROGRAMDATA%\wt.exe (masquerading as Windows Terminal) and executes a hidden PowerShell RAT with execution policy bypass flags.

Linux

A Python RAT is downloaded to /tmp/ld.py and launched as an orphaned background process via nohup python3, detaching it from the terminal session that spawned it.

Additional compromised packages

Two other packages were observed shipping the malicious plain-crypto-js dependency:

• @qqbrowser/openclaw-qbot@0.0.130 — includes a tampered axios@1.14.1 with the injected dependency (SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776)
• @shadanai/openclaw (versions 2026.3.31-1, 2026.3.31-2) — vendors plain-crypto-js directly (SNYK-JS-SHADANAIOPENCLAW-15850775)

These secondary packages suggest either coordinated attacker infrastructure or that the malicious plain-crypto-js was being actively used in related campaigns.

Who is actually at risk

The three-hour publication window (00:21 to 03:29 UTC) is the key constraint. Risk is highest for:

• CI/CD pipelines that do not pin dependency versions and run npm install on a schedule or on commit — especially those that run overnight or in the early morning UTC.
• Developers who ran npm install or npm update in that window and happened to pull the affected versions.
• Projects depending on @qqbrowser/openclaw-qbot or @shadanai/openclaw, whose exposure does not depend on the window.

If your lockfile (package-lock.json or yarn.lock) was committed before the malicious versions were published and your install did not update it, you were not affected. Lockfiles are your first line of defense here.

The malicious versions have been removed from the npm registry. However, anyone who installed them during the window should assume a full system compromise: the RAT was live, beaconing, and capable of executing arbitrary follow-on payloads.

Snyk remediation and how to check your exposure

If you are a user or customer of Snyk, then any of the various Snyk integrations will alert you of any projects that vendor the compromised and malicious version of the axios dependency, whether via the Snyk CLI, the Snyk app integration, or otherwise.

Snyk’s database includes entries for both SNYK-JS-AXIOS-15850650 and SNYK-JS-PLAINCRYPTOJS-15850652, so snyk test will flag the affected versions and the malicious transitive dependency.

Additionally, if you’re on the Enterprise plan, Snyk you will see a Zero Day report in the application, similar to how you’d find earlier zero day security incidents such as LiteLLM, Shai-Hulud and others, giving you a system-wide view to easily locate and pin-point affected projects and repositories that have the vulnerable axios dependency:

In the case you’re not yet using Snyk, there’s a free tier, and you can easily get started and audit your environment for potential axios compromise or other security issues as follows:

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

For Bun users: Snyk workaround (native bun.lock support is limited in the Snyk CLI at time of writing):

The recommended workaround is to generate a yarn.lock compatible lockfile using Bun's built-in -y flag, which Snyk can parse:

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

Otherwise, you can follow any of the steps below to locate and check if you’re affected by the axios compromise:

Step 1: Check your lockfile for affected versions

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

Step 2: Check for the malicious dependency

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

Step 3: Check for Bun runtime installs for the malicious axios dependency

If you are using Bun, check your bun.lock (text lockfile, Bun v1.1+):

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

Also, check for the malicious transitive dependency:

grep 'plain-crypto-js' bun.lock

Note: Older Bun versions produce a binary bun.lockb. To inspect it, convert first:

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

Step 4: Check for IOCs on compromised systems

If you believe a machine ran npm install in the affected window, look for these indicators:

| | | | — — | — — | | Platform | IOC | | macOS | /Library/Caches/com.apple.act.mond binary | | Windows | %PROGRAMDATA%\wt.exe (PowerShell masquerading as Windows Terminal) | | Linux | /tmp/ld.py Python script | | Network | Outbound connections to sfrclak[.]com / 142.11.206.73:8000 |

Further npm package manager remediation advice

If you are not affected (precautionary):

1. Pin axios to a known safe version in your package.json. Any version other than 1.14.1 or 0.30.4 is clean.
2. Commit your lockfile and ensure CI uses npm ci (not npm install) to enforce lockfile integrity.
3. Add plain-crypto-js to a blocklist in your package manager or security tooling.

Consider enabling --ignore-scripts for npm installs in CI environments where lifecycle hooks are not needed:

npm ci --ignore-scripts

This prevents postinstall scripts from running entirely, which would have blocked this attack vector. Be aware that it can break packages that legitimately need post-install steps (native addons, for example).

Additionally, consider using and rolling to your developers the npq open-source project that introduces security and health signal pre-checks prior to installing dependencies.

Finally, you’d likely want to review and consult these publicly curated npm security best practices.

If you are affected (assume breach):

1. Contain immediately: Isolate any systems that ran npm install in the affected window.
2. Rotate all secrets: Treat every credential on the affected machine as compromised — API keys, SSH keys, cloud credentials, npm tokens, GitHub tokens. Do not rotate in place; revoke and reissue.
3. Review for lateral movement: Check logs for outbound connections to sfrclak[.]com or 142.11.206.73. If the RAT was active, the attacker had arbitrary code execution and may have enumerated or exfiltrated further.
4. Rebuild environments: Do not attempt to clean compromised systems. Rebuild from a known-clean snapshot or base image.
5. Audit CI pipelines: Review build logs for the March 31, 2026 UTC window to determine which pipelines installed the affected versions.

The bigger picture: Maintainer account security

This attack follows a now-familiar pattern: compromise a legitimate maintainer account, publish a malicious version of a trusted package, and rely on the ecosystem’s implicit trust of registered packages. We’ve seen this playbook used against ESLint’s Prettier plugin, against multiple packages owned by a prolific developer via phishing, and against the Shai-Hulud campaign that compromised over 600 packages.

What makes Axios particularly significant is the scale: 100 million weekly downloads means even a two-hour malicious window represents an enormous potential blast radius. The attacker also showed meaningful operational sophistication, pre-staging the malicious dependency, using a “clean” version history, double-obfuscating the dropper, building platform-specific RATs, and implementing anti-forensic self-deletion. This was not opportunistic

For organizations that depend on open source at scale, the lesson is not to stop using npm or to distrust all dependencies. It’s to understand which supply chain controls would have caught this: lockfile enforcement, postinstall script auditing, and runtime monitoring for unexpected process spawns or outbound network connections from build environments. Snyk’s guide to preventing npm supply chain attacks and lockfile security considerations are worth revisiting in the context of this incident.

If you want to understand the class of attack at a conceptual level, Snyk Learn has a lesson specifically on compromise of legitimate packages that walks through the attack patterns and defensive controls.

Timeline

| | | | — — | — — | | Time (UTC) | Event | | 2026–03–30 23:59 | plain-crypto-js@4.2.1 published to npm | | 2026-03-31 00:21 | axios@1.14.1 published with malicious dependency | | 2026-03-31 ~00:27 | Socket's scanner detects malicious version (within ~6 minutes) | | 2026-03-31 01:00 | axios@0.30.4 published with malicious dependency | | 2026-03-31 03:29 | Both malicious axios versions removed from npm |

In the age of AI-driven development, speed is the new baseline. But as AI agents accelerate the pace of coding, they also amplify the risk of security bottlenecks. At Snyk, we believe a superior Developer Experience (DX) is the only way to secure this new frontier. DX is not just a layer on top of the product. It is the foundation that allows developers to unleash AI innovation securely.

We think of DX as a system of decisions that compound over time. Every interaction, every default, and every piece of information a developer encounters shapes how effectively they can use our platform.

The five principles that emerged from our journey of evolving and refining the Snyk platform now serve as the foundation for delivering an excellent DX. These principles continuously guide the thousands of small decisions we make across the entire product surface, underscoring our commitment to this ongoing process.

1. Go to where developers work, don’t ask them to come to you

The most common challenge in developer tooling is the assumption that a beautiful dashboard is the primary destination. Experience shows that developers prioritize their existing workflows, which they have optimised over the years: their IDE, the terminal, their Git flow, and their pull request (PR) process. Context switching out of those workflows has a tremendous cost.

We saw this directly at Snyk. We had built a detailed findings interface in the Snyk platform with prioritized vulnerability lists, remediation guidance, and full data flow traces. Developers did not visit it. We learned that even the most valuable data is often bypassed if it requires a context switch. By moving security into the existing PR conversation, we aligned with the developer’s natural flow.

We changed our model. We stopped asking developers to come to Snyk and started bringing Snyk to them. Security findings became part of the pull request conversation, surfaced directly in the SCM in the same thread where code review was already happening. Same information. Zero context switch, but dramatically different adoption.

The principle goes beyond PRs. It is why we invest heavily in IDE plugins, AI coding assistant and, CLI integrations, and CI/CD gates. The question we ask is always the same: where is the developer already working, and how do we show up there?

There’s a broader shift underway from traditional IDEs to agentic development environments. At the velocity that AI coding assistants drive, context switching becomes a much bigger bottleneck, since higher agent productivity amplifies the cost of breaking flow. As agentic platforms become a core part of developer workflows, Snyk is already integrated in those environments to secure AI-generated code at inception.

1. Developers are not security specialists, so speak their language

When we designed security findings in PRs, we optimized for the developer’s mental mode. CVSS scores or CWE classifications made sense to security professionals, but to developers they were jargon that required translation.

We surface a contextual, natural-language description generated from Snyk’s own data flow analysis. For a SQL injection vulnerability, for example, rather than citing a generic advisory, we would explain that unsanitised user input from the HTTP request body is directly interpolated into an SQL query string, naming the source, the sink, and the mechanism in the developer’s own code.

That one sentence tells a developer, who is often not a security specialist, exactly what and where (to the exact file and line number) the problem is, in terms they already understand. The full trace is still available for those who want it. But most developers do not need to go deeper. They need to understand enough to act.

And every surface of Snyk’s product attempts to apply this principle. We aim to answer, “What does this developer need to understand, at this moment, given what they know?”

1. Every piece of information is either signal or noise — there’s no middle ground

There is a tendency in security tools to surface everything. It feels comprehensive, but it often overwhelms rather than helps. When we examined our PR experience, we reframed the problem: what information truly belongs in the developer’s view?

We chose to be deliberate. What we show depends on the workflow. In prevention, developers need fast, actionable guidance. In remediation, they need depth and more paths when they are optimising for risk reduction. In a PR, every piece of information should either answer an immediate question or enable a clear next step. This context matters a lot as developers in a PR are focused on shipping the functionality. Vulnerability resolution becomes secondary. This is very different from a backlog context, where fixing issues is the primary task.

Progressive disclosure also helps balance this. The primary view focuses on the issue, its severity, and the next step. Deeper layers provide additional context, such as data flows, when needed. This keeps the experience focused and noiseless.

1. Detection is not the product, resolution is

For a long time, security tools measured success by what they found. The more vulnerabilities surfaced, the more complete the tool felt. What this metric missed was the thing that actually mattered: whether those vulnerabilities got fixed.

Most developers do not want awareness. They want to know what to do next. A vulnerability report with no clear next step is just noise with a severity score, and developers, quite rationally, learn to treat it that way.

The motivation behind building fix suggestions directly into the PR experience was to close the loop: not just identify vulnerabilities, but fix them without ever leaving the workflow. When Snyk detects a vulnerability in code, it does not just flag it. It proposes a concrete, AI-generated fix as a diff, inline in the PR as a review comment, red lines out, green lines in, applicable as a commit with a single action.

For the SQL injection example, rather than flagging the string interpolation and leaving the developer to figure out the solution, the AI Fix suggestion replaces it with a parameterized query. The developer does not need to research secure SQL practices, the fix is already there. The path to resolution becomes the default path.

Good DX tells them how to fix an issue, but a great DX makes fixing the default path.

1. Trust is built when developers understand why, not just what

When we launched the suggested fix, we saw a pattern repeatedly in developer feedback: the question was not “does the fix work?” It was “Why does this fix work?” Developers were applying suggestions and then struggling to explain them to colleagues. The fix was solving the immediate problem and creating a different one.

So we added something that turned out to be one of the highest-signal changes we made to the PR check experience: a plain-English explanation of exactly why the suggested change eliminates the vulnerability. Not a link to documentation. Not a reference to the CVE. An explanation, derived from the code’s specifics, of how the fix addresses the vulnerability.

For the SQL injection example, the explanation would describe how replacing dynamic string interpolation with parameterized queries ensures that user input is treated as data rather than executable code and why that distinction closes the vulnerability.

The combination of these two features, suggested fix and its explanation, mirrors how a senior security engineer would actually review code with a colleague: first making sure they understand the problem, then showing them what good looks like.

Trust is built through reasoning. Every time Snyk explains its thinking, it gives developers the tools to develop their own security instincts, which is, ultimately, the most durable outcome.

Great developer experience does not happen by accident

These five principles got solidified by watching what broke, understanding why, and changing our approach.

Great developer experience requires principles like these that can guide thousands of small decisions across product, engineering, and design. As we move into a future where AI and human developers collaborate more closely, these principles ensure that security remains a tailwind, not a hurdle. At Snyk, we are constantly striving to get better; one decision, one fix, and one successful deployment at a time.

See how the developer experience Snyk has built can accelerate your program. Get a demo today.

This is the prompt — the whole thing:

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

It’s the core of Cursor’s Agentic Security Review automation, the one that’s been reviewing 3,000+ internal PRs per week and catching 200+ real vulnerabilities. A role assignment, a goal, a four-step methodology, and a priority list. No elaborate chain-of-thought scaffolding. No pages of few-shot examples. No complex JSON output schemas.

If you’d told me two years ago that a prompt this concise could run at that scale and produce results worth blocking CI on, I would’ve been skeptical. We’ve all been conditioned to think AI prompting requires elaborate engineering: pages of instructions, carefully crafted examples, detailed output specifications. Cursor’s open-sourced templates suggest that for security review, a clear role definition and a structured methodology might be all you need.

That’s a remarkable signal about where frontier models are right now. The model already “knows” what SQL injection looks like, how authentication bypasses work, and what unsafe deserialization means. It just needs a framework for applying that knowledge systematically. If models can do this much with so little instruction today, the trajectory over the next six to twelve months is genuinely exciting.

Of course, the prompt is just the tip of the iceberg. The real engineering achievement here isn’t the 15 lines of instructions; it’s everything underneath: the custom MCP server handling persistence and deduplication, the Terraform-managed deployment pipeline, the webhook orchestration that knows when to trigger which agent, and the state management that lets agents compare findings across runs. The prompt is simple because the surrounding infrastructure is not. That’s an important distinction, and it’s actually the more interesting story: Cursor didn’t just write clever prompts; they built a production-grade agent orchestration platform and then put simple prompts on top of it.

But before we get ahead of ourselves, let’s look at the full picture of what Cursor built, what’s impressive about each piece, and where the gaps are. To do that, it helps to have a framework for thinking about security in agentic development environments.

The three dimensions of agentic security

At Snyk, we think about securing agentic development across three dimensions: the code the agents generate, the supply chain the agents depend on, and the behavior of the agents themselves. The code dimension is the one most people focus on: is the AI writing secure code, and are we catching vulnerabilities before they ship? The supply chain dimension is newer and less obvious: MCP servers, automation templates, agent skills, and plugins are all components your agents depend on, and they carry the same risks as any third-party dependency. The behavior dimension is the most nuanced: are the agents acting within their intended scope, are they making decisions they shouldn’t, and do you have visibility into what they’re actually doing across your organization?

Cursor’s security agents primarily operate in the first dimension, catching vulnerabilities in code. That’s valuable and necessary work. But as you’ll see in the walkthrough below, the other two dimensions matter just as much, especially at enterprise scale. And the organizations getting the best results, like Labelbox, which cleared a multi-year vulnerability backlog by running Cursor and Snyk together, are the ones addressing all three.

The four agents: what’s strong, what’s missing

Today, Travis McPeak published a blog post detailing how Cursor’s security team built four autonomous security agents on top of Cursor Automations (their cloud agent platform) and open-sourced the templates for anyone to use. Their PR velocity had increased 5x over nine months, and traditional static analysis couldn’t keep up. So they built agents that could.

The whole system sits on a foundation that’s worth noting: a custom MCP (Model Context Protocol) server deployed as a serverless Lambda function. It provides persistent state tracking, a deduplication layer powered by Gemini Flash 2.5 (so different agents don’t file the same finding using different words), and consistent Slack output formatting with dismiss/snooze actions. Everything is managed through Terraform. Solid engineering.

Here’s each agent, along with what I think is genuinely impressive and what an enterprise security team should be thinking about.

Agentic Security Review: the PR gatekeeper

What it does: Reviews every pull request against Cursor’s specific threat model. Posts findings to a private Slack channel, comments directly on PRs, and can block the CI pipeline on security findings. The key differentiator from a general-purpose review bot like Cursor’s Bugbot is the ability to prompt-tune specifically for security without blocking on every code quality nit.

What’s impressive: The results speak for themselves. In the last two months, this agent has run on thousands of PRs and prevented hundreds of issues from reaching production. And as I showed above, the prompt driving all of this is remarkably concise. The signal-to-noise ratio, for an LLM-based reviewer, is genuinely surprising.

What to think about: LLMs can confidently flag a “critical SQL injection” in a parameterized query that’s perfectly safe, because the model misread the data flow. They can also miss a real vulnerability because attention drifts across a large codebase. In a security context, both failure modes are expensive: false positives erode developer trust, and false negatives leave real vulnerabilities in production. When your detection layer is entirely probabilistic, you’re accepting both risks. The principle here is simple: the agent cannot mark its own homework. You need an independent validation layer confirming what the LLM found. That’s why layering deterministic SAST analysis (like Snyk Code) underneath the LLM review matters. The deterministic engine catches known patterns with mechanical precision; the LLM catches the novel, cross-file logic bugs that rule-based tools miss. You want both.

Also worth noting: look at the end of the prompt template.

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

The review agent explicitly does not push fixes. It finds, it reports, it blocks, but a human still decides what to do. Even Cursor’s own security team keeps humans in the loop for their own tooling. That should tell you something about where autonomous AI security actually stands today: it’s a powerful accelerator, not a replacement for human judgment. At least not yet.

Vuln Hunter: scanning the existing codebase

What it does: Instead of watching new code come in, Vuln Hunter scans the existing codebase. It divides the repo into logical segments, searches each one for vulnerabilities, and the security team triages findings from Slack. They often use @Cursor directly from Slack to generate fix PRs.

What’s impressive: Pointing LLM reasoning at legacy code is smart. This is where AI shines: understanding complex, undocumented codebases and identifying vulnerabilities that static rules would miss. Cross-file logic bugs, broken access control patterns, and authentication bypasses buried in years-old code. Traditional scanners struggle here because they need well-defined patterns to match against.

What to think about: This is the agent most likely to produce false positives at scale. Scanning an entire codebase (rather than a focused PR diff) means the model is working with a much larger context, and that’s where LLM attention drift becomes a real concern. BaxBench, a benchmark from ETH Zurich, UC Berkeley, and INSAIT, found that 62% of solutions generated by even the best models are either incorrect or contain security vulnerabilities. When the model is reasoning about large, complex codebases, the “agent can’t mark its own homework” principle applies doubly: you want deterministic validation confirming or disproving what the LLM found before anyone spends time on a fix.

Anybump: automated dependency patching

What it does: Tackles the most tedious job in application security: dependency patching. It runs a reachability analysis to filter down to actually impactful vulnerabilities, traces code paths, runs tests, checks for breakage, and opens a PR when tests pass. All automated, with Cursor’s canary deployment pipeline as a final safety gate.

Here’s the core of the prompt:

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

What’s impressive: This addresses a pain point that every security team knows intimately. Dependency patching is so time-intensive that most teams eventually give up and push it to engineering, where it sits in backlogs for months (or years). Automating the reachability analysis, testing, and PR generation is a real workflow improvement.

What to think about: Anybump solves the hardest part of dependency management: actually getting the patch applied, tested, and into a PR. Where it stops is everything around that patch. There’s no SBOM generation, no license compliance check, and no audit trail for your compliance team. Those aren’t shortcomings of the agent so much as they are a different category of problem entirely. Automated patching and enterprise software composition analysis overlap, but they’re not the same thing. If you’re in a regulated industry or shipping software under customer contracts with compliance requirements, you’ll still need that broader infrastructure alongside the automation.

If you’re a startup with one repo, Anybump might be all you need. If you’re operating at enterprise scale (hundreds of repositories, regulated industries, customer contracts requiring specific compliance certifications), you need to know exactly what’s in your software, what licenses you’re using, and you need to be able to prove it. That’s the difference between automated patching and enterprise-grade software composition analysis: they overlap, but they solve fundamentally different problems.

Invariant Sentinel: compliance drift detection

What it does: Runs daily to check for drift against a set of security and compliance properties. It spins up subagents for each logical segment of the repo, compares the current state against previous runs using automation memory, and alerts the security team when something changes.

What’s impressive: The statefulness here is clever. Using the automation’s memory feature to compare across runs means the agent can detect changes in security posture, not just point-in-time snapshots. The ability to write and execute validation code alongside the analysis adds rigor that pure LLM reasoning alone wouldn’t have.

What to think about: Compliance drift detection is valuable, but compliance governance is a broader challenge. Invariant Sentinel tells you when something changed; it doesn’t enforce policy-as-code across hundreds of repos, generate compliance reports for auditors, or give your CISO a dashboard showing risk trends over time. Those are platform-level capabilities that sit above what any single agent can provide.

This is still CI, and CI is not where security should start

Here’s the thing that’s easy to miss when you’re looking at the architecture diagrams and agent orchestration: what Cursor built is, at its core, a really sophisticated CI layer. The agents trigger on GitHub webhooks when PRs are opened or pushed. They review diffs, post comments, block pipelines, and open fix PRs. That’s fundamentally the same control point that traditional security tools have been operating at for years, but it’s smarter now because there’s an LLM doing the analysis instead of a regex-based rule engine.

And look, that’s a real improvement — no argument there. But CI is still the wrong place for security to start.

Why CI is too late for security

Think about it: if you’re using Cursor to write code in your IDE and the vulnerable code makes it all the way to a PR before anyone catches it, you’ve already lost time. The developer context-switches away from the code they wrote, the PR review cycle adds latency, and if the CI check blocks, now the developer has to go back, understand the finding, make a fix, push again, and wait for another review cycle. It’s better than discovering the vulnerability in production, sure, but it’s still the “scan and ticket” model, just compressed into the PR timeline.

What shifting left actually looks like

What you really want is security tooling running directly inside your IDE, triggering scans and remediations immediately as new code is introduced. That way, vulnerable code never makes it into a commit in the first place. Your git history stays clean. Your PRs don’t get blocked because the security issues are caught and fixed in the flow before the developer even stages the change. And you dramatically reduce the need for expensive human-in-the-loop reviews, because if the vulnerability never makes it into a PR, nobody needs to triage it, and nobody’s pipeline gets blocked at 4:30 PM on a Friday.

IDE-first security vs CI-first security

With Snyk Studio, this is exactly how it works. Security guardrails intercept insecure code before the developer even accepts the AI suggestion. The AI assistant runs snyk_code_scan on new code in real time, and if security issues are found, it fixes them right there in the flow. It works directly in Cursor and every other major AI coding assistant. No CI pipeline block, context switch, or cluttered git history.

Why layered security is necessary

Now imagine running both: Snyk Studio at the IDE layer catching the vast majority of issues at the point of creation, and Cursor’s security agents at the CI layer as a safety net for anything that slips through. You get defense in depth, with most of the work handled silently in the IDE and the expensive human reviews reserved for genuinely complex cases. Given what BaxBench tells us about the insecurity rate of AI-generated code (62% of solutions from top models contain vulnerabilities or are incorrect), this kind of layered protection isn’t a nice-to-have. It’s essential.

And even beyond the CI question, a security program is much more than CI checks. It’s centralized dashboards aggregating risk across hundreds of repositories. Its SAST findings correlated with DAST results, confirming that the same endpoint is exploitable at runtime. It’s your SCA engine identifying that the ORM library you’re using has a known CVE that bypasses parameterization in certain edge cases, and connecting that to the SAST finding in the same controller method. Individually, each of those is a data point. Together, correlated on the same platform, they tell you exactly what’s happening, why, and what to fix first. A code scanner, even an autonomous one with four agents and impressive PR throughput, doesn’t answer those questions. A security platform does.

Validation, not competition (and we’re already integrated)

I wrote a few weeks ago about Anthropic’s Claude Code Security launch and made the case that AI coding platforms investing in security is validation, not disruption. The same logic applies here: When the biggest names in AI development tooling start building security features, it means the industry has figured out that security in AI-assisted development is infrastructure, not an optional add-on.

How Cursor and Snyk work together

Cursor and Snyk aren’t ships passing in the night; Snyk is already in Cursor’s MCP Directory. We have a verified extension. We ship Evo Agent Guard via Hooks. Cursor is our AI Innovation Partner of the Year as of two weeks ago. This isn’t an adversarial relationship; it’s the two-tier architecture in action. Think of it this way: AI agents are the researchers, discovering vulnerabilities and proposing fixes with speed and creativity. Deterministic validation is a peer review that independently confirms that the findings are real and the fixes are sound.

The two-tier security architecture

You wouldn’t publish a paper without peer review, and you shouldn’t ship a security fix without deterministic validation. Cursor provides the research layer (agent orchestration, webhook triggers, automated PR generation). Snyk provides the peer review, governance, and breadth of coverage across the entire software supply chain.

And this is already working in the real world: Labelbox runs Cursor + Snyk together in production and was able to clear a multi-year vulnerability backlog. Cursor automates the remediation workflows; Snyk ensures those fixes are real and enterprise-grade.

The agentic supply chain is the new attack surface

Take a step back from Cursor’s specific implementation and look at what’s actually happening across the industry. Over the past year, an entirely new software supply chain has emerged, and it’s growing fast: MCP servers, agent skills, automation templates, AI tool plugins, and custom model configurations. Call it the agentic supply chain. It’s the collection of components that AI-powered development tools depend on to function, and right now, almost no one is securing them.

This isn’t a theoretical concern. In January 2026, Snyk’s research team discovered hundreds of malicious skills on ClawHub, the first major supply-chain attack targeting AI agent ecosystems. Think about that in the context of what Cursor just open-sourced: automation templates that run with access to your codebase, your CI pipelines, your Slack channels, and your GitHub repos. An MCP server deployed as a Lambda function that processes every security finding in your organization. These are powerful, privileged components. And the ecosystem for distributing and discovering them (marketplaces, template galleries, open source repos) is growing much faster than the security practices around it.

The traditional software supply chain took decades to develop the tooling we rely on today: package registries with signature verification, SBOMs, license scanners, and vulnerability databases. The agentic supply chain lacks that infrastructure yet, and it’s already being adopted at scale. Every organization installing MCP servers, importing automation templates, or connecting agent skills to their development environment is extending their attack surface in ways that code-level scanning, no matter how sophisticated, simply doesn’t address.

This is exactly the problem Evo by Snyk was built to solve. Evo is our agentic security orchestration system designed for the AI-native development landscape: AI threat modeling that builds live threat models from your code, AI red teaming that runs continuous adversarial testing against your models and agents, AI-SPM so you know exactly which AI models and frameworks are running across your organization (including the “shadow AI” that security teams don’t even know about), and Agent Scanning for visibility into all toolchains with real-time guardrails.

When you’re running autonomous security agents across your codebase, you need to secure those agents too. The tools in your agentic supply chain are every bit as critical as the npm packages in your node_modules, and they deserve the same rigor.

What’s next: the questions this raises

Rather than wrapping up with a thesis I’ve already written about, let me end with the forward-looking questions that Cursor’s announcement opens up. Because I think this is more interesting than looking backward.

Try it yourself

Snyk Studio is free, and setup takes minutes. It works in Cursor (along with virtually every other AI coding assistant). You’ll get deterministic scanning and the /snyk-fix remediation command running in your IDE in about five minutes. If you want to see layered security in practice, this is the fastest path.

Evo by Snyk is where you go when you need to secure the AI stack itself: threat modeling, red teaming, AI-SPM, agent scanning, and agentic security orchestration. If your organization is adopting AI coding tools at scale (and let’s be real, you probably are), Evo gives you the visibility and guardrails to do it safely.

Cursor’s automation templates are open source on GitHub. If you’re a Cursor user, they’re worth exploring. And if you’re running them alongside Snyk, you’ll get the best of both worlds: agent-powered automation with enterprise-grade validation underneath.

The pieces are all here. Time to put them together.

This is the prompt — the whole thing:

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

It’s the core of Cursor’s Agentic Security Review automation, the one that’s been reviewing 3,000+ internal PRs per week and catching 200+ real vulnerabilities. A role assignment, a goal, a four-step methodology, and a priority list. No elaborate chain-of-thought scaffolding. No pages of few-shot examples. No complex JSON output schemas.

If you’d told me two years ago that a prompt this concise could run at that scale and produce results worth blocking CI on, I would’ve been skeptical. We’ve all been conditioned to think AI prompting requires elaborate engineering: pages of instructions, carefully crafted examples, detailed output specifications. Cursor’s open-sourced templates suggest that for security review, a clear role definition and a structured methodology might be all you need.

That’s a remarkable signal about where frontier models are right now. The model already “knows” what SQL injection looks like, how authentication bypasses work, and what unsafe deserialization means. It just needs a framework for applying that knowledge systematically. If models can do this much with so little instruction today, the trajectory over the next six to twelve months is genuinely exciting.

Of course, the prompt is just the tip of the iceberg. The real engineering achievement here isn’t the 15 lines of instructions; it’s everything underneath: the custom MCP server handling persistence and deduplication, the Terraform-managed deployment pipeline, the webhook orchestration that knows when to trigger which agent, and the state management that lets agents compare findings across runs. The prompt is simple because the surrounding infrastructure is not. That’s an important distinction, and it’s actually the more interesting story: Cursor didn’t just write clever prompts; they built a production-grade agent orchestration platform and then put simple prompts on top of it.

But before we get ahead of ourselves, let’s look at the full picture of what Cursor built, what’s impressive about each piece, and where the gaps are. To do that, it helps to have a framework for thinking about security in agentic development environments.

The three dimensions of agentic security

At Snyk, we think about securing agentic development across three dimensions: the code the agents generate, the supply chain the agents depend on, and the behavior of the agents themselves. The code dimension is the one most people focus on: is the AI writing secure code, and are we catching vulnerabilities before they ship? The supply chain dimension is newer and less obvious: MCP servers, automation templates, agent skills, and plugins are all components your agents depend on, and they carry the same risks as any third-party dependency. The behavior dimension is the most nuanced: are the agents acting within their intended scope, are they making decisions they shouldn’t, and do you have visibility into what they’re actually doing across your organization?

Cursor’s security agents primarily operate in the first dimension, catching vulnerabilities in code. That’s valuable and necessary work. But as you’ll see in the walkthrough below, the other two dimensions matter just as much, especially at enterprise scale. And the organizations getting the best results, like Labelbox, which cleared a multi-year vulnerability backlog by running Cursor and Snyk together, are the ones addressing all three.

The four agents: what’s strong, what’s missing

Today, Travis McPeak published a blog post detailing how Cursor’s security team built four autonomous security agents on top of Cursor Automations (their cloud agent platform) and open-sourced the templates for anyone to use. Their PR velocity had increased 5x over nine months, and traditional static analysis couldn’t keep up. So they built agents that could.

The whole system sits on a foundation that’s worth noting: a custom MCP (Model Context Protocol) server deployed as a serverless Lambda function. It provides persistent state tracking, a deduplication layer powered by Gemini Flash 2.5 (so different agents don’t file the same finding using different words), and consistent Slack output formatting with dismiss/snooze actions. Everything is managed through Terraform. Solid engineering.

Here’s each agent, along with what I think is genuinely impressive and what an enterprise security team should be thinking about.

Agentic Security Review: the PR gatekeeper

What it does: Reviews every pull request against Cursor’s specific threat model. Posts findings to a private Slack channel, comments directly on PRs, and can block the CI pipeline on security findings. The key differentiator from a general-purpose review bot like Cursor’s Bugbot is the ability to prompt-tune specifically for security without blocking on every code quality nit.

What’s impressive: The results speak for themselves. In the last two months, this agent has run on thousands of PRs and prevented hundreds of issues from reaching production. And as I showed above, the prompt driving all of this is remarkably concise. The signal-to-noise ratio, for an LLM-based reviewer, is genuinely surprising.

What to think about: LLMs can confidently flag a “critical SQL injection” in a parameterized query that’s perfectly safe, because the model misread the data flow. They can also miss a real vulnerability because attention drifts across a large codebase. In a security context, both failure modes are expensive: false positives erode developer trust, and false negatives leave real vulnerabilities in production. When your detection layer is entirely probabilistic, you’re accepting both risks. The principle here is simple: the agent cannot mark its own homework. You need an independent validation layer confirming what the LLM found. That’s why layering deterministic SAST analysis (like Snyk Code) underneath the LLM review matters. The deterministic engine catches known patterns with mechanical precision; the LLM catches the novel, cross-file logic bugs that rule-based tools miss. You want both.

Also worth noting: look at the end of the prompt template.

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

The review agent explicitly does not push fixes. It finds, it reports, it blocks, but a human still decides what to do. Even Cursor’s own security team keeps humans in the loop for their own tooling. That should tell you something about where autonomous AI security actually stands today: it’s a powerful accelerator, not a replacement for human judgment. At least not yet.

Vuln Hunter: scanning the existing codebase

What it does: Instead of watching new code come in, Vuln Hunter scans the existing codebase. It divides the repo into logical segments, searches each one for vulnerabilities, and the security team triages findings from Slack. They often use @Cursor directly from Slack to generate fix PRs.

What’s impressive: Pointing LLM reasoning at legacy code is smart. This is where AI shines: understanding complex, undocumented codebases and identifying vulnerabilities that static rules would miss. Cross-file logic bugs, broken access control patterns, and authentication bypasses buried in years-old code. Traditional scanners struggle here because they need well-defined patterns to match against.

What to think about: This is the agent most likely to produce false positives at scale. Scanning an entire codebase (rather than a focused PR diff) means the model is working with a much larger context, and that’s where LLM attention drift becomes a real concern. BaxBench, a benchmark from ETH Zurich, UC Berkeley, and INSAIT, found that 62% of solutions generated by even the best models are either incorrect or contain security vulnerabilities. When the model is reasoning about large, complex codebases, the “agent can’t mark its own homework” principle applies doubly: you want deterministic validation confirming or disproving what the LLM found before anyone spends time on a fix.

Anybump: automated dependency patching

What it does: Tackles the most tedious job in application security: dependency patching. It runs a reachability analysis to filter down to actually impactful vulnerabilities, traces code paths, runs tests, checks for breakage, and opens a PR when tests pass. All automated, with Cursor’s canary deployment pipeline as a final safety gate.

Here’s the core of the prompt:

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

What’s impressive: This addresses a pain point that every security team knows intimately. Dependency patching is so time-intensive that most teams eventually give up and push it to engineering, where it sits in backlogs for months (or years). Automating the reachability analysis, testing, and PR generation is a real workflow improvement.

What to think about: Anybump solves the hardest part of dependency management: actually getting the patch applied, tested, and into a PR. Where it stops is everything around that patch. There’s no SBOM generation, no license compliance check, and no audit trail for your compliance team. Those aren’t shortcomings of the agent so much as they are a different category of problem entirely. Automated patching and enterprise software composition analysis overlap, but they’re not the same thing. If you’re in a regulated industry or shipping software under customer contracts with compliance requirements, you’ll still need that broader infrastructure alongside the automation.

If you’re a startup with one repo, Anybump might be all you need. If you’re operating at enterprise scale (hundreds of repositories, regulated industries, customer contracts requiring specific compliance certifications), you need to know exactly what’s in your software, what licenses you’re using, and you need to be able to prove it. That’s the difference between automated patching and enterprise-grade software composition analysis: they overlap, but they solve fundamentally different problems.

Invariant Sentinel: compliance drift detection

What it does: Runs daily to check for drift against a set of security and compliance properties. It spins up subagents for each logical segment of the repo, compares the current state against previous runs using automation memory, and alerts the security team when something changes.

What’s impressive: The statefulness here is clever. Using the automation’s memory feature to compare across runs means the agent can detect changes in security posture, not just point-in-time snapshots. The ability to write and execute validation code alongside the analysis adds rigor that pure LLM reasoning alone wouldn’t have.

What to think about: Compliance drift detection is valuable, but compliance governance is a broader challenge. Invariant Sentinel tells you when something changed; it doesn’t enforce policy-as-code across hundreds of repos, generate compliance reports for auditors, or give your CISO a dashboard showing risk trends over time. Those are platform-level capabilities that sit above what any single agent can provide.

This is still CI, and CI is not where security should start

Here’s the thing that’s easy to miss when you’re looking at the architecture diagrams and agent orchestration: what Cursor built is, at its core, a really sophisticated CI layer. The agents trigger on GitHub webhooks when PRs are opened or pushed. They review diffs, post comments, block pipelines, and open fix PRs. That’s fundamentally the same control point that traditional security tools have been operating at for years, but it’s smarter now because there’s an LLM doing the analysis instead of a regex-based rule engine.

And look, that’s a real improvement — no argument there. But CI is still the wrong place for security to start.

Why CI is too late for security

Think about it: if you’re using Cursor to write code in your IDE and the vulnerable code makes it all the way to a PR before anyone catches it, you’ve already lost time. The developer context-switches away from the code they wrote, the PR review cycle adds latency, and if the CI check blocks, now the developer has to go back, understand the finding, make a fix, push again, and wait for another review cycle. It’s better than discovering the vulnerability in production, sure, but it’s still the “scan and ticket” model, just compressed into the PR timeline.

What shifting left actually looks like

What you really want is security tooling running directly inside your IDE, triggering scans and remediations immediately as new code is introduced. That way, vulnerable code never makes it into a commit in the first place. Your git history stays clean. Your PRs don’t get blocked because the security issues are caught and fixed in the flow before the developer even stages the change. And you dramatically reduce the need for expensive human-in-the-loop reviews, because if the vulnerability never makes it into a PR, nobody needs to triage it, and nobody’s pipeline gets blocked at 4:30 PM on a Friday.

IDE-first security vs CI-first security

With Snyk Studio, this is exactly how it works. Security guardrails intercept insecure code before the developer even accepts the AI suggestion. The AI assistant runs snyk_code_scan on new code in real time, and if security issues are found, it fixes them right there in the flow. It works directly in Cursor and every other major AI coding assistant. No CI pipeline block, context switch, or cluttered git history.

Why layered security is necessary

Now imagine running both: Snyk Studio at the IDE layer catching the vast majority of issues at the point of creation, and Cursor’s security agents at the CI layer as a safety net for anything that slips through. You get defense in depth, with most of the work handled silently in the IDE and the expensive human reviews reserved for genuinely complex cases. Given what BaxBench tells us about the insecurity rate of AI-generated code (62% of solutions from top models contain vulnerabilities or are incorrect), this kind of layered protection isn’t a nice-to-have. It’s essential.

And even beyond the CI question, a security program is much more than CI checks. It’s centralized dashboards aggregating risk across hundreds of repositories. Its SAST findings correlated with DAST results, confirming that the same endpoint is exploitable at runtime. It’s your SCA engine identifying that the ORM library you’re using has a known CVE that bypasses parameterization in certain edge cases, and connecting that to the SAST finding in the same controller method. Individually, each of those is a data point. Together, correlated on the same platform, they tell you exactly what’s happening, why, and what to fix first. A code scanner, even an autonomous one with four agents and impressive PR throughput, doesn’t answer those questions. A security platform does.

Validation, not competition (and we’re already integrated)

I wrote a few weeks ago about Anthropic’s Claude Code Security launch and made the case that AI coding platforms investing in security is validation, not disruption. The same logic applies here: When the biggest names in AI development tooling start building security features, it means the industry has figured out that security in AI-assisted development is infrastructure, not an optional add-on.

How Cursor and Snyk work together

Cursor and Snyk aren’t ships passing in the night; Snyk is already in Cursor’s MCP Directory. We have a verified extension. We ship Evo Agent Guard via Hooks. Cursor is our AI Innovation Partner of the Year as of two weeks ago. This isn’t an adversarial relationship; it’s the two-tier architecture in action. Think of it this way: AI agents are the researchers, discovering vulnerabilities and proposing fixes with speed and creativity. Deterministic validation is a peer review that independently confirms that the findings are real and the fixes are sound.

The two-tier security architecture

You wouldn’t publish a paper without peer review, and you shouldn’t ship a security fix without deterministic validation. Cursor provides the research layer (agent orchestration, webhook triggers, automated PR generation). Snyk provides the peer review, governance, and breadth of coverage across the entire software supply chain.

And this is already working in the real world: Labelbox runs Cursor + Snyk together in production and was able to clear a multi-year vulnerability backlog. Cursor automates the remediation workflows; Snyk ensures those fixes are real and enterprise-grade.

The agentic supply chain is the new attack surface

Take a step back from Cursor’s specific implementation and look at what’s actually happening across the industry. Over the past year, an entirely new software supply chain has emerged, and it’s growing fast: MCP servers, agent skills, automation templates, AI tool plugins, and custom model configurations. Call it the agentic supply chain. It’s the collection of components that AI-powered development tools depend on to function, and right now, almost no one is securing them.

This isn’t a theoretical concern. In January 2026, Snyk’s research team discovered hundreds of malicious skills on ClawHub, the first major supply-chain attack targeting AI agent ecosystems. Think about that in the context of what Cursor just open-sourced: automation templates that run with access to your codebase, your CI pipelines, your Slack channels, and your GitHub repos. An MCP server deployed as a Lambda function that processes every security finding in your organization. These are powerful, privileged components. And the ecosystem for distributing and discovering them (marketplaces, template galleries, open source repos) is growing much faster than the security practices around it.

The traditional software supply chain took decades to develop the tooling we rely on today: package registries with signature verification, SBOMs, license scanners, and vulnerability databases. The agentic supply chain lacks that infrastructure yet, and it’s already being adopted at scale. Every organization installing MCP servers, importing automation templates, or connecting agent skills to their development environment is extending their attack surface in ways that code-level scanning, no matter how sophisticated, simply doesn’t address.

This is exactly the problem Evo by Snyk was built to solve. Evo is our agentic security orchestration system designed for the AI-native development landscape: AI threat modeling that builds live threat models from your code, AI red teaming that runs continuous adversarial testing against your models and agents, AI-SPM so you know exactly which AI models and frameworks are running across your organization (including the “shadow AI” that security teams don’t even know about), and Agent Scanning for visibility into all toolchains with real-time guardrails.

When you’re running autonomous security agents across your codebase, you need to secure those agents too. The tools in your agentic supply chain are every bit as critical as the npm packages in your node_modules, and they deserve the same rigor.

What’s next: the questions this raises

Rather than wrapping up with a thesis I’ve already written about, let me end with the forward-looking questions that Cursor’s announcement opens up. Because I think this is more interesting than looking backward.

Try it yourself

Snyk Studio is free, and setup takes minutes. It works in Cursor (along with virtually every other AI coding assistant). You’ll get deterministic scanning and the /snyk-fix remediation command running in your IDE in about five minutes. If you want to see layered security in practice, this is the fastest path.

Evo by Snyk is where you go when you need to secure the AI stack itself: threat modeling, red teaming, AI-SPM, agent scanning, and agentic security orchestration. If your organization is adopting AI coding tools at scale (and let’s be real, you probably are), Evo gives you the visibility and guardrails to do it safely.

Cursor’s automation templates are open source on GitHub. If you’re a Cursor user, they’re worth exploring. And if you’re running them alongside Snyk, you’ll get the best of both worlds: agent-powered automation with enterprise-grade validation underneath.

The pieces are all here. Time to put them together.

AI coding assistants are quietly resurrecting millions of abandoned open source packages. For the last decade, developers relied on a simple heuristic for open source security: Prevalence = Trust. If a package was downloaded millions of times a week (lodash, react, requests), we assumed it was "safe enough" because thousands of eyes were on it. If it was obscure, we approached with caution.

Human developers follow social signals of trust, such as popularity, maintenance activity, and community adoption, and this “Wisdom of the Crowds” model worked because human developers are fundamentally social. We stick to the “paved roads” built by our peers. Generative AI, however, is starting to break this model.

AI systems select packages based on statistical patterns in training data that span the entire history of the internet, including millions of abandoned projects and experimental repositories. LLMs are stochastic; they do not understand “popularity” or “maintenance health” in the way a human architect or engineer does. Rather, they understand statistical probability based on training data that spans the entire history of the internet, including the good, the bad, and the abandoned.

We built Snyk Advisor and then merged it into our Security DB to help bridge the gap between open source intelligence and package health, providing developers and agents with various data points on security, popularity, maintenance, and community. How does Snyk’s package health amplify AI agents? Here’s our take on it.

The data: Visualizing the “Dormant Majority”

When we analyze the open source ecosystem, a striking pattern emerges. A very small number of packages power most of the modern internet, while the vast majority are rarely used or have been completely abandoned.

To understand the risk, we need to revisit the structure of the open source ecosystem. Snyk contributed key data to the Linux Foundation & Harvard Census II Report, mapping the reality of the supply chain. When we overlay package health data on top of prevalence, a stark hierarchy emerges:

| Usage Tier | Found in % of Projects | Population Size (Approx.) | Description | Package health on Snyk Advisor | Examples | | — — | — — | — — | — — | — — | — — | | The Global Constants | 90% — 100% | ~1,000 packages | The “plumbing” of the internet. Deep transitive dependencies almost every modern app relies on. | lodash - scored 86/100 chalk - scored 92/100 requests - scored 88/100 | chalk, lodash, requests, openssl | | The Industry Standards | 15% – 50% | ~20,000 packages | The primary frameworks developers explicitly choose to build core architecture. | react - scored 89/100 next - scored 89/100 | React, Pandas, Next.js, FastAPI | | The Domain Specialists | 1% – 5% | ~100,000 packages | Professional-grade tools for specific industries or complex technical niches. | tensorflow - scored 75/100 scipy - scored 88/100 stripe-node- scored 63/100 | TensorFlow, Stripe-node, SciPy | | The Long-Tail Active | < 0.1% | ~600,000+ packages | Valid, working code used in very specific scenarios or by a dedicated community. | | HL7-parser, specialized CAD tools | | The Dormant Majority | ~0% | ~6.3 Million+ packages | The 89.5%. Abandoned projects, "Hello World" tests, unmaintained forks, single-use experiments. | | test-pkg-v1, my-first-app-123 |

Nearly 90% of the open source ecosystem belongs to the Dormant Majority — millions of abandoned experiments, forks, and unmaintained projects. Human developers rarely select packages from this tier; AI systems, however, do.

The AI disconnect

Human developers naturally stay in the top tiers of the ecosystem — widely used frameworks, trusted infrastructure libraries, and mature domain tools. Because LLMs are trained on vast repositories of code spanning the entire history of the internet, they may surface packages from anywhere in the ecosystem, including the Dormant Majority.

As a result, LLMs can recommend packages from the bottom 89.5% of the ecosystem: abandoned projects, unmaintained forks, and even simple “Hello World” experiments. For example, security researcher Luke Hinds shared an interaction where an LLM recommended the Go package gorilla/sessions:

The problem with this LLM recommendation is that gorilla/sessions has been archived. Because archived repositories no longer receive updates, using this package introduces long-term maintenance debt and unpatched supply chain risks.

Worse, LLMs suffer from hallucinations (or “AI Package Hallucinations”), confidently recommending packages that never existed. This creates two new attack vectors:

1. The zombie resurrection: An LLM suggests an unmaintained, 5-year-old package from the “Dormant Majority” because it solves a specific niche problem. It has 0 CVEs (because nobody looks for them) but contains critical flaws.
2. Slopsquatting (AI Hallucination Attacks): Attackers predict common package names that LLMs hallucinate (e.g., huggingface-cli-tool vs the real huggingface-cli) and register them with malicious payloads. When an AI suggests this “logical” but fake package, the developer installs malware.

The strategic pivot: From “popularity” to “provenance”

As a CISO, you cannot rely on your developers to manually vet every AI suggestion. The velocity is too high. You need to shift your program from “scanning for bad” to “ensuring good”. In past write-ups, we’ve outlined the roles of CISOs and evolving responsibilities.

Similarly, as an engineer, you simply cannot rely on AI coding agents end-to-end to choose and install packages from npm or PyPI because of the inherent risk of the software supply chain that could result in a bad package that introduces malware or data harvesting, such as via npm’s postinstall package manager capabilities.

How do we equip AI coding agents and software engineers with package health heuristics to achieve more secure, autonomous results? With Snyk’s paved road.

1. Discover trusted packages with security.snyk.io

Before selecting a dependency, developers and AI systems need visibility into the reputation and trustworthiness of open source packages. The new Snyk Security Database experience provides a centralized view of package trust signals, helping teams quickly identify widely adopted, well-maintained, and reputable projects across supported ecosystems.

Strategy: Encourage developers and platform teams to use Snyk Security Database insights during package discovery to prioritize mature, trusted dependencies early in the selection process.

2. Snyk Package Health API helps verify health, not just vulnerabilities

A package with zero known vulnerabilities is not necessarily safe. It may be abandoned, unmaintained, or lacking a trusted community. Secure software supply chains require evaluating package health beyond CVEs. The Snyk Package Health API provides package-level and version-level intelligence across major ecosystems (npm, PyPI, Maven, NuGet, and Go), exposing signals such as:

• Security posture.
• Maintenance activity and lifecycle indicators.
• Popularity and adoption metrics.
• Community engagement signals.

This allows engineering platforms, CI/CD pipelines, and AI-driven development tools to automatically evaluate the quality, sustainability, and ecosystem risk of a dependency at the moment it is being considered — especially at the moment a dependency is being selected or introduced.

Strategy: Integrate package health intelligence directly into dependency-selection workflows and AI-assisted development environments, so package suitability can be evaluated before a dependency is added, not after it is installed.

Tooling: Use the Snyk Package Health API to inform package selection, upgrade planning, and automated dependency governance. See the Package level endpoint and the Package version level endpoint for implementation details.

If you integrate with an SCA via CLI, CI, or GitHub CI checks, then during and before a build, Snyk Open Source will also be catching these ill-recommended LLM coding suggestions (imagine the coding agent plans to run an npm install … for a malicious package).

3. Enforce dependency safety at introduction with Snyk Studio

Even when intelligence is available, developers and AI coding assistants may still introduce dependencies automatically. Security must so be enforced at the moment a dependency is selected, not only during CI/CD scans.

The Snyk Studio Package Health flow integrates package health intelligence directly into AI-assisted development workflows. When an AI coding assistant proposes adding or updating a dependency, Snyk Studio can automatically invoke the package health check before the dependency is installed, ensuring that risk signals are evaluated in real time. This allows organizations to prevent unhealthy, unmaintained, or risky packages from entering their codebase at the earliest possible stage — the “secure at inception” moment.

Strategy: Configure AI coding assistants to automatically run Package Health checks before introducing new dependencies, pausing or blocking installation when risk signals are present, and requiring explicit user approval to proceed.

4. Defend against hallucinations

AI coding assistants may occasionally recommend packages that do not exist in public registries. These “package not found” events should be treated as potential supply-chain security signals rather than simple developer errors, as attackers may later register packages with similar names to exploit these mistakes.

Strategy: Treat dependency-resolution failures (for example, “package not found”) as security-relevant events. Investigate the source of the dependency suggestion and validate whether the package name is legitimate before proceeding.

In the following image, you can see how Snyk Studio is invoked by the Windusrf coding agent to perform package health analysis via the snyk_package_health_check tool, which is part of other security tools in the Snyk MCP Server. With Snyk Studio installed, the AI agent can then confirm the package is maintainable, has no security issues, and is not malicious.

Snyk’s mission to secure AI-generated code

We built Snyk on the belief that developer-first security is the only way to scale. In the world of AI coding agents, this is doubly true. The Census II data shows us that the open source ecosystem is vast and mostly dormant.

Our job is to keep your AI and developers focused on the healthy, vibrant top tiers, the 10% that powers the world, and to automate defenses against the chaotic 90%. Don’t let your AI verify trust. Verify the AI’s trust.

Want to learn more about how AI coding assistants are reshaping software supply chain risk? Explore our guide on securing Python in the age of AI.