Agent Capabilities and the Tool Supply Chain
An agent's capabilities are everything it can do beyond generating text: the tools it can call, the systems it can reach, the data it can retrieve. Those capabilities arrive through several different mechanisms – MCP servers, skills, plugins, extensions, packages, and SaaS connectors – and the mechanisms are not interchangeable. They differ in where the code executes, what permissions install grants, whether they produce inspectable traffic, and whether they can change after approval. The agent tool supply chain is the set of all those paths, and governing it means governing the paths rather than maintaining a list of approved names.
What counts as an agent capability?
A useful working definition: anything that extends what an agent can do past producing output. If a mechanism lets an agent read a file, query a database, call an API, browse a page, or execute code, it’s a capability, regardless of what the platform calls it.
The reason to use one collective noun is that platforms don’t agree on vocabulary. What one vendor calls a plugin, another calls an extension, a third calls a connector, and a fourth exposes the same functionality as a tool behind an MCP server. Governing by product vocabulary produces a policy full of gaps, because the next platform will introduce a term nobody wrote a rule for. Governing by what the mechanism does survives the naming churn.
The supply chain framing matters for the same reason it does in software generally: these capabilities are largely authored by someone other than the organization running the agent, distributed through channels with variable scrutiny, and updated after installation. That’s a supply chain, with the familiar supply chain problem of trusting code you didn’t write and can’t fully inspect.
What are the main ways agents gain capabilities?
Six mechanisms cover most of what’s deployed.
MCP servers. A standardized protocol for exposing tools and data to agents. The server is a separate process, often remote, and the agent calls it over a defined interface. Capabilities are discoverable at connection time, and because calls cross a network boundary they can be inspected by an MCP gateway.
Skills. Capability definitions that live inside the agent’s own configuration – instructions, and often scripts, that the agent loads as part of its context. Because a skill can be defined and executed without calling out to a separate server, it may generate no outbound traffic for a boundary control to see. This is the single biggest divergence in the list and the reason the MCP-versus-skills distinction is more than terminology. The public marketplace dimension is not hypothetical: one organization reported real damage from publicly distributed skills, describing marketplace entries that pointed users toward malicious content, and attributed it to teams not knowing how to evaluate or secure a skill before adopting it.
Plugins and extensions. Platform-specific packages that add functionality to a harness or a host application. Permissions are typically granted at install, sometimes broadly, and the granting event is often a single click by whoever set the agent up.
SaaS connectors. Pre-built integrations to business applications, usually authorized through OAuth. The distinctive risk is scope: connectors frequently request broader access than the task requires, and the granted scope persists long after the original use case ends.
Packages and dependencies. For agents built in code, the ordinary software supply chain applies – libraries the agent imports, with their own transitive dependencies. This is the most mature supply chain problem on the list and the one most likely to already have tooling pointed at it.
Sub-agents. An agent that can invoke another agent has effectively acquired that agent’s entire capability set. This is the least-tracked mechanism of the six, because it doesn’t look like installing a tool.
What makes each mechanism behave differently?
Four properties do most of the work in explaining why one governance approach doesn’t cover all six. These are the questions worth asking about any new capability type, including ones that don’t exist yet.
Where does the code execute? In the agent’s own process, in a sandbox, or on a remote server somebody else operates. This determines blast radius and who is positioned to observe a failure.
What does installation grant? Some mechanisms grant narrow, per-call permissions. Others grant broad standing access at install time, in a single approval event that nobody revisits.
Does it produce inspectable traffic? If invoking the capability crosses a network boundary, a proxy can see it. If it resolves entirely inside the agent’s configuration and context, there is nothing at the boundary to inspect. This is where gateway-based coverage divides cleanly into covered and uncovered.
Can it change after approval? A remote server can alter the tools it advertises after you approved it. A package can publish a new version. A skill file can be edited in a repository. Review at install time answers a question about a thing that no longer necessarily exists.
That last property is the one that undermines allow-listing as a complete strategy. An allow-list records a decision made at a moment about an artifact that can change afterward, which means the list stays green while the underlying thing drifts.
It also changes how quickly the agent itself changes. Add an MCP server on a Wednesday and by Thursday morning the agent is a materially different system from the one that was assessed – same configuration, same instructions, different reach. Security teams working on this have started asking for revalidation on a daily or even hourly cycle rather than at approval, specifically to catch tools that were benign when cleared and are not benign now. The useful way to hold the whole category: an agent is only as capable as what it can access, which means it is also only as risky as what it can access. Those are the same sentence.
Why isn’t allow-listing enough?
Allow and deny listing is a reasonable baseline and a poor ceiling, for three reasons that compound.
Names are not behavior. Capabilities are approved by identifier – a server name, a package, a skill title. None of those describe what the thing does when the agent uses it. A capability can look entirely legitimate at review and behave differently in use, which is why the practical failure mode isn’t an obviously malicious tool getting approved but a plausible-looking one doing something unexpected once an agent starts calling it.
Approval is a point in time, use is continuous. The gap between when something is reviewed and when it executes is where trust-boundary failures live. Two documented vulnerabilities in a widely used coding agent turned on exactly this: repository-defined configuration that could execute shell commands at tool initialization before consent was enforced, and traffic redirection that occurred before a trust prompt was shown. Both were patched. The pattern generalizes beyond those specific bugs.
Lists don’t cover what you haven’t enumerated. A list governs the mechanisms someone thought to put on it. The tool types that generate no traffic, and the sub-agent relationships nobody logged as a capability, are absent from the list and therefore absent from the policy.
The alternative isn’t abandoning allow-lists – it’s treating them as one input to a continuous picture of which agents hold which capabilities, what permissions those carry, and what the agent actually does with them. That’s a mapping exercise rather than a list, and it belongs alongside posture management rather than in a separate approvals workflow.
How do you actually map an agent’s tool supply chain?
Three questions, in order. Most organizations can answer the first and stall on the second.
- Which capabilities does each agent currently hold? Not which were approved – which are configured right now, across all six mechanisms above. If assembling this requires asking teams, treat the result as a floor.
- What permissions does each capability carry? The scope granted, not the scope required. OAuth connectors are usually where the two diverge most.
- Which of those capabilities does the agent actually use? Held-but-dormant and actively-exercised are different risk profiles, and no configuration review distinguishes them.
The evidence that steps one and two are harder than they look: a British bank had already run employee surveys and deployed MCP gateways across its developer population. A subsequent assessment still surfaced significantly more tool connections than both of those efforts combined had captured, concentrated in the tool types neither mechanism was positioned to see.
Common questions
What is tool poisoning?
Tool poisoning is manipulating a capability's definition so that an agent is influenced by content its operator never reviewed – for example, embedding instructions in a tool's description or metadata, which the agent reads as part of deciding whether and how to use it. The reason it works is structural: an agent must ingest a tool's description to use the tool, and that description is authored by whoever published it. Mitigation generally involves treating tool metadata as untrusted input rather than configuration, and re-checking definitions rather than trusting them once at install.
Are skills more dangerous than MCP servers?
Neither is inherently more dangerous, and framing it as a ranking usually obscures the useful point. They fail differently. MCP servers run remote code you don't control but produce inspectable traffic. Skills execute in the agent's own context and may produce no traffic to inspect, but are typically visible in configuration if something is reading it. The right question is which of the two your current tooling can see, and the answer for most gateway-based setups is one of them.
Does an SBOM cover agent capabilities?
Partially. A software bill of materials covers packages and dependencies well, because that's what it was designed for. It doesn't cover MCP server connections, skills, SaaS connector scopes, or sub-agent relationships, none of which are packages. An SBOM is a good input and not a substitute for a capability map. The broader supply chain analogy is worth borrowing – provenance, continuous revalidation, transitive dependencies all transfer cleanly – but it breaks in one specific place worth naming. A software dependency executes code you didn't write. A tool does that and reads your data and sends it somewhere. The confidentiality dimension has no real equivalent in the package supply chain, which is why controls inherited from that discipline tend to cover integrity well and exposure poorly.
Can you allow a tool but restrict what it does?
This is a live gap rather than a solved problem, and it comes up regularly from teams already running approved servers. A single MCP server frequently exposes both read and write capability, and the natural request is to permit the server while blocking the write path – allow the agent to query, not to modify. Most current tooling approves or denies at the server level, which forces an all-or-nothing decision on something that is not all-or-nothing in practice. Where per-tool granularity isn't available, the practical workarounds are separate scoped credentials per use case, or enforcing the restriction at the agent's own [execution path](https://www.geordie.ai/knowledge-center/agent-lifecycle-hooks/) rather than at the tool boundary.
Which tool controls can safely be automated?
There's a useful pattern in where teams accept automated blocking and where they refuse it, and it isn't severity. The same people who reject automated enforcement on cost anomalies – on the grounds that stopping an agent mid-task is disruptive and the spend might have been justified – will volunteer automatic blocking for known-malicious or known-vulnerable servers before anyone proposes it. The dividing line is whether a human could plausibly have had a good reason. A cost spike usually has one, so blocking it second-guesses the user. A known-malicious MCP server has none, so blocking it protects them. That test predicts appetite for automation more reliably than impact scoring does, and it's a reasonable default when deciding which agent policies ship in enforce mode and which start in monitor.
Who should own agent tool supply chain risk?
In practice it lands between application security, who own the package supply chain already, and whoever owns AI governance. The failure mode is assuming the existing supply chain function covers it, because most of the mechanisms above aren't packages and don't appear in the tooling that function uses. The practical move is naming an owner for the four non-package mechanisms explicitly rather than assuming they're inherited.
