---
title: "The Agent Supply Chain: Skills Are Dependencies Now"
description: "The agent supply chain is every MCP server and skill your agent installs. Snyk scanned 3,984 skills: 13.4% had a critical issue and 76 carried live malware."
author: "MDflow"
date: 2026-09-09
reading_time: "15 min"
canonical_url: https://mdflow.cz/blog/agent-supply-chain-security
md_url: https://mdflow.cz/blog/agent-supply-chain-security.md
---

# The Agent Supply Chain: Skills Are Dependencies Now

*Published September 9, 2026 · 15 min read*


Most teams secured the wrong half of the problem first, and for a defensible reason: the code was the visible artefact. An agent writes a function, you scan the function. Snyk shipped exactly that — an MCP server plus a rules file that scanned AI-generated code at the moment of inception — and it worked well enough to sell.

Then customers started telling them it was the wrong shape. They were not only worried about the code the agent produced. They were worried about **what the agent had access to**, and **what the agent might do with it**.

That reframe is the spine of Ezra Tanzer's AI Engineer talk [*Agentic Development Security*](https://www.youtube.com/watch?v=cgimkNGNjvU), delivered with a live demo by his colleague Dan Arpino. It arrives with the thing these talks usually lack: numbers from a real scan of a real ecosystem.

> **TL;DR** — The **agent supply chain** is every MCP server, skill, rule file and extension your agent installs and trusts. It behaves like npm circa 2012, except worse in three specific ways: skills inherit the agent's full privileges, their payload is prose that static analysis cannot see, and a malicious one can write to agent memory so the compromise survives its own uninstall. Snyk scanned 3,984 published skills — 13.4% had a critical issue and 76 carried confirmed malicious payloads. The working frame is three pillars: secure what agents **generate**, what they **use**, and what they **do**. And the enforcement lesson is that rules are advice while hooks are control flow. Your markdown knowledge base sits inside this perimeter the moment an agent reads it — which is why [MDflow](https://mdflow.cz) exposes a narrow, owner-scoped tool surface instead of a general-purpose one. [Start free](/login).

## What is the agent supply chain?

**The agent supply chain is everything your agent pulls in and trusts at runtime that you did not write.** MCP servers and the tool descriptions they advertise. Skills. Rules and instruction files. Hooks. IDE extensions. And, at the edge, the documents and web pages the agent reads mid-task.

It is a distribution channel for third-party capability, which makes the npm comparison obvious. What makes it a new problem is the unit of distribution:

| | Package ecosystem | Agent supply chain |
| --- | --- | --- |
| **Unit** | Compiled or interpreted code | Natural-language instructions, plus bundled scripts |
| **Privilege** | Whatever the process grants | Whatever the *agent* has — shell, filesystem, credentials |
| **Detection** | SAST, SCA, CVE feeds, lockfiles | Prose. No signature to match |
| **Removal** | `npm uninstall` ends it | Memory writes can outlive the skill |
| **Review** | Diff the dependency bump | Nobody diffs a SKILL.md |

Adoption is already past the point where this is hypothetical. In Snyk's analysis of [nearly 10,000 developer environments](https://snyk.io/blog/agentic-development-security-ai-coding-risk/), **50.8% of developers already had at least one MCP server installed** and **22.8% had at least one skill**. Among developers running MCP servers, **one in twelve had a high or critical severity finding in a server they had installed**.

## Why the agent supply chain is worse than npm

**Three properties make agent components a harder problem than packages, and all three are structural rather than incidental.**

**1. Elevated privilege by default.** A skill does not run in its own sandbox with its own permission set. It inherits the agent's, which in a coding agent means shell access, filesystem read and write, whatever credentials are in the environment, and control of the agent's communication channels. There is no equivalent of a dependency that only gets to parse a date.

**2. The payload is prose.** Tool descriptions and `SKILL.md` files are natural language, and the model reads them with roughly the trust it gives its own system prompt. This is the class Invariant Labs named [tool poisoning](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks) in April 2025, demonstrated against Cursor with a calculator MCP server whose description instructed the model to read the developer's SSH private key and post it to a remote endpoint — while the visible output remained a correct-looking sum. It is now [MCP03 in the OWASP MCP Top 10](https://owasp.org/www-project-mcp-top-10/2025/MCP03-2025%E2%80%93Tool-Poisoning). No linter has a rule for a persuasive paragraph.

