From Models to MCP Servers, Skills, and Plugins: Rethinking Trust in the AI Supply Chain

An enterprise can approve an AI model, authenticate its users, and restrict access to internal systems, yet still expose sensitive data through the components surrounding that model.

In September 2025, an MCP server distributed through npm demonstrated how quickly trust can become a liability.

The package, postmark-mcp, allowed AI assistants to send email through Postmark. It operated normally across its first 15 versions and reached approximately 1,500 weekly downloads. Then version 1.0.16 introduced a hidden change: every outgoing email was silently copied to an external address controlled by the package developer.

When the server was installed, it had no signs of malicious behaviour. It gained adoption, entered agent workflows, and changed after users had already decided to trust it.

Traditional supply-chain controls have a clear response to this form of compromise: verify provenance, review changes, pin versions, scan dependencies, and revoke affected releases.

Those controls remain essential. But agentic AI introduces two additional questions: what instructions can a component introduce, and what authority can the agent exercise when it follows them?

The AI Supply Chain Now Extends Into Agent Behavior

The AI supply chain still includes source code, datasets, model weights, libraries, build pipelines, and deployment infrastructure. Model artifacts can introduce risk before inference even begins. Researchers have documented serialized model files that execute arbitrary code when loaded, showing why third-party weights must be treated like untrusted binaries.

Agents add components that directly shape decisions and actions:

• MCP servers connect agents to files, databases, APIs, and execution environments. Their code, tool definitions, authentication, and returned content all affect risk.

• Skills package natural-language instructions, reference material, and sometimes executable scripts. They can influence how an agent selects and uses tools.

• Plugins can bundle skills, hooks, commands, agents, scripts, and MCP servers behind a single installation.

• Agent configuration defines available tools, task instructions, approval rules, memory, and execution behavior. It should be reviewed as security-sensitive logic rather than harmless configuration.

These layers are not independent. A plugin can install a skill that retrieves external instructions and invokes an MCP tool using the employee’s credentials. Approving the top-level package does not automatically validate every dependency, instruction source, or action it enables.

This creates three distinct trust decisions:

1. Artifact trust: Who published the component, which version is running, and has it changed?

2. Instruction trust: What prompts, metadata, tool descriptions, retrieved documents, or memory entries can influence the agent?

3. Execution trust: What data and systems can the agent reach, and which actions can it perform?

Security teams need all three. Provenance without runtime control can verify the origin of a component while leaving its authority largely unconstrained.

The Trust Decision Happens Before the Risk Appears

Most components are reviewed when they are installed or connected. Their behavior continues to evolve afterward.

Tool-poisoning research demonstrated that malicious instructions could be embedded in MCP tool descriptions. Once read by the model, those instructions could redirect agent behavior and influence how other connected tools were used.

The same timing gap enables rug pulls. A server or skill can pass review and later change its definitions, scripts, dependencies, or referenced content. The original approval may have been valid, but it described a different version of the component.

Tool results create another gap. A legitimate integration may return an attacker-controlled issue, document, webpage, or message. In a GitHub MCP demonstration, malicious instructions inside a public issue caused an agent to retrieve information from a private repository and publish it through a public pull request. The integration itself was legitimate, and the agent already possessed the necessary access. The failure came from combining untrusted content, a sensitive read, and an external write.

This is why component approval cannot be treated as a permanent runtime decision. Connect-time review establishes what was trusted at one moment. It does not determine whether every future input, tool sequence, or destination should be allowed.

The Same Component Can Have a Different Blast Radius

Risk depends on where a component runs.

A skill operating inside a restricted cloud sandbox does not have the same blast radius as the identical skill running on a developer workstation with shell access, source code, environment variables, local credentials, and unrestricted network connectivity. The file may be unchanged while the potential impact is completely different.

Skills also create a two-layer inspection problem. Their natural-language instructions can manipulate the agent, while their scripts can perform the actual operation. In one study of 3,984 publicly available skills, researchers found 534 with Critical-level security issues and confirmed 76 malicious payloads. Every confirmed malicious sample contained malicious-code patterns, while 91% also used prompt injection.

Scanning only the scripts can miss the instructions that persuade an agent to run them. Scanning only the Markdown can miss the executable payload. Review must cover the full package, its external references, and its behavior inside the intended execution environment.

Persistent memory and retrieval systems extend the risk further. A poisoned document or stored instruction can continue influencing decisions after the original component has been removed. Incident response may therefore require reviewing memory entries, retrieved content, generated configuration, and files modified during the affected sessions.

A Five-Step Plan for Securing the AI Supply Chain

1. Build a live inventory. Create an AI bill of materials covering models, datasets, agents, MCP servers, skills, plugins, configurations, and upstream dependencies. Record the owner, source, version, deployment location, connected systems, and available permissions. Akto extends this inventory into workforce environments by discovering the AI components employees are actually using, including installations outside approved processes.

2. Gate components before they enter. Verify provenance, pin approved versions, review updates, and isolate untrusted model artifacts. Review natural-language instructions alongside scripts, hooks, metadata, nested dependencies, and remote references. Re-evaluate any material change instead of allowing an earlier approval to carry forward automatically.

3. Limit the execution context. Give agents scoped identities and task-specific credentials. Restrict filesystem, process, network, and tool access according to the environment in which each component runs. Apply stronger approval requirements to external writes, destructive operations, privilege changes, and transfers of sensitive data.

4. Test components as a system. A safe component can still participate in an unsafe sequence. Test the deployed combination of model, tools, data, identity, memory, and approval settings against prompt injection, poisoned tool results, malicious skills, and excessive agency. Akto continuously red teams homegrown agents and MCP servers across these attack paths instead of treating validation as a one-time release gate.

5. Enforce policy and retain the evidence. Evaluate prompts, responses, tool requests, target resources, and destinations while the agent is running. Akto guardrails can stop interactions that violate security policy, while Agent Traces preserve the prompts, tool calls, outputs, policy hits, and session context needed to investigate anomalous behavior. When a dependency becomes unsafe, teams can identify the affected activity and accelerate containment and credential rotation.

The goal is not to assign permanent trust to a model, server, skill, or plugin. Trust must remain scoped to a specific component, version, execution environment, identity, and task. That is the shift from securing AI artifacts to governing the full chain that turns instructions into actions.