Dockyard shows how MCP packaging becomes identity governance

At a glance

What this is: Stacklok’s Dockyard repackages npm, PyPI, Go, and skill-based MCP content into signed artifacts and checks them with multiple scanners before release.

Why it matters: IAM, PAM, and NHI teams need to treat MCP distribution as an identity control problem because unscanned tool servers can inherit access, secrets, and trust without a normal software supply-chain boundary.

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.

👉 Read Stacklok's post on Dockyard, MCP server packaging, and AI Defense scanning

Context

MCP server security is not just a packaging issue. It is an identity governance problem because these tool endpoints can inherit secrets, permissions, and trust relationships before security teams have a stable way to inspect what they do or what they can reach.

The article focuses on the gap between how MCP servers are distributed and how enterprises usually secure software. Many arrive as npm packages, PyPI modules, Go modules, or skill folders, which means the control point has to move earlier in the lifecycle, before runtime access is granted.

That starting position is typical for fast-moving AI adoption: teams want the capability first and the governance model later. The result is a familiar pattern of tool sprawl without consistent attestation, scanning, or lifecycle ownership.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?

A: Because they sit inside an active decision layer. The server is not just code on disk, it is a tool path that an agent can invoke with real permissions and live data. That makes install-time trust, runtime intent, and revocation all part of the same governance decision.

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. The failure is not only technical compromise. It is the assumption that registration equals trust. Teams should verify provenance, scope permissions tightly, and review tool behaviour continuously.

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.

Technical breakdown

Why MCP servers become trust-boundary problems

MCP servers often arrive as executable packages or Markdown-based skills rather than as standardized, security-reviewed containers. That matters because the agent consumes the tool as an extension of its own runtime, which means prompt injection, toxic tool combinations, and hidden credential exposure can all emerge before a human operator notices. The security challenge is less about where the code lives and more about whether the tool can be evaluated before it enters the agent’s trusted context.

Practical implication: treat MCP distribution as a pre-admission control point and require inspection before any tool is allowed into an agent workflow.

Why live scanning beats static package review for MCP

A static package review cannot reliably reveal how an MCP server behaves once initialized. Live scanners start the server, perform the handshake, enumerate tools, and test descriptions for prompt-injection patterns, cross-boundary escalation, rug-pull behaviour, and toxic tool flows. That is a different control model from conventional code scanning because the risk lives in runtime tool semantics as much as in source code. For skill bundles, the challenge is even harder because the content is mostly natural language, which shifts detection toward semantic analysis.

Practical implication: validate MCP servers in execution, not just at rest, and tie release approval to the scanner result rather than package metadata alone.

How signed artifacts and attestations change downstream trust

Signing an MCP server container or OCI artifact does not make the tool safe by itself, but it does create a verifiable custody chain from build to consumption. SBOMs, provenance attestations, and scan attestations let downstream teams decide whether the artifact they pulled is the one that was scanned, signed, and approved in CI. That is especially important for AI toolchains because trust has to survive repackaging, registry promotion, and agent deployment without relying on tribal knowledge.

Practical implication: make signature verification and attestation checks mandatory in admission and deployment workflows for agent tooling.

NHI Mgmt Group analysis

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.

Tool semantics are now part of the identity attack surface. The article’s emphasis on prompt injection, toxic flows, cross-origin escalation, and rug-pull patterns is a reminder that tool permissions are not defined only by RBAC or API scope. The behaviour of the tool itself can redirect an agent into unsafe actions even when the underlying package appears legitimate. Practitioners should read that as a control-model shift: identity approval must cover intended use, not only package provenance.

Signature and attestation only matter when they are enforceable downstream. Dockyard’s model is useful because it connects scan results, signatures, and provenance to a registry artifact that can be verified later by consumers. That matters for NHI governance because trust must survive beyond the build pipeline and into deployment admission. The takeaway is that artifact trust is becoming a first-class identity control, not an optional supply-chain enhancement.

Named concept: MCP trust inheritance gap. MCP servers often inherit a trusted position inside agent workflows before security teams have established who owns them, how they are scanned, or whether they can be revoked cleanly. That gap is not a tooling flaw alone, it is a governance failure mode that appears when identity, packaging, and runtime access are handled as separate problems. Practitioners should treat that inherited trust as a boundary that must be explicitly governed.

From our research:

• 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.
• For a broader agentic context, see OWASP Agentic Applications Top 10 for the controls that address tool misuse and identity exposure.

What this signals

MCP governance is converging with NHI supply-chain control. The practical next step for most programmes is to treat tool packaging, signature verification, and registry admission as identity controls, not only build controls. The more agent workflows depend on third-party MCP servers, the more important it becomes to know which artifacts are trusted, who signed them, and how that trust can be revoked.

MCP trust inheritance gap: This article highlights the gap between package provenance and operational trust. The governance challenge is not simply finding packages, but ensuring that every tool an agent can call has a documented owner, a bounded purpose, and an enforceable approval path before it touches production data.

When agentic AI enters regulated or high-risk workflows, teams should align their control model to the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework rather than relying on traditional software acceptance alone. That shift gives security, IAM, and platform teams a common language for tool abuse, runtime trust, and accountability.

For practitioners

• 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.
• Document every allowlist exception with ownership and rationale Require a human-readable justification for every suppressed finding, plus a named owner who can revisit the exception when the upstream package, skill, or scanner behaviour changes.

Key takeaways

• MCP servers are becoming identity-bearing assets, which means packaging and attestation now sit inside the governance model.
• The biggest risk is not just untrusted code, but untrusted tool behaviour that can inherit access inside an agent workflow.
• Practitioners need admission controls, live scanning, and enforceable attestations before MCP tools are allowed into production.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Artifact Attestation: Evidence that a build output was produced by a trusted process and has not been altered before execution. It is a practical control for software and AI supply chains because it helps separate approved runtime inputs from files that merely look legitimate.

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

👉 Stacklok's full post covers the build pipeline, scanner gates, and attestation workflow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.