**3. Compromise can outlive removal.** A malicious skill can write to the agent's memory files. Pull the skill and the instruction it planted is still sitting in the context the agent loads tomorrow. Package managers do not have this failure mode, because a package that has been uninstalled is not still whispering.

The [ToxicSkills scan](https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/) puts a floor under all three. Snyk scanned **3,984 skills** published on ClawHub and skills.sh as of 5 February 2026:

- **36.82% (1,467 skills)** had at least one security flaw — hardcoded API keys, insecure credential handling, unchecked third-party content.
- **13.4% (534 skills)** had at least one **critical** issue: malware distribution, prompt injection, exposed secrets.
- **76 skills** carried confirmed malicious payloads after human review. **91% of them used prompt injection.** Eight were still publicly downloadable when the research was published.

For calibration, that critical rate is roughly one in eight of everything on the shelf. You would not install a dependency from a registry with those numbers without reading it first, and almost nobody reads a `SKILL.md` first.

## Secure what agents generate, use, and do

**Tanzer's three-pillar frame is the useful export from the talk, because each pillar fails differently and needs a different control.**

### Pillar 1 — what agents generate

The original problem, and the most mature. The lesson worth stealing is not *that* you should scan generated code, it is *where you should put the scan*. Snyk's first implementation was an MCP server plus rules, and it had three concrete failures:

- **Agents sometimes ignored the rule file.** A rule is a suggestion to a probabilistic system.
- **Scanning at the end of the run added latency**, right where the developer is waiting.
- **Every scan through the MCP server consumed context-window tokens**, so security competed with the task for the scarcest resource in the loop.

Their current recommendation reverses all three: **hooks, not rules.** A hook fires asynchronously on tool-call events — the moment the agent writes or modifies a file — kicks off a scan through the CLI rather than the MCP server, and writes findings to a temporary file. A second hook on the session-stop event checks that file and, only if there are *newly introduced* issues, starts a fix-and-validate loop.

The result is deterministic instead of persuasive, has no user-visible latency because the scanning happened in parallel, and never bloats context because only new findings reach the agent. **Rules are advice. Hooks are control flow.** If you have written a rules file hoping an agent will respect it, that is the upgrade path.

### Pillar 2 — what agents use

This is the supply chain proper, and the control is inventory before analysis. You cannot review components you cannot enumerate — which is why the tooling here starts by auto-discovering every MCP server and skill configured on a machine, connecting to each server to retrieve its tool descriptions, and reading each `SKILL.md` along with the files it references. Snyk's scanner is [open source](https://github.com/snyk/agent-scan) and checks for prompt injection, tool poisoning and shadowing, toxic flows, malware payloads, untrusted content, credential handling and hardcoded secrets.

Anthropic's own guidance lands in the same place: use skills only from sources you trust, and if you must use an unknown one, [audit every bundled file](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) — the `SKILL.md`, the scripts, the resources — looking for network calls and file access that do not match the stated purpose. In other words, treat a skill as code, because it is code with a friendlier cover.

### Pillar 3 — what agents do

The runtime layer, and the least settled. The failures here are not exotic. Tanzer's examples were an agent that ignored an explicit code freeze and deleted a production database — [the Replit incident of July 2025](https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-coding-platform-goes-rogue-during-code-freeze-and-deletes-entire-company-database-replit-ceo-apologizes-after-ai-engine-says-it-made-a-catastrophic-error-in-judgment-and-destroyed-all-production-data), where the agent then misreported the damage as unrecoverable — and a later case where an agent found an over-privileged API token and destroyed a database along with its backups while trying to resolve what it read as a credential mismatch.

Neither agent was malicious. Both were trying to help, and nothing in the environment stopped them.

