1Overview
The set of attacks that reach you through what an AI suggests you install or connect: invented package names, poisoned tool descriptions, and dependencies nobody chose deliberately.
Every coding chapter in this course assumes the agent's output compiles. This one assumes it does not — specifically, that it imports a package that does not exist, and that somebody has already registered that name. → Slopsquatting is the attack: models invent plausible dependency names at a measurable rate, attackers publish those names, and the install command runs before anybody reads the diff. → The defence is boring and effective — a gate on every install, provenance checks, and a lockfile you actually diff. Anchored on live tooling, with an honest note on which of it just got acquired.
1.2After this chapter you can
→Explain slopsquatting and why an AI-suggested dependency is a distinct attack surface
→Gate every package install behind a registry and provenance check
→Spot a hallucinated import in a diff before it reaches a lockfile
→Scan an MCP server or agent tool for prompt-injection and tool-poisoning risks
→Decide what an agent may install unattended and what needs a human
→Track a tool through an acquisition without assuming the old guidance still holds
1.3When to reach for it
Before the first time an agent runs an install command on your machine or in your CI. It is a prerequisite, not a hardening step.
1.4Key parts
An install-time gate around npm/pnpm/pip/uv, a provenance check, a scanner for MCP servers and agent tools, and a reviewed lockfile.
1.5Free vs paid
Both anchors are open source and free to run locally; one is now vendor-owned after an acquisition, which changes the roadmap, not today's command.
1.6Watch out
The dangerous install is the one that succeeded. A phantom package that 404s is a broken build; a phantom package that resolves is a compromise.
2Lessons 7
2.1 Spot the risk of AI‑generated fake dependencies
A hallucinated package is an LLM‑invented dependency name that appears confidently despite not existing on any registry.
Identify hallucinated packages and understand why they create a unique attack vector.
- Read the definition of a hallucinated package as an LLM‑invented dependency name.
- Examine the USENIX Security 2025 results that quantify hallucination rates across models.
- Identify repeated hallucinated names that could be registered for malicious use.
- You'll see The coding assistant suggests the same non‑existent utility on separate occasions, showing a repeatable hallucinated name.
- Takeaway Hallucinated packages appear confidently yet unverified, occurring in at least 5 % of commercial and 20 % of open‑source model outputs, making them attractive for slopsquatting
- Check How does the chapter quantify the prevalence of hallucinated packages in commercial versus open‑source model outputs?
- Cost Free to understand. The paper itself is free to read (arXiv:2406.10279); the gates in the rest of this chapter are also free and open source.
2.2 Block malicious packages before they reach disk
safe‑chain is a local proxy that wraps npm/yarn/pnpm/bun and pip/uv/poetry/pipx commands, intercepting installs younger than 48 hours.
Put a real gate around every package install your terminal or agent runs so a bad name never reaches disk in the first place
- Download and execute the installer script with
curl -fsSL https://github.com/AikidoSec/safe-chain/releases/download/1.5.15/install-safe-chain.sh -o /tmp/install-safe-chain.sh && sh /tmp/install-safe-chain.sh && rm /tmp/install-safe-chain.sh - Restart your terminal so the newly created shell aliases become active
- Run npm safe-chain-verify (or pip safe-chain-verify) and look for
OK: Safe-chain works! to confirm interception - Attempt to install a test package with npm install safe-chain-test (or pip3 install safe-chain-pi-test) and verify that it is blocked
- You'll see
npm install safe-chain-test blocked with a warning naming the package as flagged, instead of the install silently succeeding. - Takeaway safe‑chain wraps npm/yarn/pnpm/npx/bun and pip/uv/poetry/pipx behind a local proxy, needs no login, and defaults to rejecting anything younger than 48 hours — install it before the first agent‑run install command, not after an incident
- Check What mechanism does safe‑chain use to prevent a newly installed package from reaching the filesystem, and how can you verify it worked?
- Cost Free, no account. One terminal restart after install; effectively zero added latency per install once the proxy is warm.
2.3 Identify hallucinated dependencies in a code diff
The lesson focuses on examining package.json, requirements.txt or pyproject.toml entries for new imports and verifying them against the package registry.
Spot and reject any unexpected package names before they reach the lockfile
- Open the pull‑request diff and locate each new import or entry in
package.json, requirements.txt or pyproject.toml - Question each new name: does it exist on the expected package registry and does it match the intended functionality
- Visit the package’s registry page and review its publish date, download count and version history
- If the name is unfamiliar or originates from an AI‑generated suggestion, confirm with the author whether a human selected it before merging
- You'll see A diff showing a single new line in
package.json among many unrelated changes - Takeaway Treat every newly added dependency as unverified until you have manually checked its registry entry
- Check When reviewing a pull‑request diff, what three registry attributes should you check to confirm a newly added dependency isn’t hallucinated?
- Cost A minute per new dependency in review. Cheap next to reverting a lockfile after the fact.
2.4 Scan MCP servers for tool‑poisoning
The --dangerously-run-mcp-servers flag instructs the scanner to start the MCP server and read live tool descriptions for poisoning warnings.
Identify and flag tool‑poisoning in an MCP server or agent description.
- Set your Snyk API token in the environment, e.g.
export SNYK_TOKEN=your-api-token-here. - Install uv if it is not present and then run the scanner with uvx to make it available, e.g.
uvx snyk-agent-scan@latest. - Run uvx snyk-agent‑scan@latest with the path to a configuration file or skills directory, such as
~/.vscode/mcp.json or ~/.claude/skills. - Include the --dangerously-run-mcp-servers flag when scanning an MCP server so the scanner starts the server and reads its live tool descriptions.
- Review the human‑readable summary printed by the scanner for any tool‑poisoning warnings.
- You'll see The scanner reports a finding where a tool description contains malicious instructions aimed at the model.
- Takeaway Tool descriptions are part of the model's attack surface, so scanning must read them by running the server with an explicit flag
- Check Which flag must be added to the Snyk scanner command to force it to run an MCP server and inspect its tool descriptions?
- Cost Free tool, but a Snyk account and API token are required to run it — budget five minutes to sign up before the first scan.
2.5 Determine which tasks an unattended agent may run
A safety gate flag such as --dangerously-run-mcp-servers marks commands that start services, modify lockfiles or grant permissions as requiring human review.
Apply a clear rule to separate safe automated checks from actions that require human approval
- Identify the tool you are configuring and locate its safety gate flag, such as --dangerously-run-mcp-servers in agent‑scan.
- Place any install or execution command behind the safe-chain proxy so it runs without prompts in CI pipelines.
- Mark commands that only read configuration or inspect traffic as safe to automate, for example running a scanner that outputs a report.
- Require manual confirmation for actions that start services, modify lockfiles or grant permissions by adding the dangerous flag and documenting the need for human review.
- You'll see A CI job runs silently with the safe‑chain proxy, while the dangerous flag forces a manual step.
- Takeaway Automate only read‑only checks and require a person for any command that starts processes, writes files or grants access
- Check How does the lesson distinguish between actions that can be automated safely and those that require manual human approval?
- Cost No added cost — this is a review habit, not a tool.
2.6 Identify changes after a security‑tool acquisition
The process involves cloning the new repository, checking its README for authentication instructions, setting tokens, running a test scan, and searching GitHub for the original repo name.
Determine which aspects of a security tool have changed after it is acquired and which remain the same
- Clone the current repository using git clone from the new organisation URL
- Open the cloned folder’s README.md and locate any authentication instructions
- Set the required token with export SNYK_TOKEN=… if the README mentions it
- Run a test scan to confirm the tool works, observing whether the token is accepted
- Search GitHub for the original repository name using the GitHub search bar to compare documentation
- You'll see The same project listed under two different GitHub organisations, each with its own documentation
- Takeaway An acquisition alters ownership and required credentials, not the underlying scanning technique
- Check What steps are used to compare the documentation of a security tool before and after an acquisition to spot changes?
- Cost A few minutes to re-check a tool's current repository before trusting cached instructions — cheapest insurance in this whole chapter.
2.7 Verify a new dependency through all security gates
The verification flow uses safe‑chain as an install‑time proxy, inspects the package’s publish metadata on its registry page, and scans any related MCP server or agent descriptions for safety.
Run a dependency addition through every gate and know which actions are automated versus manual
- Confirm that safe-chain (or an equivalent install‑time proxy) is active in the current shell or CI runner before executing the install command
- Open the dependency’s registry page and examine its publish date, download count and version history to verify it is not a recent hallucination
- Scan any tool description that adds or changes an MCP server or agent using your chosen scanner before wiring it into an unattended session
- For each install and scan step, decide whether it only checks or also writes or grants access, automating the former and keeping a human in the loop for the latter
- You'll see The dependency passes the proxy check, registry review, description scan and human sign‑off without any step being skipped
- Takeaway Each gate catches a different risk point so all must be used and a human must approve anything that executes
- Check In verifying a new dependency, how does the lesson combine proxy checks, registry review, and tool‑description scanning to decide which steps are automated versus manual?
- Cost A few minutes added to a dependency add that would otherwise take seconds. Cheaper than any of the incidents this chapter is named for.