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

Static review is strongest when facts are visible in artifacts: vulnerable dependencies, unpinned Git references, suspicious install hooks, hard-coded secrets, obfuscated text, excessive tool declarations, or a license mismatch. Semantic review examines what instructions ask the model to do, which conditions activate them, and whether the component attempts to override higher-priority policy. Neither mode reliably proves runtime behavior.

Dynamic review should install and exercise the component in a clean, instrumented environment. Start with documented steps; deviations are themselves findings. Give the environment synthetic credentials and canary data, constrain network destinations, record file and process activity, and expose only test resources. The review environment should never require live production credentials; if a test depends on them, the test design has already crossed the trust boundary it is meant to evaluate. Exercise normal tasks, malformed inputs, injected content, denied permissions, expired tokens, tool failures, and cancellation. Compare observed actions with the manifest. An undeclared destination or attempted file read can matter even if no data left the sandbox.

Human review remains necessary for ambiguity and risk acceptance. Automated systems can rank findings and test broad surfaces, but someone accountable must decide whether a discrepancy is a hard failure, a constrained-use condition, or accepted risk. Accepted risk needs an owner, rationale, scope, and expiry. “The model did not flag it” is not an approval record.

Promote with a capability envelope

Promotion should publish more than a green check. The decision record should bind the release digest, build inputs, capability envelope, test-suite version, reviewer, known findings, and expiry. Consumers need a capability envelope: approved version, allowed environments, permitted identities, tool set, data classes, egress policy, required approvals, sandbox requirements, evaluation suite, known limitations, and expiry or re-review triggers. A component reviewed for synthetic data and read-only tools should not silently become approved for production credentials and mutations.

The envelope also separates component quality from local deployment responsibility. A centrally reviewed MCP server can still be deployed badly—with an overpowered service credential, overly broad collaborators, or unrestricted outbound access. Conversely, a component with a narrow finding may be usable inside a stricter local envelope. Admission establishes the maximum reviewed posture; the deployment may narrow it but should not expand it without another decision.

Make trust change-sensitive

‍