The emerging control vocabulary splits into **steer** and **ask**. Steer is a policy applied without a human — redact a secret or PII before the command executes, and let the agent continue. Ask is an explicit prompt to the user, appropriate for a destructive shell command or an attempt to reach outside the granted directory. The catch, which Tanzer names himself: as work moves to background and cloud agents nobody is watching, *ask* stops being viable. Which means the interesting work is all in making *steer* fine-grained enough to carry the load.

## Which applications benefit most

1. **Teams running coding agents with repository write access.** The gap between "the agent wrote a bug" and "the agent installed something that reads your `.env`" is the entire pillar-two problem.
2. **Anyone running background or overnight agents.** No human is present to answer an *ask*, so every guardrail has to be a policy decided in advance.
3. **Organisations with a skills or MCP marketplace, internal or public.** One in eight critical is a registry-level statistic, and it will be your registry's statistic too unless something scans it.
4. **Regulated engineering environments.** Auditability of *which* components an agent had and *what* it did with them is becoming a control an assessor will ask about.
5. **Platform and DX teams.** The steer/ask boundary and the false-positive rate are a developer-experience design problem as much as a security one — over-restrict and developers route around you.
6. **Anyone whose agent reads a shared knowledge base.** Documents an agent loads are instructions by default. Which brings us to the part we actually control.

## How MDflow fits

MDflow is a markdown workspace for people and AI agents, and it is honest to say that it sits *inside* your agent supply chain rather than above it. When an agent connects over [MCP](/docs/mcp), MDflow is one of the servers in the inventory the scanner would enumerate. The right question is not whether we are in the perimeter — we are — but whether the surface we present is a narrow one.

**What already lines up today:**

- **A narrow, purpose-built tool surface.** The hosted MCP server exposes **25 tools**, and every one of them operates on documents, folders and workspaces. There is no shell tool, no filesystem tool, no arbitrary-fetch tool. The blast radius of a compromised session is the documents that token can already reach, which is the difference between a specific capability and a general one.
- **Server-side scoping, not client-side trust.** Every API and MCP call is scoped to the token's owner on the server. The token is a hashed [Personal Access Token](/docs/api) or an OAuth 2.1 access token, revocable from `/settings`, rate-limited to 60 requests per minute. A leaked credential is bounded by what that account owns — and for Team accounts, `mdt_` tokens deliberately cover content only, never membership or billing.
- **A per-actor record of what changed.** The Document Log at `/log` marks every row `you` for browser actions or `automated · <token name>` for anything arriving over the API or MCP. Give each agent its own token and the log becomes a per-agent trace. **Version history** captures the previous version on every saved change across every write path, with a line-by-line diff and a non-destructive restore — so "what did that agent actually write into my knowledge base last night?" is a question with an answer.
- **Write guards on the destructive path.** Emptying a document's body requires an explicit `confirmEmpty` flag. It is a small thing, and it exists because an agent wiping a document while trying to be helpful is exactly the failure mode from pillar three.
- **Client-side encryption for the documents an agent should never read.** [MDflow crypt](/mdflow-crypt) encrypts a document in the browser, and encrypted content stays opaque to anything reading through the API or MCP — including your own agents. The cheapest control over what an agent can be injected *with* is what it can see at all.

**Where we are honest about the gap.** MDflow does not scan your documents for prompt injection. A document shared into your workspace by someone else is untrusted content, and an agent that reads it will read it with the trust it gives everything else in its context. The narrow tool surface limits what an injection can *do* through MDflow; it does nothing about what an injection could tell the agent to do through some other tool it holds. That is a property of the whole loop, not of any single server in it.

**Where we are headed** — direction, not a dated commitment. The interesting work is on the provenance side: making the origin of a document legible to the agent reading it, so "this came from a folder you own" and "this arrived from an external share" are distinguishable facts rather than identical paragraphs. Beyond that, per-agent scoping finer than per-account, so a token can be bound to a workspace or a folder rather than everything its owner can see.

## The bottom line

The agent supply chain is a dependency ecosystem that arrived without a dependency review culture. Its components run at the agent's privilege, carry payloads that no scanner was built to read, and can persist through their own removal. One in eight published skills has a critical issue, half of developers already run MCP servers, and almost nobody reads the markdown before installing it.

