Agents, Skills, and MCP Servers Are a Software Supply Chain: Build an Admission-Control Pipeline

Reusable agent components accelerate delivery. They also import instructions, code, dependencies, credentials, tool reach, and egress into the runtime. Security therefore needs a version-bound admission decision—not a trust badge attached to a name.

s, container images, and service templates. A skill can encode a high-value operating procedure. An MCP server can turn an internal API into a discoverable tool surface. A prebuilt agent can compress weeks of orchestration work into a deployable starting point. This is useful precisely because the component brings behavior with it.

That same property creates the security problem. An agent component is not only source code. It may contain natural-language instructions that alter model behavior, scripts with install-time effects, third-party libraries, credential flows, tool schemas, allowed destinations, and assumptions about who may authorize an action. A conventional malware scan is still necessary, but it does not answer whether a seemingly benign instruction causes secret disclosure, whether a read-only tool can be chained into a write path, or whether installation reaches an undeclared endpoint.

The right abstraction is an admission-control pipeline for behavior-bearing releases. The decision should bind to an immutable state, scale review depth with capability, exercise uncertain behavior under containment, and expire when material facts change.

Review a release, not a listing

A practical release identity starts with an immutable source commit or content digest. It should also record the repository and publisher, license, build recipe, dependency lock state, included instruction files, exposed tools, requested secrets, network destinations, data classes, and installation steps. The goal is not to create paperwork for its own sake. It is to make the decision reproducible: a reviewer should be able to state exactly which bytes and capabilities were assessed.

This is where agentic supply chains diverge from ordinary libraries. Two releases with identical executable code can behave differently if their instructions differ. Two agents with identical prompts can carry different risk if one receives a finance tool and the other receives a public-search tool. The component’s effective behavior emerges from the artifact, model and runtime context, and authority available at execution. The manifest therefore needs both artifact facts and the capability envelope in which the component was tested; a digest alone cannot describe the resulting behavior.

Classify capability before selecting review depth

Not every component deserves the same review path. A prose-only skill that summarizes a public document has a different surface from an MCP server that can rotate production credentials. But “no executable code” does not mean “no security risk.” Instructions can contain hidden Unicode, encoded directives, misleading activation rules, data-exfiltration steps, or permission-expanding guidance. Conversely, a small server with source code may be low risk if it wraps a documented read-only endpoint, uses pinned dependencies, has no credential custody, and cannot reach arbitrary networks.

A useful classifier considers at least five dimensions: execution, data sensitivity, authority, egress, and dual-use capability. Execution asks whether the component contains scripts, install hooks, shell access, or dynamic loading. Data asks which classifications it can read or emit. Authority asks whether exposed tools are read-only, reversible, mutating, or destructive. Egress asks whether destinations are fixed, policy-controlled, or arbitrary. Dual-use capability asks whether the component can scan, exploit, manipulate credentials, or change security controls even when its stated purpose is defensive.

The classification should determine the controls, not merely the queue priority. A low-risk prose skill may receive structural checks, hidden-content detection, instruction analysis, and a limited behavior test. A mutating MCP server should add dependency and secret-flow analysis, schema inspection, authentication review, constrained dynamic execution, and negative tests for unauthorized operations. A component capable of offensive security actions may require a separate policy decision before technical review begins at all.

Build an admission pipeline that combines evidence types

‍