Agent Supply Chain Security in 5 Steps [2026]

Your agent’s attack surface includes every skill it loads, every API it calls, every model it queries, and every data source it reads. You built one of those. Someone else built the rest.

Agent supply chains combine code dependencies, identity management, and runtime behavior into a single attack surface that most teams handle in fragments. This five-step checklist covers the full chain: inventory, verify provenance, pin versions, monitor runtime, and plan for compromise.

Attacks on upstream dependencies have traditionally focused on a single point of failure. SolarWinds in 2020: attackers compromised one piece of software that 18,000 organizations trusted. One backdoor. Cascading damage. But agent supply chains are different. They’re wider. They move faster. And they’re harder to audit because the behavior you see at test time might not be the behavior you see at runtime.

Last week, researchers discovered 820 malicious skills in a public agent marketplace. They weren’t sophisticated. They didn’t hide. But they were there, waiting for the first agent that tried to load them.

Here’s your five-step checklist to lock down your agent’s supply chain before one of those skills lands in your production environment.

1. Do You Actually Know Everything Your Agent Depends On?

Start here. List every external dependency. Every skill. Every API. Every model. Every data source. Every library.

Don’t skip anything because it seems obvious or small. The skill that runs once a month. The library that handles JSON parsing. The third-party model you call for image classification. Write them down. All of them.

Create a spreadsheet. A config file. A database table. Whatever you need. But get them into one place where you can see the full scope.

This inventory is your baseline. You can’t secure what you can’t see.

2. Can You Verify Who Actually Wrote These Dependencies?

Once you have your list, start asking: Who made this? Are they who they claim to be? Can I inspect the source?

This is provenance verification. It matters because the skill that looks official might be a typosquatting attack. The API endpoint that claims to be from a trusted provider might be hosted on an attacker’s infrastructure.

For each dependency, do this:

• Check the publisher’s identity. Is there a verified account? A domain you recognize? A signed certificate?
• Look at code provenance. Is the source code public? Can you read it? Can you verify that what’s published matches what you’re running?
• Check the history. How long has this dependency existed? Who uses it? Are there known vulnerabilities or security issues?

If you can’t answer these questions, that dependency doesn’t belong in your agent.

3. Have You Pinned Versions and Verified Checksums?

Dependencies change. Usually for good reasons. Sometimes because an attacker got access and pushed a malicious update.

Lock down your dependencies.

Pin every version. Don’t use “latest” or floating version ranges. Specify exact versions. Then verify checksums or signatures to ensure you’re getting what you asked for, not a silent substitution.

This prevents a common attack pattern: an attacker compromises a dependency, pushes a malicious update, and your agent automatically pulls the new version without your knowledge.

Version pinning catches that. It forces a human decision before an update happens.

4. What Are Your Dependencies Actually Doing at Runtime?

You’ve inventoried. You’ve verified. You’ve locked versions. Now watch what happens when your agent actually runs.

Monitor runtime behavior. What API calls are being made? What data is being transmitted? What resources are being accessed? Does the dependency’s actual behavior match its claimed behavior?

This is where hidden compromises show themselves. A skill that looks legitimate in code review might exfiltrate data or make unauthorized API calls when it runs.

Set up observability. Log dependency calls. Alert on unexpected behavior. Compare runtime activity against a baseline of normal operation.

If a dependency starts making calls to an unfamiliar IP address or exfiltrating sensitive data, you want to know immediately.

5. What’s Your Incident Response Plan If a Dependency Gets Compromised?

Hope for the best. Plan for the worst.

Assume any dependency could be compromised. Not if. When. Build your response plan now, before you need it.

Your plan should include:

• Revocation: How quickly can you disable the compromised dependency? What’s your workflow? Who has approval authority?
• Replacement: Do you have a backup dependency? Can you swap it in without redeploying your entire agent?
• Restoration: If data was exfiltrated or modified, what’s your recovery procedure? How do you audit what happened?

Write this down. Test it. Run a drill. Make sure everyone knows their role when it’s 3 AM and an alert fires.

The Milk Expiration Date Principle

You check the expiration date on milk but not on the contractor badge that gets someone into your office.

Agent supply chain hygiene is about applying the same scrutiny to every dependency, not just the obvious ones.

You wouldn’t blindly install software from an untrusted source on your computer. Don’t blindly load skills into your agent. You wouldn’t run code without reading it. Don’t integrate APIs without knowing what they do. You wouldn’t disable monitoring on a production system. Don’t run agents without observability.

The same principles apply. The same discipline works. The difference is that agent dependencies move faster and affect more systems, so the stakes are higher.

Start With Step 1 Today

Don’t wait for a security incident to build your supply chain hygiene. Start right now.

Create an inventory of every external dependency your agents use. Print it. Paste it into a doc. Stick it on a wall. Make it real.

Once you can see what you depend on, everything else becomes possible.

Tomorrow: we zoom out from the technical and ask a bigger question. Humans trust invisible infrastructure every single day. From plumbing to power grids to AI agents. What happens when that invisible trust breaks?