TL;DR: Most MCP servers and skills arrive as unscanned packages, Markdown bundles, or remote endpoints rather than hardened containers, so Dockyard repackages them into signed OCI artifacts and gates them with Cisco AI Defense scanners plus Grype, according to Stacklok. The security problem is not packaging alone but the trust gap between agent tooling and the identities, secrets, and permissions those tools can reach.
NHIMG editorial — based on content published by Stacklok: Blog Integrations Inside Dockyard: How Stacklok + Cisco AI Defense are securing MCP servers and skills
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?
A: Because they sit inside an active decision layer.
Q: What breaks when MCP tools are treated as trusted by default?
A: When MCP tools are trusted by default, a poisoned or spoofed component can inherit privileged access, manipulate outputs, or expose secrets without crossing a traditional perimeter.
Practitioner guidance
- Define MCP admission controls before deployment Require every MCP server or skill to pass pre-admission review for provenance, scanning, and ownership before it can be published to an internal registry or allowed into an agent runtime.
- Separate trusted runtime dependencies from build-time helpers Block runtime images when scans find issues in live server paths such as /app/node_modules or /opt/uv-tools, while keeping base-image and build-time findings in a separate exception path.
- Make attestation verification mandatory at consumption time Verify signatures, SBOMs, and security-scan attestations in registry admission or deployment policy so downstream teams can confirm that the artifact they use is the one that was approved.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- The spec.yaml structure used to repack npx, uvx, go, and skill sources into OCI artifacts
- The Cisco AI Defense scanner gates, including how mcp-scanner and skill-scanner are configured in CI
- The exact Grype handling for base-image, build-time, and runtime package findings
- The Cosign and SCAI attestation workflow used to verify published artifacts downstream
👉 Read Stacklok's post on Dockyard, MCP server packaging, and AI Defense scanning →
MCP server packaging and attestation: are your controls keeping up?
Explore further
MCP packaging has become an NHI governance boundary, not just a delivery format. The article shows that npm, PyPI, Go, and skill bundles can all carry privileged tool logic into agent workflows without the normal container assurance teams expect. That shifts the identity question from “can we run it?” to “what exactly is being trusted to act on behalf of the agent?” The practical conclusion is that MCP distribution now belongs inside NHI governance and software supply-chain controls at the same time.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who should own exceptions for unscanned MCP packages and skill bundles?
A: The owning team should, with security review enforcing the policy. Exceptions need a named owner, a written rationale, and a time-bound revisit path so that allowlists do not become permanent blind spots. Without that discipline, exceptions quickly turn into unmanaged trust.
👉 Read our full editorial: Dockyard shows how MCP packaging becomes identity governance