AI Agent Supply-Chain Security: Skills, MCP and Plugins

An enterprise AI agent is assembled, not installed. The finished system may include a foundation model, orchestration framework, reusable skills, MCP servers, plugins, retrieval connectors, document parsers, observability libraries and ordinary software packages. Each component can influence what the agent sees or what it is allowed to do.

That ecosystem is becoming a new software supply chain. It inherits familiar risks—compromised maintainers, typosquatting, vulnerable dependencies and malicious updates—but adds an unusual property: plain-language instructions and metadata can change behavior without looking like executable code.

This is already visible in enterprise environments. Snyk's agentic development supply-chain research describes MCP connections and reusable agent skills spreading across developer systems, including components exposed to uncontrolled third-party content. The exact prevalence will vary by organization, but the governance problem is no longer hypothetical.

Security teams need a review model that covers both dimensions. They must assess conventional code execution and the semantic influence a component has over the model. Scanning a package for malware is necessary; it does not prove that a tool description, skill instruction or retrieved document cannot redirect the agent toward an unsafe action.

What belongs in the AI agent supply chain

Start with everything that can change the agent's decisions, capabilities or operating context. The model and application source are only the center. Around them sit system prompts, agent skills, workflow templates, MCP clients and servers, browser extensions, tool schemas, plugins, package dependencies, container images, vector-store clients, embedding models and data connectors.

Configuration is part of the chain. An MCP server URL, OAuth scope, agent rule file or automatic approval setting can materially alter risk even when no package version changes. So can the external service behind a stable endpoint.

Data also has supply-chain characteristics when the agent treats it as reusable authority. A shared prompt template, imported knowledge base or community-maintained retrieval source can carry persistent instructions into many deployments. The artifact may not execute directly, yet it can steer a tool-using agent toward execution.

Create a component map that records the owner, source, exact version or digest, update channel, privileges, network destinations, data access and which model-facing fields it controls. Include development workstations and local agents; supply-chain exposure often begins outside centrally managed production.

The inventory method in Shadow AI Agents helps find unsanctioned runtimes. This article extends that inventory into the components each runtime trusts.

Why skills are more powerful than they look

An agent skill may be described as a reusable set of instructions, but practical skills can include scripts, templates, hooks, package requirements and tool calls. Once installed, the skill may be loaded automatically whenever a matching task appears.

That convenience creates three risks. First, a malicious publisher can include overt code that steals data or modifies the environment. Second, an apparently benign skill can contain instructions that persuade the agent to use existing tools unsafely. Third, a later update can introduce either behavior after the component has earned trust.

Review skill provenance like a software dependency. Who controls the repository and release process? Is the distributed artifact tied to a reviewed commit? Are updates automatic? Does the skill fetch remote content or install packages at runtime? What permissions are genuinely necessary for its stated purpose?

Do not assume a popular name is authentic. Typosquatting and cloned listings are inexpensive, and natural-language descriptions make it easy to imitate a trusted project. Use an approved internal registry or allowlist, pin versions and require review when a skill requests new capabilities.

Test semantic behavior as well as code. Give the skill adversarial but safe inputs and observe whether it changes scope, contacts undeclared hosts, reads unrelated files or delegates to another tool. The companion guide AI Agent Skills Security provides a focused assessment method.

MCP servers are privileged dependencies

MCP makes it easier to connect agents to tools and data. That interoperability also means a newly configured server can introduce many callable operations and large amounts of model-visible metadata in one step.

Assess the server implementation, hosting environment, authentication design and every exposed tool. A server that only advertises read operations may still access sensitive sources. A tool with a harmless name may accept a path, URL or query that crosses authorization boundaries. Tool descriptions can influence selection and conceal side effects.

Remote MCP servers add service-provider risk. Local servers add endpoint risk because they may execute with the developer's filesystem access and inherited environment. In both cases, constrain identity and egress. Do not hand a third-party server a broadly scoped token simply because the desktop client makes configuration easy.

Pin or approve server versions and monitor tool-catalog changes. A new tool, modified description or broadened input schema should trigger review. Gateways can centralize authentication, allowlists and logging, but direct local connections may bypass them. Test alternate paths rather than assuming the diagram is enforced.

For deeper technical controls, see MCP Security Testing and MCP Gateway Security.

Traditional packages still matter

Agentic systems run on ordinary software, so normal supply-chain controls remain essential. Frameworks pull parsers, HTTP clients, serialization libraries, database drivers and command utilities into a process that may handle sensitive context. Vulnerabilities in those components can bypass model-focused safeguards entirely.

Use lockfiles and immutable build inputs. Verify package signatures or provenance where ecosystems support them. Generate a software bill of materials, scan for known vulnerabilities and review unusual maintainer or ownership changes. Protect release pipelines with branch controls, isolated builders and short-lived credentials.

Pay special attention to installation scripts, dynamic plugin discovery and packages suggested by the agent. An attacker-influenced agent may choose a misspelled or low-reputation package. Route package resolution through an approved repository and block arbitrary registry changes.

Document and archive the exact artifact deployed, not only the version string. Mutable tags and overwritten releases make later investigation difficult. Container images, prompts, skills and MCP configuration should be linked to the same release record so the full system can be reconstructed.

The AI Agent Framework Security guide describes how framework parsers, caches and serializers can turn hostile content into conventional software impact.

Build an AI bill of materials

A traditional SBOM answers which software libraries are present. An AI bill of materials, or AIBOM, should add components that determine agent behavior and authority.