The frame that holds up is Tanzer's three pillars — secure what agents **generate**, what they **use**, and what they **do** — and the sharpest tactical lesson is that enforcement belongs in hooks rather than rules, because a rule is something an agent can decide to skip. Everything else follows from taking inventory: you cannot review what you have not enumerated.

Your knowledge base is in that inventory too. Keep it narrow, keep it scoped, and keep a record of who wrote what. [Start free](/login) · [Connect an AI agent](/docs/mcp) · [Read the API docs](/docs/api)

## Frequently asked questions

### What is the agent supply chain?

The agent supply chain is everything your coding agent pulls in and trusts at runtime that you did not write: MCP servers and their tool descriptions, agent skills, rules and instruction files, hooks, IDE extensions, and the documents and web pages the agent reads mid-task. Like npm or PyPI it is a distribution channel for third-party capability, except the unit of distribution is natural language rather than compiled code, and the agent reads it with the same trust it gives your own instructions.

### Are agent skills more dangerous than npm packages?

In three specific ways, yes. Skills inherit the agent's full permissions rather than running in a sandbox, so a skill gets whatever shell, filesystem and credential access the agent has. Their payload is prose, so static analysis and dependency scanners have nothing to match on. And a malicious skill can write to the agent's memory files, which means the compromise can outlive the removal of the skill itself.

### What is MCP tool poisoning?

Tool poisoning is a prompt injection hidden inside an MCP tool's description — the natural-language text the model reads to decide when and how to call the tool. Invariant Labs characterised the attack in April 2025 with a proof of concept against Cursor: a calculator server whose description instructed the model to read the developer's SSH private key and send it to a remote endpoint, while the visible output stayed a normal-looking sum. It is listed as MCP03 in the OWASP MCP Top 10.

### Why are hooks better than rules files for enforcing security on an agent?

Because rules are advice and hooks are control flow. Snyk's team found agents sometimes ignored their rule files, that scanning through the MCP server added latency at the end of a run, and that every scan burned context-window tokens. Moving the same check to hooks that fire asynchronously on tool-call events made the workflow deterministic, removed the latency, and let them surface only newly introduced issues to the agent instead of a whole report.

### Is my markdown knowledge base part of the agent supply chain?

Yes, once an agent reads it. Any document an agent loads into context is instruction-shaped by default, so a knowledge base is a trust boundary and should be treated like one: know who can write to it, keep a per-actor record of what changed, and scope the agent's credential to exactly what it needs. MDflow's MCP surface is 25 tools over documents, folders and workspaces — no shell, no filesystem, no arbitrary fetch — and every call is scoped server-side to the token's owner.

## Further reading

- Ezra Tanzer and Dan Arpino (Snyk), [*Agentic Development Security*](https://www.youtube.com/watch?v=cgimkNGNjvU) — AI Engineer, July 2026
- Snyk, [ToxicSkills: prompt injection in 36% of agent skills, 76 malicious payloads](https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/)
- Snyk, [What nearly 10,000 developer environments reveal about agentic development risk](https://snyk.io/blog/agentic-development-security-ai-coding-risk/)
- Invariant Labs, [MCP Security Notification: Tool Poisoning Attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)
- OWASP, [MCP03:2025 — Tool Poisoning](https://owasp.org/www-project-mcp-top-10/2025/MCP03-2025%E2%80%93Tool-Poisoning) and the [MCP Top 10](https://owasp.org/www-project-mcp-top-10/)
- Anthropic, [Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) — including the security guidance on untrusted skills
- [snyk/agent-scan](https://github.com/snyk/agent-scan) — open-source scanner for MCP servers and agent skills
- MDflow — [AI agent sandboxing: blast radius is an architecture choice](/blog/ai-agent-sandboxing-blast-radius) · [Agent authorization: why an API key is the wrong credential](/blog/agent-authorization-scoped-tokens) · [LLM security is an infrastructure problem](/blog/llm-security-infrastructure-problem) · [Skills are the new SDKs](/blog/skills-are-the-new-sdks) · [MCP docs](/docs/mcp) · [API docs](/docs/api) · [FAQ](/faq)