Securing the Agent Supply Chain

A developer installs a skill to make their coding agent less chatty. It works. It also, the first time the agent uses it, reads the AWS credentials on that laptop and sends them to a domain no one recognizes. No one wrote obviously malicious code and no one approved a change. A file landed in a folder, the agent loaded it on the next run, and production credentials were gone.

Your Agents Have a Supply Chain Now

That skill is one link in a supply chain most security teams have never inventoried. To do real work, an agent reaches for far more than the model. It loads skills that change how it behaves, connects to MCP servers that hand it new tools, reads websites that can carry instructions as easily as information, and clones repositories full of code it will run. Every one of those is authored by someone else, and every one of them executes with the agent's privileges, the developer's credentials, and whatever production access the agent was given.

That is a supply chain. It behaves like the software supply chain we have spent a decade learning to secure, except it is assembled at runtime, from whatever the agent reaches for in the moment, with no manifest, no lockfile, and no build step where anything gets checked. The dependency that mattered was never declared. It just showed up and ran.

Every Control We Have Assumes Something That Is No Longer True

Reach for the tools you already own and they miss it, each for a specific reason.

Scanning assumes a build step. This skill was never committed or reviewed; it was dropped into a folder and picked up on the next run, so there was no pipeline to catch it and no diff to approve. Detection assumes you can recognize the threat. But the skill is new and one-off, unknown to any threat feed, and its code reads perfectly clean, because it does nothing wrong until the agent actually uses it. The credential theft is a behavior, not a signature. Triage assumes severity is obvious. The same skill is a five-minute cleanup on one laptop and a breach across a dozen coding agents, and nothing in the finding tells you which situation you are in. Without knowing where a dependency runs and how often, every alert looks identical.

Response assumes someone can see the whole event. Instead your endpoint tool sees a process, your identity provider sees a user, your gateway sees a tool call, and the malicious skill lives in the seams between them, connected to none of them.

What It Takes To Actually Secure It

So securing the agent supply chain takes more than adding another scanner to the pile.

You have to discover what your agents actually pull in, built from what they run rather than a list someone is supposed to maintain, because the whole problem is that nobody declared these dependencies in the first place.

You have to judge a dependency by how it behaves when it executes, not by how it reads on the page, because the dangerous ones look fine until the moment they run.

You have to know how far a bad one has already spread, so you can tell a contained mistake from an active incident.

You have to be able to act: block a dependency before it runs again, and contain the sessions that already used it, rather than filing a report after the credentials are gone.

And all of it has to stay tied to the agent and the session it ran in, or every finding is just one more disconnected fragment in someone else's console.

How Zenity Secures the Agent Supply Chain

This is the problem Zenity is built for.

It starts with inventory. Zenity discovers every agent and decomposes it into the skills, MCP servers, websites, and repositories it actually uses, assembled from runtime rather than a declaration, and it counts how many machines installed each one and how often agents ran it. That usage is what separates a single-laptop cleanup from a fleet-wide incident before you spend a minute triaging.

Then it gives each dependency a verdict you can trust, by looking at it two ways. A static scan reads the artifact for the obvious tells: obfuscated instructions, an unsigned package pulled from somewhere it should not be. The Detonation Chamber goes further and runs the dependency in isolation, driving it until it acts and watching what it does at install and, separately, when the agent puts it to work. That second view is what catches the concise-coding skill, because the credential theft only happens at use time and no static read would ever surface it.

From there a verdict becomes an action, because Zenity keeps everything attached to the agent and the session. A dangerous dependency is blocked by a Boundary before any agent can invoke it again. A session that already used it is contained while it is still running. Exposure shows the risky dependencies sitting across your estate before an agent loads one, and the runtime session view resolves what the endpoint, the gateway, and the identity provider each saw into a single account of what happened. One malicious skill connects back to the machines that installed it, the identity behind it, and the control that shuts it down.

That is the difference between seeing your agent supply chain and actually securing it.