AI Developer Supply Chain Incident Response: What to Check After a Tool or Package Compromise

AI Developer Supply Chain Incident Response When a trusted package, AI SDK, editor extension, or CI workflow gets poisoned, the first mistake is treating it like a normal dependency update. It is not. It is a workstation and credentials incident. For developers, AI builders, DevOps teams, and technical founders responding to modern package and AI-tool compromises. The uncomfortable part of modern software supply-chain attacks is how ordinary they look at first. A developer runs npm install. A CI runner restores a cache. A Python package imports normally. A VS Code extension updates in the background. An AI coding assistant suggests a dependency that seems to solve the problem. Nothing feels like a breach until the postmortem arrives. That is why developers need a sharper incident-response habit. The question is no longer only, “Did we install a bad version?” It is, “What did that version get to see, execute, read, cache, modify, or publish before we noticed?” The May 2026 Mini Shai-Hulud wave made that lesson hard to ignore. SafeDep reported a coordinated campaign that compromised more than 170 npm packages and 2 PyPI packages, totaling 404 malicious versions across projects including TanStack, Mistral AI, UiPath, OpenSearch, and Guardrails AI. The Register also described how malicious TanStack packages were published in a narrow May 11 window and how affected developer or CI environments were advised to be treated as compromised if they ran install commands against the bad versions. InfoQ summarized TanStack’s postmortem as a chain involving GitHub Actions cache poisoning, unsafe workflow behavior, token extraction, and npm publishing through OIDC. That combination matters. These incidents are not just “someone uploaded a bad package.” They are closer to a temporary remote execution event inside the most sensitive part of your engineering system: laptops, package managers, editor extensions, secrets, build logs, cloud credentials, and release pipelines. In 2026, your developer workstation is part of the production attack surface. Treat it that way. The new blast radius: AI tools, packages, and CI are now one system Traditional software supply-chain guidance often starts with inventory: know your dependencies, scan vulnerabilities, pin versions, and update quickly. That still matters. But AI developer workflows have changed where risk enters. An AI coding tool may recommend a package. A model gateway or SDK may be pulled into a notebook, backend service, or internal automation. A local extension may receive source code context, environment context, and shell access. A CI workflow may hold short-lived publish authority. A package postinstall script may read files before your application ever imports it. The boundary between “developer convenience” and “trusted execution” has become thin. If a compromised artifact executes in a developer or CI environment, it may be able to inspect: Environment variables with cloud, database, model API, package registry, or webhook secrets. Local files such as .npmrc, .pypirc, shell history, SSH keys, editor settings, and AI tool configuration. GitHub, GitLab, npm, PyPI, Docker, Vault, Kubernetes, and cloud credentials. CI caches, workflow tokens, build artifacts, lockfiles, and release metadata. Prompt, tool, or extension configuration that changes what an AI assistant can read or execute. This is why “just downgrade the package” is an incomplete response. Downgrading removes one known bad artifact. It does not undo the possibility that credentials were copied, CI state was poisoned, hooks were added, or a local developer tool was modified. What makes the AI developer version different? AI builders tend to move fast across experimental packages. They install SDKs, vector database clients, eval frameworks, model routers, browser automation tools, notebook utilities, and agent frameworks. Many of these tools request broad permissions because the workflow itself is broad: read files, call APIs, execute commands, spin up local servers, connect to cloud services, and modify code. That makes AI development productive. It also means an incident can cut across more systems than a typical frontend dependency compromise. There are three practical differences. First, AI tooling often handles high-value secrets. Model API keys, cloud credentials, vector database tokens, observability keys, and customer-data access may sit in the same dev environment. A compromised dependency does not care that a key was “only for testing” if it can still spend money, read data, or call internal services. Second, AI coding tools can amplify dependency decisions. A human may review a new package carefully. An assistant may add it as a convenience during a refactor, test scaffold, or prototype. If teams approve large AI-generated diffs quickly, a malicious or typosquatted package can become normal before anyone has asked why it exists. Third, many teams are adding agent-like workflows to CI. The moment a workflow can reason, install, patch, publish, or comment with broad repository permissions, dependency compromise becomes a control-plane problem. The attacker is not merely stealing source code. They may be borrowing the permissions your automation already has. The first 30 minutes: contain before you clean The goal of the first 30 minutes is not to prove everything. It is to stop making the situation worse while preserving enough evidence to make good decisions. 1. Stop install and build activity Pause CI workflows that install dependencies from public registries. Temporarily disable auto-merge, release workflows, scheduled dependency updates, and any agent workflow that can run shell commands or modify dependencies. Ask developers not to run fresh installs until the affected package list, time window, and lockfile guidance are clear. This sounds obvious, but many teams keep rebuilding while investigating. That can destroy evidence, refresh poisoned caches, trigger more installs, and rotate logs out of retention. 2. Isolate affected machines and runners If a developer machine or CI runner installed an affected package during the incident window, treat it as potentially compromised. Disconnect it from sensitive networks if practical. Do not immediately wipe it unless your policy requires it. You may need logs, lockfiles, shell history, process lists, and file timestamps to understand what happened. For ephemeral CI runners, preserve job logs, artifacts, caches, workflow metadata, and environment-variable exposure records before cleanup. If you use self-hosted runners, assume persistence is possible until proven otherwise. 3. Freeze dependency state Copy the lockfiles, package manifests, container digests, build logs, and dependency install logs from affected repositories. You want to know exactly what resolved at the time of install, not what resolves now. # JavaScript projects cp package.json package-lock.json pnpm-lock.yaml yarn.lock ./incident-snapshot/ 2>/dev/null || true npm ls --all > ./incident-snapshot/npm-tree.txt 2>&1 # Python projects cp pyproject.toml poetry.lock requirements*.txt ./incident-snapshot/ 2>/dev/null || true python3 -m pip freeze > ./incident-snapshot/pip-freeze.txt # Containers docker image ls --digests > ./incident-snapshot/docker-images.txt Do not rely only on package names. Record versions, resolved URLs, integrity hashes, commit SHAs, container digests, and CI run IDs. The credential rule: rotate by exposure, not by confidence Developers often ask, “Do we know the secret was stolen?” That is the wrong threshold. If malicious code executed in an environment where a secret was readable, rotate it. You are not rotating because you have proof. You are rotating because you no longer have trust. Start with credentials that can publish, deploy, access customer data, spend money, or mint more credentials. Then rotate read-only credentials if they can expose sensitive code, data, logs, or model prompts. High-priority rotations include: Package registry tokens for npm, PyPI, GitHub Packages, Docker registries, and private package feeds. GitHub and GitLab personal access tokens, deploy keys, fine-grained tokens, and app credentials. Cloud keys for AWS, GCP, Azure, Kubernetes, Vault, and service accounts. Model provider API keys and AI gateway keys, especially if they can access production usage or fine-tuned assets. Database, analytics, observability, webhook, email, and payment credentials present in local or CI environments. SSH keys and signing keys found on machines or runners that executed affected installs. Rotate in an order that does not lock you out of evidence. For example, preserve CI logs and token metadata before revoking the accounts needed to query them. Then revoke and replace aggressively. Check the places normal dependency scanners miss Vulnerability scanners are useful, but a supply-chain incident needs a wider search. The question is not only “Is the package vulnerable?” It is “What changed because that package ran?” Editor and AI tool configuration Inspect VS Code, JetBrains, terminal, shell, and AI-assistant config directories for suspicious extensions, hooks, startup commands, MCP or tool server definitions, shell aliases, proxy settings, and injected instructions. A poisoned dependency may try to add persistence or alter a tool the developer already trusts. Look for changed files around the incident window: # macOS/Linux examples find ~/.vscode ~/.config ~/.npm ~/.cache ~/.ssh ~/.cursor ~/.claude ~/.codex \ -type f -mtime -7 -maxdepth 5 2>/dev/null | sort grep -R "curl .*|.*sh\\|wget .*|.*sh\\|base64\\|webhook\\|token\\|preinstall" \ ~/.vscode ~/.config ~/.npm ~/.cursor ~/.claude ~/.codex 2>/dev/null Do not assume every result is malicious. The point is to find unexpected changes worth reviewing. Package lifecycle scripts Many attacks rely on install-time execution. Review preinstall, install, postinstall, prepare, and Python packaging hooks. A package can execute before a developer ever imports it. # Find lifecycle scripts in a JavaScript dependency tree find node_modules -name package.json -maxdepth 5 -print0 | xargs -0 jq -r 'select(.scripts) | .name + " " + (.scripts | tostring)' \ 2>/dev/null | grep -Ei "preinstall|postinstall|prepare|curl|wget|node -e|bash" For Python, inspect wheel metadata, setup hooks, .pth files, and unexpected startup behavior. In AI projects, pay close attention to packages that wrap model providers, load plugins, or modify import paths. CI caches and workflow permissions The TanStack incident made one point especially clear: a clean source tree does not guarantee a clean build if the CI cache is hostile. Delete caches for affected workflows and rebuild from known-good dependencies. Review workflows that use pull_request_target, restore caches from untrusted branches, run scripts from forks, or allow broad write permissions. Use narrow workflow permissions by default: permissions: contents: read jobs: test: permissions: contents: read publish: permissions: contents: read id-token: write Publishing jobs should be boring, minimal, and isolated. They should not restore broad caches from untrusted contexts. They should not run arbitrary contributor-controlled scripts before minting publish authority. Provenance helps, but it does not replace incident response npm’s trusted publishing documentation explains that OIDC-based trusted publishing removes the need for long-lived npm tokens and can automatically generate provenance attestations for qualifying public packages. That is a meaningful improvement. Long-lived tokens are easy to leak, hard to rotate, and often too broad. But provenance answers a specific question: where and how was this package built? It does not prove the build context was safe. If a workflow, cache, runner, or dependency path was compromised before the signed build, the artifact can still be harmful. So use provenance as one control, not the whole strategy. Prefer trusted publishing where available. Verify attestations for critical dependencies. Restrict publish workflows. Remove unnecessary automation tokens after migration. But also sandbox installs, delay risky upgrades, scan lockfile diffs, and make suspicious dependency changes visible during code review. A practical prevention baseline for AI developer teams You cannot prevent every registry compromise. You can make the blast radius smaller and the response faster. Use disposable environments for risky installs Run unfamiliar repositories, AI-generated dependency changes, and new SDK experiments in containers, devcontainers, cloud workspaces, or throwaway virtual machines. Do not test random client repositories, agent-generated package additions, or untrusted demos on the same laptop profile that holds production credentials. Give AI tools less ambient authority AI coding tools should not inherit every secret by default. Separate development keys from production keys. Use project-scoped credentials. Keep package publishing, cloud admin, and database admin credentials out of daily editor sessions. Put the most powerful actions behind explicit human-controlled workflows. Review dependency changes as security changes Every new package is new executable code. Require PRs to explain why a new dependency is needed, whether it runs lifecycle scripts, who maintains it, how active it is, whether it has provenance, and what permissions it touches. For AI-generated code, add one more review question: did the assistant choose the package, or did a human choose it? If the assistant chose it, slow down and verify. Add install-time policy Use lockfiles, package integrity checks, dependency cooldown policies, registry allowlists for critical systems, and tools such as npm audit signatures, pip-audit, osv-scanner, Socket, StepSecurity, Semgrep Supply Chain, or equivalent controls that fit your stack. The tool matters less than the policy: risky packages should be blocked before they execute. Keep a dependency incident runbook Write down who can pause CI, revoke tokens, query audit logs, delete caches, rotate cloud keys, publish advisories, and approve clean rebuilds. During an incident, a clear runbook beats a heroic Slack thread. Clean rebuild beats “surgical cleanup” After containment and evidence collection, resist the urge to surgically remove only the known bad package and keep going. For developer machines with sensitive access, the safer default is a clean rebuild from a known-good baseline. For CI, rotate credentials, delete caches, rebuild images, rehydrate runners, and redeploy from verified source and lockfiles. A clean rebuild is slower in the moment. It is faster than spending three weeks wondering whether a hidden hook, modified extension, poisoned cache, or copied token is still in play. Use this decision rule: If the environment had production credentials, rebuild it. If it could publish packages, rebuild it. If it could deploy infrastructure, rebuild it. If it ran untrusted install scripts and you cannot fully inspect what happened, rebuild it. If it only ran inside a disposable sandbox with no secrets, destroy the sandbox and recreate it. The article-worthy takeaway for technical leaders The most important shift is cultural. Developers have been trained to think of dependencies as productivity. Security teams have been trained to think of dependencies as inventory. Modern AI developer workflows require a third view: dependencies are delegated execution. When a package, extension, tool server, or AI-generated dependency enters your workflow, it may run code, read context, call APIs, and influence other tools. That is powerful. It is also exactly why the incident response has to start at the developer environment, not only at the production service. The best teams will not be the ones that never install a bad package. That is unrealistic. The best teams will be the ones that notice quickly, stop execution, preserve evidence, rotate by exposure, rebuild cleanly, and reduce the next blast radius before the next campaign arrives. FAQ What is AI developer supply chain incident response? It is the process of containing, investigating, and recovering after a compromised package, AI SDK, editor extension, agent tool, CI workflow, or developer dependency may have executed inside an engineering environment. It focuses on credentials, local machines, CI runners, package state, and trusted automation. Should I rotate secrets if I only installed the package locally? Yes, if the malicious package could read those secrets. Rotate based on exposure, not proof of theft. If a model API key, cloud key, registry token, SSH key, or database credential was present in the environment, treat it as untrusted. Are lockfiles enough to prevent supply-chain attacks? No. Lockfiles help by making dependency resolution predictable, but they do not protect you if the locked version itself is malicious, if a cache is poisoned, or if the lockfile was changed by an unsafe workflow. They are necessary, not sufficient. Does npm trusted publishing solve this problem? Trusted publishing reduces risk from long-lived npm tokens and can add provenance attestations, but it does not prove every build input was safe. Teams still need isolated workflows, narrow permissions, cache hygiene, dependency review, and incident-response plans. How should AI coding assistants handle new dependencies? They should propose dependencies, not silently normalize them. Require human review for new packages, lifecycle scripts, transitive dependency changes, and permission-expanding tool configuration. Treat assistant-added dependencies as security-relevant changes. When should a developer machine be rebuilt? Rebuild when the machine ran affected install scripts and had production credentials, publishing authority, deployment access, SSH keys, or other sensitive tokens. If you cannot confidently inspect the system state, a clean rebuild is usually cheaper than lingering doubt. What should I add to my incident runbook this week? Add owners and commands for pausing CI, collecting lockfiles and logs, deleting caches, revoking package registry tokens, rotating cloud keys, disabling risky AI tool integrations, rebuilding runners, and approving a clean release. Keep the runbook short enough that developers will use it under pressure. Sources and further reading: SafeDep’s analysis of the May 2026 npm and PyPI campaign, The Register’s TanStack coverage, InfoQ’s summary of TanStack’s postmortem, and npm’s trusted publishing documentation. AI Developer Supply Chain Incident Response: What to Check After a Tool or Package Compromise was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.