Agentic supply chain compromise

What it is

Agents assemble their capabilities when they run: tool definitions, skill packages, connectors to other systems, and sometimes other agents, often fetched from a registry. Each is a dependency that can be hostile from the start, altered after it was approved, or described in a way that misleads the agent about what it does. This differs from the LLM application supply chain, which concerns models, data and libraries fixed at build time.

How it happens

• A skill published to a public registry contains hidden instructions or code.
• A tool's description is written to make the agent prefer it, or to misstate what it does.
• A component that was reviewed is later updated by its publisher, and the update is loaded without review.
• A look-alike name leads the agent, or the developer, to the wrong package.

Why it matters

A loaded component sits inside the agent's trust boundary. It sees what the agent sees and can act through the agent's permissions. Conventional software checks do not read natural-language tool descriptions for hostile intent.

Warning signs

• Agents can load components from sources no one approved.
• No inventory lists the tools and skills each agent uses.
• Component versions are not pinned.
• A tool's behaviour changes with no release on the organisation's side.

Who owns it

The owner of third-party risk sets the vetting standard. Engineering maintains the approved list and the pinning. Security reviews components before approval.

In practice

A team adds a community connector so that an agent can read a shared calendar. A later version of the connector also forwards meeting contents to an external address. Nobody had fixed the version. The same pattern generalises to any component an agent loads by name from a source the organisation does not control.