Record model provider and version, system-prompt revision, orchestration framework, skills, plugins, MCP servers, tool schemas, retrieval sources, embedding components, memory stores, identity grants, approval policy and external service dependencies. For each entry, capture owner, environment, data classification, provenance and last review.

Avoid producing a static spreadsheet that immediately becomes stale. Populate the inventory from repositories, deployment manifests, runtime discovery, identity systems and network telemetry. Compare observed tool calls and outbound destinations with declared components. Unexpected differences are valuable security signals.

Tie every assessment finding to the relevant component and version. If a malicious tool description is fixed, the evidence should show which catalog revision was retested. If a model or framework changes, identify which previous results need revalidation.

Our detailed AI Agent Bill of Materials guide explains a practical schema and operating model for this inventory.

Control onboarding and updates

Supply-chain governance fails when initial approval is careful but updates are invisible. Define an onboarding process based on risk. A local formatting skill and a production payment tool should not require identical evidence.

At minimum, verify publisher identity, source repository, license, maintenance history, artifact integrity, declared network behavior and requested permissions. Review code and embedded instructions. Run the component in a disposable environment and compare observed activity with its declaration.

Then define what changes require renewed approval: maintainer transfer, signing-key change, new dependency, new host, broader OAuth scope, altered tool schema, added script, modified instruction or automatic-update behavior. Use staged rollout and retain a tested rollback version.

Do not let the agent approve its own dependencies. Suggestions can enter a normal change-management path, but a separate human or policy system should authorize installation. For high-impact components, require two-person review and evidence from adversarial testing.

Maintain an emergency blocklist and kill switch. Teams should be able to disable a compromised skill, revoke a server credential or prevent a package digest from running without waiting for every workstation owner.

Use least privilege to limit supplier impact

Assume that an approved component may eventually be compromised. Containment determines whether the incident affects one disposable task or the enterprise environment.

Give each agent and integration a dedicated identity. Issue short-lived tokens restricted by tool, resource, tenant and action. Keep production credentials out of developer agents and prevent a read-only component from acquiring write access through another connected tool.

Segment execution. Document parsing, model orchestration and tool execution do not need to share a process or filesystem. Run third-party components with a non-privileged user, minimal mounts and explicit egress. Broker sensitive operations through a trusted service that rechecks authorization.

Be cautious with composition. Two individually acceptable tools can form a dangerous path: one reads private data and another publishes content. Evaluate combinations and data movement, not just each tool in isolation. Excessive Agency in AI Systems explains how functionality, permissions and autonomy multiply one another.

Test the supply chain behaviorally

Static scanning finds vulnerable or suspicious code, but it cannot fully assess how natural-language metadata influences an agent. Add behavioral testing in a synthetic environment.

Seed skills, tool descriptions, package documentation and retrieved content with harmless adversarial instructions. Observe whether the agent invokes undeclared tools, reads unrelated canary files, changes configuration or attempts network contact. Test update scenarios in which a previously safe component changes its description or permissions.

Exercise transitive relationships. A skill may call an MCP tool that invokes a package that fetches a remote script. Evidence should trace the full sequence. Capture the initiating content, component versions, model decision, tool arguments, identity, approval, network activity and final state.

Test downgrade and rollback as well. If the current component is disabled, does the client silently select an older vulnerable version? Does cached metadata survive removal? Are long-lived sessions still using an outdated tool catalog?

Turn confirmed paths into regression cases. Supply-chain controls are only durable when a future update cannot quietly reopen the same route.

Monitor for drift and compromise

Runtime monitoring should compare behavior with the approved declaration. Alert on new tools, permission changes, undeclared destinations, unexpected package installation, modified digests and unusual cross-repository access.

Preserve provenance in logs: agent identity, initiating user, task, skill and version, MCP server, tool definition version, credential scope, policy decision and downstream effect. Without this context, investigators may see an API call but cannot identify which supply-chain component caused it.

Use canary resources carefully to detect unauthorized reads. Track failed policy checks and repeated attempts, not only successful actions. A compromised component may probe boundaries before finding a viable route.

Prepare incident procedures before adoption expands. The team should know how to quarantine workspaces, revoke integration tokens, identify every installation, remove poisoned memory or cached metadata and preserve evidence. The AI Agent Incident Response and Forensics guide provides a complete playbook.

Enterprise supply-chain checklist

Before trusting an agent component, confirm that:

• The component and all transitive dependencies appear in a maintained inventory.
• Publisher, repository, version and artifact digest are verified.
• Code, scripts, instructions, schemas and network behavior have been reviewed.
• Installation and updates require a controlled approval path.
• Automatic changes cannot silently broaden permissions or introduce tools.
• Each component runs with a dedicated, least-privileged identity.
• Filesystem, process and network access are constrained.
• Tool combinations and cross-system data movement have been threat-modeled.
• Runtime behavior can be tied to the exact component revision.
• Adversarial tests cover malicious metadata, update drift and indirect execution.
• Emergency revocation and rollback have been rehearsed.

Trust must be continuously earned

AI agent supply-chain security is not a one-time vendor questionnaire. Components update, instructions change, services add tools and permissions drift. The operating model must combine inventory, provenance, least privilege, isolation, monitoring and repeated behavioral validation.

The essential shift is to treat every component that can influence an agent as security-relevant, whether it contains executable code or natural-language behavior. That is how enterprises gain the benefits of a fast-moving ecosystem without inheriting invisible authority.

Oxyne helps teams assess supported agentic AI implementations across application, model-behavior, tool, MCP and permission boundaries. Explore the Oxyne platform, read the AI coding agent security guide, or book a scoped demonstration.