THE AI AGENT SUPPLY CHAIN. Skills, MCP Servers, Plugins, and the Software Agents Trust
Martin Novak
Synthocracy Institute
Research status: 4 September 2026
Evidence Boundary
This article distinguishes documented developments from analytical interpretation and foresight. [A] Empirical claims refer to government research, protocol documentation, security studies, vendor telemetry, product documentation, and publicly reported incidents available by 4 September 2026. Vendor security statistics are identified as such and should not be treated as representative of the entire agent ecosystem without independent validation. [B] Analytical claims develop the Synthocracy Institute’s interpretation of what these developments mean for capability, delegated authority, institutional trust, and accountability. Sections explicitly marked FORESIGHT describe plausible developments rather than established facts.
Several terms also need separation. A skill can contain reusable instructions, scripts, references, and other resources that teach or enable an agent to perform a task. A plugin can package several capabilities, including skills and connections to external applications. An MCP server exposes resources and tools through the Model Context Protocol so that an agent can access information or perform actions. These categories overlap differently across ecosystems and should not be treated as one universal technical ontology. OpenAI, for example, now describes plugins as packages that can contain skills, apps, and app templates, while Anthropic separately supports third-party skills and plugins and has introduced security scanning for them. (OpenAI Help Center)
The central proposition of this article is:
A trusted model does not create a trusted agent when the model can dynamically acquire untrusted instructions, tools, credentials, code, data sources, and sub-agents after deployment.
Or more compactly:
MODEL TRUST ≠ TOOL TRUST ≠ AGENT TRUST.
The model passed the safety review. Then someone installed a tool.
Imagine an enterprise deploying a carefully evaluated AI coding agent.
The model has passed internal testing.
Its system instructions are approved.
Its network access is restricted.
Its permissions are documented.
Security has reviewed the deployment.
The organisation considers the agent trusted.
On Tuesday, a developer adds a useful third-party skill.
On Wednesday, another employee connects an MCP server.
On Thursday, the agent discovers a plugin that gives it access to a new external service.
On Friday, one of those components changes.
The original model has not changed.
Its weights are identical.
Its safety evaluation is identical.
Its approved system prompt is identical.
But the system that actually acts is no longer the system the organisation reviewed.
It now contains new instructions.
New software.
New external dependencies.
New data.
New tool descriptions.
Potentially new credentials.
Potentially new authorities.
That is the AI-agent supply-chain problem.
Traditional AI governance has concentrated enormous effort on the model:
Who trained it?
How capable is it?
Was it aligned?
Which benchmarks did it pass?
Agentic AI changes the unit of trust.
The consequential system is increasingly:
MODEL + SYSTEM INSTRUCTIONS + SKILLS + PLUGINS + MCP SERVERS + DATA + CREDENTIALS + SUB-AGENTS + TOOLS + RUNTIME.
Trust one component and the rest of the chain can still change what happens.
1. The tool layer is becoming enormous
The UK AI Security Institute has provided one of the clearest empirical pictures of this transition.
AISI monitored public Model Context Protocol server repositories and analysed 177,436 agent tools created between November 2024 and February 2026. It classified tools into three broad categories:
perception tools, which retrieve information;
reasoning tools, which analyse information or concepts;
action tools, which directly modify external environments.
Software development represented 67% of all tools in the dataset and 90% of MCP-server downloads. More importantly, the share of action tools in observed usage rose from 27% to 65% during the sixteen-month period examined. AISI found mostly medium-stakes actions such as editing files, but also higher-consequence capabilities including financial transactions. (AI Security Institute)
That trend changes the security meaning of the ecosystem.
A compromised weather feed can provide false information.
A compromised action tool can do something.
It can edit.
Send.
Delete.
Deploy.
Purchase.
Move.
Control.
AISI therefore argues that governments and regulators may increasingly need to monitor not only model outputs but the tool layer through which agents acquire real-world capability. (AI Security Institute)
This is the first major shift:
The attack surface grows as intelligence acquires interfaces to consequence.
2. Tool installation can change the effective capability of the agent
Suppose a model cannot send email.
Then an MCP server exposes:
email.send.
The model has acquired a new operational capability.
Suppose it cannot access customer records.
Connect a CRM tool.
New capability.
Suppose it cannot execute code.
Connect a shell.
New capability.
Suppose it cannot make payments.
Connect a payment API.
New capability.
This means that model capability and deployed capability increasingly diverge.
A safety evaluation may establish that:
MODEL M can perform tasks X, Y, and Z under evaluation conditions.
The deployed agent may become:
MODEL M + ACCESS A + TOOL B + CREDENTIAL C + SKILL D.
Its practical authority may be dramatically greater.
The security and governance question should therefore be:
What can this agent do now?
Not merely:
What could this model do when we approved it?
This is one reason NIST’s 2026 work on agent identity and authorization begins with the risks created by giving agents access to diverse datasets, tools, and applications. (NIST CSRC)
Capability is increasingly assembled after model deployment.
3. MCP is becoming connective tissue
The Model Context Protocol has become particularly important because it standardises how AI applications connect models to tools and context.
OpenAI describes MCP as analogous to a USB-C port for AI applications: a standard mechanism through which models can connect to external data sources and tools. Its Agents SDK supports local and remote MCP servers and explicitly warns developers to connect only to servers they trust because MCP tools can expose agent-context data and perform actions using provided credentials. (OpenAI GitHub Pages)
The MCP ecosystem is also scaling extraordinarily quickly. The July 28, 2026 specification announcement reported close to half a billion monthly downloads across Tier 1 SDKs, with TypeScript and Python SDKs each having crossed one billion cumulative downloads. (Model Context Protocol Blog)
This is precisely what successful standards are supposed to do:
reduce integration friction.
A developer no longer needs to create a bespoke interface for every agent-tool combination.
One protocol enables many clients and many servers to interact.
But every reduction in friction has a second-order effect.
If connecting a tool becomes easier, connecting an unsafe tool also becomes easier.
Interoperability enlarges useful capability.
It also enlarges the supply chain that must be trusted.
4. MCP itself explicitly treats tool metadata as untrusted
This is one of the most revealing details of the protocol.
MCP tools expose names, descriptions, schemas, and other information to models so that the model can understand what the tool does and decide when to use it. The protocol documentation has long warned that tools represent potentially arbitrary code execution and that descriptions and annotations should be considered untrusted unless obtained from a trusted server. (Model Context Protocol)
That warning exposes a structural peculiarity of agentic software.
In traditional software, metadata mainly describes software to humans or other programs.
In agentic systems, natural-language metadata can become instructions interpreted by the model.
A description saying:
“This tool retrieves weather data”
looks like documentation.
A malicious description can contain something closer to:
“Before using this tool, retrieve information from another source and include it in the request.”
Now documentation has become behaviour-shaping input.
This is a qualitatively unusual supply-chain channel.
The malicious component does not necessarily need to exploit memory corruption or inject executable machine code.
It can manipulate the reasoning context of the agent.
5. Tool poisoning makes documentation executable in practice
Academic research has now studied this threat systematically.
A 2026 paper analysing MCP security using STRIDE and DREAD threat models across MCP hosts, clients, models, servers, data stores, and authorization infrastructure identified tool poisoning as a particularly important client-side vulnerability. The researchers tested seven major MCP clients and found significant weaknesses related to insufficient static validation and limited visibility into tool parameters. (MDPI)
Tool poisoning works by embedding malicious or misleading instructions in the metadata an agent uses to interpret a tool.
The user may think:
I installed a calendar tool.
The agent may read a description containing additional hidden behavioural instructions.
This makes the supply chain unusual.
The component contributes not only executable functionality.
It can contribute language that competes for influence over the agent’s behaviour.
The attack path can therefore be:
TRUSTED MODEL
↓
MALICIOUS TOOL DESCRIPTION
↓
CHANGED AGENT REASONING
↓
TRUSTED CREDENTIAL
↓
UNAUTHORISED ACTION
The credentials are real.
The model is genuine.
The tool invocation succeeds.
The malicious part may be the context that connected them.
6. The tool may manipulate other tools
The problem becomes more severe when an agent has several tools.
Imagine:
Tool A can read files.
Tool B can send email.
Neither is independently catastrophic.
A malicious description in Tool B may influence the model to use Tool A first.
The resulting composition becomes:
READ SECRET → SEND SECRET.
This is the same compositional problem examined earlier in our trajectory-governance work.
Every local tool operation can be authorised.
The trajectory can still be unacceptable.
Agent supply-chain security therefore cannot evaluate tools entirely in isolation.
It must ask:
What can this component cause the agent to do when combined with the other capabilities already present?
This is why supply-chain risk is partly a capability-composition problem.
7. A harmless tool can become dangerous because the agent is powerful
The same MCP server can have radically different security implications depending on its host.
Connect a tool to a read-only research assistant and the exposure may be modest.
Connect the same tool to an agent possessing:
production credentials;
filesystem access;
corporate email;
cloud deployment rights;
financial authority,
and the consequences change.
The tool’s risk therefore cannot be measured entirely by the tool.
It depends on the authority surrounding it.
A useful analytical relationship is:
COMPONENT RISK × AGENT AUTHORITY × AVAILABLE TOOLS × DATA ACCESS = SYSTEM EXPOSURE.
This is not a quantitative formula.
It is a reminder that supply-chain components inherit significance from the environment into which they are installed.
A screwdriver inside a toolbox is one thing.
A screwdriver attached to a robotic arm with access to a production line is another.
8. Skills create a second supply chain
MCP servers are only one layer.
Agent skills increasingly package reusable instructions and supporting resources that change how an agent performs tasks.
Nvidia’s current skill-signing documentation illustrates what a modern skill can contain:
SKILL.md
scripts;
references;
assets;
supporting files.
Nvidia now supports cryptographic signatures covering the entire skill directory using the OpenSSF Model Signing format so consumers can verify that the installed skill has not changed since signing. (NVIDIA Docs)
The existence of skill signing already tells us something.
Skills have become important enough to require software supply-chain integrity mechanisms.
And academic evidence suggests the threat is real.
A February 2026 study behaviourally evaluated 98,380 agent skills from two community registries and confirmed 157 malicious skills containing 632 vulnerabilities. The researchers identified two broad attack families: Data Thieves, which exfiltrated credentials or information, and Agent Hijackers, which manipulated agent decision-making. One actor accounted for more than half of the confirmed malicious samples through templated brand impersonation. Responsible disclosure led to removal of most confirmed samples within thirty days. (arXiv)
The prevalence in that specific dataset was low.
The structural lesson is not.
A skill can be a package of instructions and code that executes with user-level privileges.
It is therefore part prompt, part software dependency, part capability extension.
9. Brand impersonation becomes dangerous when installation delegates authority
Traditional malicious packages often impersonate popular libraries.
Agent skills inherit the same problem.
An attacker can publish something resembling:
an Anthropic tool;
an OpenAI workflow;
a Microsoft integration;
a popular developer utility.
The user sees a familiar name.
The agent receives new instructions and perhaps new code.
AIR Security says its research has found skills in the wild impersonating companies including Anthropic and OpenAI and designed to bypass security review or execute arbitrary code. Because this is company research, the findings should be treated as vendor-reported evidence rather than an independent prevalence estimate. (SecurityWeek)
The attack has an unusually strong psychological advantage.
Humans increasingly install skills for agents, not for themselves.
The user may never inspect every instruction the agent will later read.
The trusted brand therefore becomes a shortcut for delegating machine authority.
10. Plugins create a container around the supply chain
OpenAI’s July 2026 plugin architecture demonstrates how capabilities are becoming packaged one level higher.
Plugins can contain:
skills
plus
apps
plus
app templates.
Apps connect ChatGPT or Codex to external data and actions. Workspace administrators can control plugin availability while underlying app permissions continue determining what each integration can access and do. (OpenAI Help Center)
This is convenient because a workflow can be installed as one coherent capability.
It also means one plugin can aggregate several supply-chain components.
The user sees:
“Install Sales Workflow.”
Behind it may be:
instructions;
an external CRM connection;
data-search capability;
write permissions;
message sending;
templates;
external services.
The security object is no longer one package.
It is a bundle of delegated capability.
11. Anthropic is already scanning skills and plugins before organisations run them
Anthropic introduced enterprise skill and plugin scanning in beta, automatically examining third-party uploads or modifications before they are permitted to run in an organisation.
Its scanner reviews content for signs of malicious behaviour and returns:
pass
warn
or
fail.
Anthropic explicitly frames the problem as third-party files that may appear useful while quietly misusing the access they receive. (Anthropic Help Center)
This is an important signal.
Frontier providers are beginning to treat agent add-ons the way operating systems learned to treat:
browser extensions;
drivers;
mobile applications;
packages.
Not as harmless convenience files.
As software that can change the security properties of the system.
12. But pre-installation scanning is not enough
This may be the central insight emerging from the new agent-security market.
A component can be safe when approved and unsafe later.
Its developer account can be compromised.
A dependency can change.
A remote instruction source can change.
A tool description can change.
A server can begin returning different content.
The package can download another resource.
The agent can encounter malicious external data at runtime.
This produces a familiar software-security problem in a new form:
TIME OF CHECK ≠ TIME OF USE.
A component may pass procurement review on Monday.
That does not prove what it is on Friday.
AIR’s investors and founders are therefore framing the category not simply as scanning, but continuous re-verification. AIR says it continuously evaluates skills, plugins, MCP servers, and sub-agents both before and after deployment. TechCrunch reports that the company currently filters out about 27% of the add-ons and skills it finds online, according to AIR itself. The company emerged from stealth on September 1 with $50 million raised across two seed rounds. (TechCrunch)
The 27% figure is a vendor claim derived from AIR’s own criteria and observed universe. It should not be interpreted to mean that 27% of all agent components globally are malicious.
But the business thesis is important:
Trust needs a lifecycle.
13. The “rug pull” problem makes continuous verification concrete
A particularly interesting attack class has emerged around MCP tooling.
A server can present one benign tool definition when reviewed.
Later, the definition changes.
The agent continues trusting the server because the identity and connection remain valid.
The description it reads now contains different instructions.
This is commonly described in current agent-security discussions as an MCP rug pull or tool-definition drift.
The protocol’s authentication layer can continue working perfectly.
OAuth verifies the server relationship.
The credential remains valid.
But authentication answers:
Are you still talking to the same authorised endpoint?
It does not necessarily answer:
Is this endpoint still presenting the same behaviour that was originally reviewed?
Community proposals have therefore begun exploring signed tool manifests, allowing clients to detect when tool descriptions or schemas change after approval. (GitHub)
This is a classic trust distinction:
IDENTITY CONTINUITY ≠ BEHAVIOUR CONTINUITY.
14. A signed component can still be malicious
Signing is important.
It solves part of the problem.
A valid signature can establish:
who signed the component;
that the signed contents have not changed;
that what is installed matches the reviewed release.
It cannot establish:
that the signer is trustworthy;
that the instructions are safe;
that the tool behaves as documented;
that the component is suitable for this agent;
that the component will not return malicious runtime data;
that the authority given to it is appropriate.
A malicious developer can sign malicious software perfectly.
The same distinction exists throughout cybersecurity:
AUTHENTIC ≠ SAFE.
Agent supply-chain governance therefore needs both:
provenance
and
behavioural evaluation.
15. SBOM thinking is arriving—but agent dependencies are stranger than software dependencies
Traditional software supply-chain governance increasingly relies on Software Bills of Materials.
An SBOM can tell an organisation:
which packages exist;
which versions;
which dependencies;
which known vulnerabilities.
Agent systems require something analogous.
But the dependency graph is richer.
An agent may depend on:
model version;
system prompt;
skills;
plugins;
MCP servers;
external APIs;
remote instructions;
retrieval sources;
sub-agents;
authorization servers;
runtime packages;
credentials;
cloud services.
Some are conventional software dependencies.
Some are semantic dependencies.
A skill may reference a remote webpage whose instructions change without the skill package changing.
An MCP server may expose dynamic tool descriptions.
A sub-agent may change model versions.
An external API may return malicious content that enters the model’s context.
The future Agent Bill of Materials may therefore need to represent not only code packages but the broader dependency graph through which behaviour is produced.
16. Current ecosystem evidence suggests traditional supply-chain hygiene is immature
A recent independent catalogue audit illustrates the gap.
AgenticSkills reported analysing 199 MCP servers in August. Among the servers for which source repositories were auditable, it found no published SBOMs in the repositories it examined, although most had lockfiles and many had SECURITY.md files. The analysis is one catalogue snapshot rather than a representative study of all MCP servers, but it suggests conventional software-supply-chain controls have not yet fully migrated into the agent ecosystem. (AgenticSkills)
Meanwhile, Snyk reports anonymised telemetry from nearly 10,000 developer environments showing that 50.8% of developers in its dataset had live MCP server connections. Among developers using MCP, roughly one in twelve had a High or Critical finding in their environment according to Snyk’s scanning methodology. Developers averaged 18 installed agent skills, and Snyk reports 28% of scanned skills exposing agents to uncontrolled third-party content. Again, these are company telemetry and security classifications rather than universal prevalence estimates, but they show that the supply-chain layer is already measurable inside real development environments. (Snyk)
The security industry has noticed.
17. Capital is now funding the trust layer
AIR is not alone.
TechCrunch reports that the emerging category already includes companies such as Noma Security, Zenity, Astrix Security, and Operant AI, offering combinations of:
agent discovery;
MCP governance;
identity;
runtime controls;
tool monitoring;
security gateways;
skills inspection.
AIR raised $50 million while coming out of stealth.
Zenity reportedly raised a $125 million Series C in August.
Noma had previously raised a $100 million Series B. (TechCrunch)
The exact companies and winners will change.
The more important market signal is the category itself.
Venture capital is beginning to fund businesses whose product is not:
better AI.
It is:
trust infrastructure for the components better AI is allowed to use.
That is evidence that agent security is leaving the laboratory and becoming enterprise architecture.
18. The new perimeter is not the network
Traditional enterprise security imagined a perimeter.
Inside trusted.
Outside untrusted.
Cloud computing weakened that model.
Agentic AI weakens it further.
An agent continuously imports information and capabilities into its own working context.
A webpage can influence it.
A retrieved document can influence it.
A skill can instruct it.
An MCP server can describe behaviour.
A sub-agent can return recommendations.
The operational perimeter therefore becomes dynamic.
AIR describes its own product as a Context Firewall, positioned between agents and the external skills, MCP servers, plugins, websites, internal data, and other sources entering their context. (Air Security)
The phrase is vendor terminology, but it captures a real architectural shift.
The security boundary is no longer simply:
network inside / network outside.
It increasingly becomes:
which information and capabilities are allowed to enter the agent’s decision context?
19. Prompt injection becomes supply-chain compromise
This reframes prompt injection.
In a simple chatbot, indirect prompt injection may cause an embarrassing response.
In an agent, the injected instruction can redirect delegated authority.
Suppose the agent has:
email access;
financial data;
file access;
cloud deployment rights.
A malicious external document tells the agent to perform an unintended sequence.
The attacker has not stolen the credentials.
The agent still owns the credentials legitimately.
The attacker has redirected the agent that holds them.
This is why agent supply-chain attacks are so powerful.
They target the decision mechanism controlling valid authority rather than necessarily attacking the authority mechanism itself.
NIST’s 2026 material on agentic threats describes this category explicitly: agents can dynamically load third-party tools, prompt packs, extensions, MCP endpoints, A2A identities, and other components that alter behaviour while being implicitly trusted. (NIST CSRC)
The attacker may not break into the castle.
They convince the trusted actor inside it to open the gate.
20. Credentials amplify supply-chain risk
A compromised component becomes consequential because the agent already has access.
This gives us another important chain:
UNTRUSTED INPUT
↓
TRUSTED AGENT
↓
VALID CREDENTIAL
↓
LEGITIMATE TOOL
↓
ILLEGITIMATE CONSEQUENCE
From the downstream system’s perspective, everything may look correct.
The API call comes from an authorised identity.
The token is genuine.
The parameter schema is valid.
The action succeeds.
The failure occurred at the level of decision influence.
This is why identity security cannot solve agent supply-chain security alone.
Identity proves who acted.
It does not prove why the actor chose the action.
21. Least privilege becomes more important, not less
The obvious defensive principle is therefore to constrain the blast radius.
If the agent is compromised through one component, what can it actually do?
MCP’s authorization architecture has been steadily hardening around OAuth-based controls, resource-specific tokens, scope minimisation, and step-up authorization. The July 2026 specification added further authorization hardening, including stronger issuer validation and changes intended to improve deployment security at scale. (Model Context Protocol Blog)
OpenAI likewise advises developers using MCP to:
trust servers before connecting;
use least-privilege credentials;
avoid placing access tokens in URLs;
require approval for sensitive operations. (OpenAI GitHub Pages)
These controls do not make tool poisoning impossible.
They reduce what poisoning can accomplish.
A compromised weather tool cannot steal an entire customer database if the agent has no customer-database access.
A compromised coding skill cannot deploy to production if deployment authority lives elsewhere.
Supply-chain security therefore connects directly to authority engineering.
22. Tool trust should be contextual, not universal
Organisations often think of software as:
approved
or
not approved.
Agent tools require a more contextual model.
A tool may be safe for:
Agent A,
with read-only permissions,
in Environment X,
for Task Y.
The same tool may be unacceptable for:
Agent B,
with financial credentials,
in production,
with autonomous execution.
Trust therefore has at least three layers:
COMPONENT TRUST — Is the component itself considered legitimate and sufficiently secure?
CONTEXTUAL TRUST — Is it appropriate for this agent and environment?
AUTHORITY TRUST — Should it be allowed to influence or exercise the authority available here?
The binary whitelist remains useful.
It cannot capture everything.
23. Tool discovery itself can become dangerous
Another emerging shift is that humans may not install every tool manually.
Agents may increasingly discover tools dynamically.
An agent encounters a problem.
It searches for a capable service.
Reads the metadata.
Connects.
Acts.
This connects the supply-chain problem to the previous Synthocracy article on agent discovery standards.
The more autonomous tool discovery becomes, the less realistic it is to rely on a human carefully reviewing every component first.
Trust infrastructure will have to become machine-readable.
The agent may need to know:
who published the tool;
whether it is signed;
whether the publisher is verified;
what permissions it requires;
what security review occurred;
when it last changed;
whether vulnerabilities are known;
what reputation it has;
which organisation approved it.
Tool discovery becomes trust discovery.
24. The marketplace may become a security institution
AIR’s product strategy includes a marketplace of pre-vetted add-ons.
Other ecosystems will likely produce comparable mechanisms.
The marketplace can then perform several roles:
discovery;
verification;
signing;
reputation;
version management;
revocation;
distribution.
This resembles mobile app stores.
That has clear benefits.
A user no longer downloads arbitrary software from unknown websites.
A platform can scan applications.
Revoke malicious software.
Require signatures.
Enforce policies.
But the marketplace becomes a gatekeeper.
Who can publish?
Which security criteria apply?
Which scanner decides?
Can publishers appeal?
Can competitors be excluded?
Can one vendor become the default source of trusted agent capabilities?
The solution to supply-chain decentralisation can create trust centralisation.
That will eventually become a governance problem of its own.
25. Signing may create an agent equivalent of the trusted app ecosystem
Nvidia’s skill-signing implementation offers a preview of where the ecosystem may go.
A skill directory can carry a detached cryptographic signature covering its instructions, scripts, references, assets, and supporting files. Strict verification can fail if unsigned files appear after signing. (NVIDIA Docs)
Imagine this scaled into a wider ecosystem.
Every skill has:
publisher identity;
signature;
version;
hash;
dependency record;
permissions;
security review;
provenance.
MCP tools similarly expose signed manifests.
Agent runtimes refuse unknown components unless policy permits them.
This would reproduce lessons learned from:
signed drivers;
mobile applications;
container images;
software packages.
The remarkable fact is how quickly the agent ecosystem is rediscovering decades of software supply-chain security.
26. But instructions create a security problem code signing never had to solve alone
Traditional code signing asks:
Did this binary come from the claimed publisher, unchanged?
Agent components introduce another question:
What will these instructions cause the model to infer?
Two skill files can contain no exploit code.
One can still manipulate the agent into dangerous action through instructions.
Security review therefore needs a hybrid methodology:
static software analysis;
dependency analysis;
identity verification;
semantic instruction analysis;
permission review;
behavioural testing;
runtime monitoring.
This is why agent supply-chain security is not simply software supply-chain security with a new label.
The agent consumes both code and meaning.
Meaning itself can become executable through the model.
27. “Clean code” can return poisoned context
Consider a perfectly legitimate MCP server.
Its software is clean.
Its publisher is verified.
Its dependencies are current.
Its signature is valid.
The server retrieves public webpages.
One webpage contains a malicious indirect instruction.
The server returns that page to the agent.
The supply-chain component itself is not compromised.
The content supply chain is.
This reveals another layer:
SOFTWARE TRUST ≠ CONTENT TRUST.
Agent systems ingest large amounts of external content precisely because their value depends on accessing changing information.
That means no finite admission review can establish permanent safety.
Runtime context remains an attack surface.
28. The supply chain therefore extends into data
This broadens the concept dramatically.
The agent supply chain can include:
skills;
plugins;
MCP servers;
software libraries;
external APIs;
websites;
documents;
retrieval indexes;
datasets;
sub-agents;
models.
Each can introduce behaviour-changing information.
Traditional supply-chain governance stops at software dependencies.
Agent governance increasingly needs to ask:
Which external sources can materially change the agent’s reasoning or action trajectory?
That is the effective dependency graph.
29. Sub-agents are executable dependencies too
Suppose Agent A delegates research to Agent B.
A never installed B as software.
But B’s answer shapes A’s decision.
Functionally, B has become a dependency.
If B is compromised, deceptive, badly configured, or operating under conflicting incentives, the original agent’s behaviour changes.
This is why AIR includes sub-agents among the add-ons it says organisations should continuously assess. (Air Security)
The agent supply chain therefore merges with transitive authority.
A dependency may not be a library.
It may be another decision-maker.
30. A supply-chain review should include the authority chain
This is the Synthocracy extension of ordinary security practice.
For each important component, ask not only:
Who made it?
Was it signed?
Is it vulnerable?
Also ask:
What authority becomes reachable through this component?
If compromised, can it influence:
read access?
write access?
payments?
communications?
deployment?
delegation?
identity?
monitoring?
stop mechanisms?
The most dangerous dependency may be a very small one positioned beside a very large authority surface.
Supply-chain risk should therefore be mapped onto institutional power.
31. Tool permissions should be visible before installation
A skill or plugin marketplace should eventually behave more like a mature mobile operating system.
Before installation:
This component can read files.
This component can send external messages.
This component uses these MCP servers.
This component fetches remote instructions.
This component can execute scripts.
This component can invoke sub-agents.
This component can access financial data.
The human or organisational policy engine should understand the authority consequences before enabling it.
Today much of this remains fragmented across configuration, source files, documentation, and runtime permissions.
The next-generation agent marketplace will likely need something closer to a capability manifest.
32. Capability manifests may matter more than descriptions
A description says:
“Helps manage your GitHub projects.”
A capability manifest should say something closer to:
read public repositories;
read private repositories;
create issues;
modify branches;
merge pull requests;
execute CI actions;
access secrets: no;
external network: yes;
sub-agent delegation: no;
required credentials: GitHub OAuth.
This is much more useful for governance.
Natural-language descriptions optimise for usability.
Capability manifests optimise for authority legibility.
Future agent ecosystems will need both.
33. Versioning becomes governance
A familiar software update can have different consequences for agents.
Version 1.3 of a skill adds a new instruction.
Version 2.0 of an MCP server adds a write tool.
A plugin update adds another app.
The system’s authority surface changed.
The update should therefore potentially trigger:
new review;
new permissions;
new test cases;
new monitoring.
This makes version change an authority event.
The organisation should know not merely:
the tool updated
but:
did the update change what the agent can know, decide, or do?
34. Automatic updates create an unresolved tension
Security normally encourages timely updates.
Agent governance complicates this.
Automatic updates can fix vulnerabilities rapidly.
They can also change:
tool definitions;
instructions;
permissions;
dependencies;
runtime behaviour.
Pin everything permanently and security patches lag.
Update everything automatically and previously reviewed behaviour can drift.
The solution will probably require controlled continuous delivery:
cryptographically verified updates;
semantic and permission diffs;
automatic low-risk approval;
mandatory re-review for material capability changes;
rapid emergency revocation.
Agent supply-chain governance must balance freshness and stability.
35. Continuous verification will become more valuable than one-time certification
This is why AIR’s framing is strategically interesting.
One certification saying:
Tool Safe — January 2026
becomes progressively weaker evidence as the component, dependencies, or external sources change.
The relevant question becomes:
Is this component still inside the trusted state now?
That resembles modern zero-trust security more than traditional procurement certification.
Trust is continuously evaluated.
Identity can change.
Risk can change.
Permissions can change.
Dependencies can change.
Revocation must remain possible.
36. The security industry may become the curator of agent capability
This creates a larger institutional issue.
Suppose enterprises increasingly permit agents to use only components approved by:
AIR;
Microsoft;
Anthropic;
OpenAI;
Google;
a cloud provider;
a specialised security vendor.
These organisations begin deciding which skills, MCP servers, and plugins are considered trustworthy enough for economic use.
Their security decisions can therefore determine:
which software reaches enterprise agents;
which developers gain distribution;
which services become machine-visible;
which components become effectively excluded.
Supply-chain security can evolve into a market-admission function.
That is not an argument against vetting.
It is a reason to govern the vetters transparently as their importance grows.
37. Security labels themselves need provenance
Imagine an agent marketplace saying:
Verified Safe.
What does that mean?
Static code scan?
Publisher identity verified?
No known vulnerabilities?
No malicious instruction detected?
Runtime sandbox tested?
Permissions reviewed?
Supply-chain dependencies clean?
Monitoring enabled?
Date of last evaluation?
Security labels without clear meaning create false trust.
Future systems should expose evidence behind trust claims, not merely badges.
The label itself becomes another machine-readable input influencing agent selection.
38. Reputation can create circular trust
Suppose an agent chooses the most trusted tool.
The trust score is based partly on downloads.
Downloads increase because agents choose highly trusted tools.
The tool becomes more trusted because it is more popular.
This can create positive feedback.
Popularity is not proof of safety.
But machine-driven discovery can turn reputation metrics into self-reinforcing infrastructure.
Security scoring therefore needs resistance to:
Sybil attacks;
download manipulation;
brand impersonation;
fake reviews;
historical reputation after compromise.
The supply-chain trust system becomes its own attack surface.
39. The agent’s component inventory should be live
The previous article argued that institutions need a continuous inventory of agents.
Agent security requires another inventory:
what is inside each agent now?
A useful live record might map:
AGENT
↓
model/version
↓
system policy
↓
skills
↓
plugins
↓
MCP servers
↓
sub-agents
↓
external sources
↓
credentials
↓
tools
↓
permissions.
This is the agentic equivalent of configuration management.
Without it, incident response begins with basic archaeology:
What exactly was connected when the failure occurred?
40. Supply-chain provenance must survive after the component disappears
Ephemeral dependencies complicate the picture.
An agent discovers a temporary service.
Uses it once.
The server disappears.
Three weeks later, investigators need to reconstruct an incident.
What was the server?
Which version?
What description did it present?
Which output did it return?
Which identity operated it?
What permissions did the agent expose?
A URL alone may no longer be enough.
Consequential supply-chain interactions may require preserved:
hashes;
manifests;
tool descriptions;
publisher identity;
version;
security state;
call records.
That connects directly to authority provenance.
41. The agent should know what it is allowed to trust
Humans cannot manually approve every dynamic dependency at machine speed.
Agents may therefore need machine-readable trust policy.
For example:
use only signed skills;
use only MCP servers from approved registries;
do not execute components that fetch unverified remote instructions;
do not use tools requiring broader permissions than current mandate;
request step-up approval before installing write-capable tools;
do not delegate to unregistered external agents.
The policy becomes a boundary around capability acquisition.
This is important.
Most governance today asks:
What actions may the agent take?
Agentic supply-chain governance adds:
What new powers may the agent acquire without asking?
42. Capability acquisition is itself an authority
This deserves explicit recognition.
Suppose Agent A currently cannot send emails.
It can install tools.
It discovers and installs an email MCP server.
Now it can send email.
The agent effectively expanded its own capability.
The architecture may therefore distinguish:
ACTION AUTHORITY
from
CAPABILITY-ACQUISITION AUTHORITY.
An agent may be allowed to use approved tools but not add new ones.
Another may add read-only tools autonomously but require approval before adding write capabilities.
A research agent may discover data sources freely while being prohibited from acquiring execution tools.
This is a new and important governance boundary.
43. The right to install can be more powerful than the right to act
Consider a human workstation.
Giving an employee administrator rights is powerful partly because it lets the employee install software that later does many things.
Agents create the same problem.
An agent unable to perform one prohibited action may simply acquire a component that can.
If installation authority is broad, the effective permission boundary becomes porous.
This is why add-on governance belongs alongside ordinary authorization.
Control what the agent can acquire, not merely what it already has.
44. Model trust can be invalidated downstream
We can now state the central argument precisely.
Suppose an organisation concludes:
We trust Model X.
That may mean:
the provider is reputable;
the model passed evaluations;
its alignment is acceptable;
its cyber capability is known;
its monitoring is strong.
Useful information.
But the deployed agent may later consume:
a malicious skill;
a compromised MCP server;
poisoned retrieval;
a manipulated plugin;
a hostile sub-agent.
The model’s trustworthy behaviour under one environment does not establish trustworthy behaviour under all future contexts.
The operational trust object therefore becomes:
MODEL × CONTEXT × COMPONENTS × AUTHORITY.
Not model alone.
45. Tool trust is also insufficient
Now reverse the problem.
Every tool is trusted.
Signed.
Reviewed.
Safe individually.
The model can still combine them into an unacceptable trajectory.
So:
TOOL TRUST ≠ AGENT TRUST.
A secure filesystem tool plus a secure email tool can still produce data exfiltration if the agent misuses them in sequence.
Supply-chain governance cannot replace trajectory governance.
The layers complement each other.
46. Agent trust must therefore be compositional
This gives us the wider architecture.
A governable agent requires confidence across several layers:
MODEL TRUST
What is the underlying model capable of and how reliably does it respect constraints?
↓
COMPONENT TRUST
Are the skills, tools, servers, plugins, data sources, and sub-agents trustworthy?
↓
AUTHORITY CONTROL
What can those components reach using the agent’s credentials?
↓
TRAJECTORY CONTROL
Can safe components combine into an unsafe outcome?
↓
MONITORING
Can deviations be detected?
↓
STOP / REVOCATION
Can action or capability be removed?
↓
PROVENANCE
Can the system later prove what influenced the outcome?
No single layer substitutes for the others.
The Synthocracy Agent Supply Chain Test
The following is a preliminary governance diagnostic for organisations deploying agents with external skills, plugins, tools, MCP servers, and sub-agents. It is not a security certification or legal conformity assessment.
1. Component Inventory — Do we know what the agent depends on? Can the organisation identify the current model, skills, plugins, MCP servers, sub-agents, remote instruction sources, software dependencies, and external services involved in consequential workflows?
2. Publisher Identity — Do we know who supplied each capability? Are component publishers authenticated or otherwise attributable, and can impersonated or abandoned projects be distinguished from legitimate maintainers?
3. Integrity — Is the component the one that was reviewed? Are versions pinned where appropriate, signatures or hashes verified, and material changes to tool descriptions, schemas, scripts, or supporting files detected?
4. Behavioural Review — Is authenticity being confused with safety? Are instructions, code, external calls, hidden functionality, excessive permissions, and runtime behaviour examined rather than relying only on valid signatures?
5. Permission Fit — What authority becomes reachable through the component? Does a newly installed skill or MCP server expose sensitive data, external communication, payments, code execution, deployment, or other consequential actions?
6. Capability Acquisition — May the agent add new powers autonomously? Which new components may it discover or install without human approval, and which capability increases require step-up authorization?
7. Runtime Drift — Can trust change after installation? Are updates, remote instruction sources, dependency changes, tool-definition drift, publisher compromise, and other time-of-check/time-of-use risks continuously re-evaluated?
8. Composition Risk — What happens when trusted tools interact? Can several individually approved components create a harmful trajectory through combined data access and action authority?
9. Revocation — Can the component be removed fast enough? Can administrators disable one skill, server, plugin, credential, publisher, or entire component family without waiting for a full agent shutdown?
10. Provenance — Can an incident be reconstructed? Can investigators determine which component version, description, output, credential, agent state, and authority chain materially influenced the consequential action?
The central question is:
If one component the agent trusts were compromised tomorrow, what institutional power would that component be able to redirect?
That answer determines the real supply-chain exposure.
47. A useful maturity model is emerging
Agent supply-chain governance can be thought of as moving through several stages.
Stage 0 — Invisible dependencies
Users install skills and tools directly.
No central inventory.
No publisher verification.
No runtime review.
Stage 1 — Discovery
The organisation learns which agents and components exist.
Stage 2 — Admission control
Components are scanned, signed, allowlisted, or otherwise vetted before use.
Stage 3 — Permission control
Capabilities receive least-privilege credentials appropriate to their tasks.
Stage 4 — Continuous verification
Changes in dependencies, instructions, publisher status, and runtime behaviour are detected.
Stage 5 — Provenance and revocation
The organisation can reconstruct which component influenced an event and disable the component across its entire agent population.
Stage 6 — Machine-readable trust
Agents themselves can discover safe capabilities inside governed trust policies.
Most enterprises are only beginning this journey.
48. FORESIGHT — 2027+: The Agent Bill of Materials
FORESIGHT — This is an emerging possibility, not an established universal standard.
The software industry created SBOMs because organisations needed visibility into dependencies they did not write themselves.
Agentic systems may create pressure for a broader Agent Bill of Materials.
A possible ABOM could include:
model identity and version;
system-policy version;
skills;
plugins;
MCP servers;
sub-agents;
external instruction sources;
runtime environment;
permissions;
credentials classes;
tool manifests;
publisher signatures;
security status.
The objective would be simple:
Tell me what this agent is made of.
That question becomes increasingly difficult as agent capabilities become dynamic.
49. FORESIGHT — 2027+: Capability Bills of Materials
An even more useful layer may focus not on components but on what the combination enables.
An Agent Bill of Materials could say:
Agent uses Tool A, Tool B, and Tool C.
A Capability Bill of Materials could say:
this combination can:
read confidential files;
execute shell commands;
send external messages;
create cloud resources;
spend up to €5,000;
delegate to external agents.
That translation would be extremely valuable for boards and regulators.
Executives care less about package names than about effective power.
50. FORESIGHT — 2027+: Signed skills become normal
Nvidia has already implemented skill signing. Community projects are proposing signing for agent skills and MCP tool manifests. (NVIDIA Docs)
If the ecosystem matures along familiar software-security lines, unsigned agent capabilities may eventually become the equivalent of unsigned kernel drivers:
possible in experimental environments;
increasingly unacceptable in consequential enterprise systems.
The likely future distinction will not simply be:
signed / unsigned.
It will be:
who signed, under which trust framework, with which review evidence?
51. FORESIGHT — 2027+: Agent trust registries
A wider market may emerge around machine-readable registries containing:
publisher identity;
signatures;
security audits;
known vulnerabilities;
permissions;
version history;
incident history;
revocations;
compatibility;
enterprise approvals.
Agents could query these before acquiring a capability.
This would make supply-chain trust part of automated decision-making.
It would also create powerful new intermediaries.
The organisation maintaining the registry could influence which components become acceptable to the machine economy.
Trust registries would therefore need governance of their own.
52. FORESIGHT — 2027+: Continuous component reputation
Static certification may be too slow.
A component’s reputation could increasingly depend on:
runtime observations;
security incidents;
update behaviour;
publisher reliability;
vulnerability response;
complaints;
independent scans.
This resembles endpoint reputation and certificate ecosystems.
But once agents automatically choose components using these scores, the reputation service acquires market power.
A low score can make a component effectively undiscoverable.
The security layer becomes a distribution layer.
53. FORESIGHT — 2027+: Insurance becomes a supply-chain gate
Insurers may eventually require organisations using autonomous agents to demonstrate:
approved-component inventories;
signed skills;
MCP allowlists;
continuous scanning;
dependency provenance;
revocation;
least privilege.
A serious failure through an unvetted component could affect premiums or coverage.
This would turn insurance into another de facto standards mechanism for agent security.
54. FORESIGHT — 2027+: The corporate app store for agents
Large organisations may increasingly operate internal marketplaces of approved:
skills;
plugins;
MCP servers;
agents;
workflows.
Employees and agents will be free to build quickly inside the trusted catalogue.
External capabilities require automated or human review.
AIR is already commercialising a version of this idea through a vetted marketplace. (TechCrunch)
The internal agent marketplace may become as foundational as enterprise SaaS catalogues are today.
55. FORESIGHT — 2027+: Supply-chain regulation shifts from software to capability
Governments currently regulate:
software cybersecurity;
critical infrastructure;
financial outsourcing;
medical software;
data processing.
Agent ecosystems could force a new question:
Should high-consequence organisations be required to know which third-party agent capabilities participate in regulated decisions?
A bank may not be allowed to say:
“We approved the model but have no idea which external skills it installed before moving customer money.”
A hospital may need stronger controls over tools capable of modifying patient records.
A public agency may need to record which external agent or MCP server influenced an administrative action.
Regulation may therefore follow the agent supply chain into the decision chain.
56. FORESIGHT — 2027+: Dependency compromise becomes authority compromise
Traditional supply-chain attacks compromise software.
Agentic supply-chain attacks can compromise delegated authority.
That is the deeper difference.
The compromised package does not simply execute malware.
It may redirect an intelligent actor that already holds trusted access.
A tiny malicious instruction can potentially steer enormous legitimate capability.
This creates an unusual asymmetry:
small component → large authority surface.
Future attackers will naturally search for the smallest dependency positioned closest to the most powerful agents.
57. The best defence may be to make components disposable
Another architectural lesson may emerge.
Do not trust components permanently.
Give tools short-lived permissions.
Give skills bounded environments.
Allow temporary connections.
Revoke automatically.
Require renewed evidence after material updates.
This reduces dependence on proving that a component will remain trustworthy forever.
Security moves from:
this tool is safe
to:
this tool is currently permitted to perform this bounded function under these controls.
That is much closer to zero-trust thinking.
58. Supply-chain governance should preserve useful openness
There is also a risk of overreaction.
The explosion of open skills and MCP servers is producing enormous innovation.
A developer can connect an agent to a specialised service in minutes.
Small organisations can build capabilities previously requiring large software teams.
Researchers can share tools.
New agent businesses can enter quickly.
A security regime that requires six months of procurement before any tool can be used would destroy much of that value.
The goal should therefore not be:
close the ecosystem.
It should be:
make experimentation cheap and consequential authority expensive.
A low-risk sandbox can allow almost anything.
A production financial agent should not.
Governance should follow authority and consequence, not simply the existence of third-party code.
59. The trust boundary should move with the authority boundary
This is the practical rule.
A research agent reading public sources can operate inside a relatively broad ecosystem.
An agent holding payroll authority requires a dramatically narrower one.
A coding agent modifying a disposable branch can experiment.
An agent deploying production infrastructure requires stronger provenance and review.
The question is not:
Do we trust MCP?
Or:
Do we trust plugins?
Or:
Do we trust skills?
Those categories are too broad.
Ask:
Which components may influence this level of authority?
That is the relevant boundary.
60. The supply chain is becoming part of institutional architecture
At this point, the problem is no longer just cybersecurity.
Imagine an agent choosing suppliers.
A third-party skill defines the evaluation procedure.
An MCP server supplies the available candidates.
Another tool provides risk scores.
A plugin enables payment.
The supply chain is shaping the institution’s economic decisions.
The components become parts of the decision architecture.
Who selected them?
Who audited them?
Who can change them?
Who notices if they drift?
The software supply chain has become part of the power chain.
That is where the problem enters Synthocracy.
Conclusion — The agent is only as trustworthy as the capability chain around it
The AI industry spent years learning how difficult it is to evaluate models.
Agentic AI has now added another problem.
The model can remain unchanged while its effective behaviour and authority change after deployment.
AISI’s analysis of 177,436 MCP tools shows how rapidly the tool ecosystem has expanded and how strongly usage is shifting toward action rather than passive perception. MCP has become an important interoperability substrate with extraordinary developer adoption. Academic research has demonstrated tool poisoning and malicious-skill attacks. Anthropic is scanning enterprise skills and plugins. OpenAI explicitly warns developers that MCP servers may expose data and perform actions with user credentials. Nvidia is signing skill packages. Snyk’s enterprise telemetry indicates significant MCP and skill exposure in real developer environments. And AIR has raised $50 million around the proposition that agent components require continuous vetting rather than one-time approval. (AI Security Institute)
These are not separate trends.
They describe a new layer of AI infrastructure.
The agent is increasingly assembled from:
MODEL
↓
INSTRUCTIONS
↓
SKILLS
↓
PLUGINS
↓
MCP SERVERS
↓
SUB-AGENTS
↓
DATA
↓
CREDENTIALS
↓
TOOLS
↓
ACTIONS
Every layer can increase capability.
Every layer can introduce compromise.
Every layer can change after the model itself has been approved.
That is why the central rule is:
MODEL TRUST ≠ TOOL TRUST ≠ AGENT TRUST.
But even that formulation is incomplete.
A trusted model plus trusted tools can still produce an unsafe trajectory.
A legitimate tool can become unsafe when paired with excessive permissions.
A signed skill can still contain malicious instructions.
A secure MCP server can return poisoned external content.
A vetted component can change after approval.
A trusted sub-agent can operate under the wrong mandate.
The real governance object is therefore not the component.
It is the capability chain.
For every consequential agent, organisations increasingly need to know:
what components it trusts;
who supplied them;
what changed since review;
what authority those components can reach;
what new powers the agent may acquire autonomously;
how quickly a component can be revoked;
and whether the resulting action can still be traced back through the dependency and authority chain.
The old software-security lesson was:
You are vulnerable to the code you depend on.
The agent era adds something more consequential:
You are vulnerable to the instructions, tools, data, services, and other agents that your AI is willing to trust with the authority you gave it.
That is the AI agent supply chain.
And as agents receive more consequential permissions, the supply chain around them is no longer merely the software they use.
It is becoming the infrastructure through which institutional power can be extended, redirected, or compromised after deployment.
