Securing the Docker MCP Catalog: Commit Pinning, Agentic Auditing, and Publisher Trust Levels

Ensuring trust is paramount when integrating AI assistants with real-world tools. While Model Context Protocol (MCP) containerization offers robust isolation against malfunctioning or compromised servers, Docker is consistently enhancing the security and trustworthiness of its MCP solutions. As the MCP ecosystem expands exponentially, robust mechanisms are essential to verify code execution, build provenance, and overall trustworthiness.

To strengthen trust across the entire MCP lifecycle—from submission to maintenance to daily use—Docker has introduced three key enhancements:

• Commit Pinning: Every Docker-built MCP server in the Docker MCP Registry (the authoritative source for the MCP Catalog) is now linked to a specific Git commit. This makes each release precisely attributable and verifiable.
• Automated, AI-Audited Updates: A new update workflow ensures submitted MCP servers remain current. Agentic reviews of incoming changes provide scalable and traceable vigilance.
• Publisher Trust Levels: Clearer trust indicators have been introduced in the MCP Catalog, enabling developers to easily distinguish between official, verified servers and community-contributed entries.

These updates significantly raise the bar for transparency and security for all users and builders leveraging MCP at scale with Docker.

Commit Pins for MCP Servers

Local MCP servers within the Docker MCP Registry are now explicitly tied to a specific Git commit via source.commit. This commit hash acts as a cryptographic fingerprint for the exact revision of the server code that Docker builds and publishes. Without this pinning, references like latest or branch names would build whatever is current at that reference, leading to non-deterministic builds and potential vulnerability to supply chain attacks if an upstream repository is compromised. Even Git tags are not truly immutable as they can be deleted and recreated to point to different commits. In contrast, commit hashes are cryptographically linked to their content, ensuring that an audit result for that commit remains persistent.

To streamline this process, Docker has updated its authoring tools, such as the MCP Registry Wizard, to automatically add the commit pin when creating new server entries. Furthermore, the CI pipeline now enforces the presence of a commit pin; missing or malformed pins will fail validation. This deliberate enforcement ensures that no server can be accidentally published without clear provenance for the distributed code. The pin is also propagated into the MCP server image metadata via the org.opencontainers.image.revision label for enhanced traceability.

Here’s an example of what this looks like in the registry:

# servers/aws-cdk-mcp-server/server.yaml
name: aws-cdk-mcp-server
image: mcp/aws-cdk-mcp-server
type: server
meta:
  category: devops
  tags:
    - aws-cdk-mcp-server
    - devops
about:
  title: AWS CDK
  description: AWS Cloud Development Kit (CDK) best practices, infrastructure as code patterns, and security compliance with CDK Nag.
source:
  project: https://github.com/awslabs/mcp
  commit: 7bace1f81455088b6690a44e99cabb602259ddf7
  directory: src/cdk-mcp-server

And here’s an example of how you can verify the commit pin for a published MCP server image:

$ docker image inspect mcp/aws-core-mcp-server:latest \
    --format '{{index .Config.Labels "org.opencontainers.image.revision"}}'
7bace1f81455088b6690a44e99cabb602259ddf7

If cosign and jq commands are available, additional verifications can be performed:

$ COSIGN_REPOSITORY=mcp/signatures cosign verify mcp/aws-cdk-mcp-server --key https://raw.githubusercontent.com/docker/keyring/refs/heads/main/public/mcp/latest.pub | jq -r ' .[].optional["org.opencontainers.image.revision"] '

Verification for index.docker.io/mcp/aws-cdk-mcp-server:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key
7bace1f81455088b6690a44e99cabb602259ddf7

Keeping Servers in Sync

Once a server is in the registry, maintainers should not need to manually edit pins with every merge into their upstream repositories. A new automated workflow addresses this by scanning upstream repositories nightly, updating source.commit when a newer revision is found, and opening an auditable Pull Request (PR) in the registry to track the incoming upstream changes. This provides the security benefits of pinning (immutable references to reviewed code) without the maintenance overhead. Updates still flow through pull requests, maintaining a review gate and approval trail that clearly shows what new code is entering the supply chain. This update workflow operates on a per-server basis, with each server update receiving its own branch and pull request.

This naturally leads to the question: how can we be sure that the incoming changes are safe?

AI in the Review Loop, Humans in Charge

Every proposed commit pin update (and any new local server submission) is now subject to an agentic AI security review of incoming upstream changes. Reviewers, such as Claude Code and OpenAI Codex, analyze MCP server behavior, identifying risky or malicious code. They add structured reports to the PR and apply standardized labels like security-risk:high or security-blocked. Humans retain final judgment, but these agents offer relentless and scalable vigilance.

The Challenge: Untrusted Code Means Untrusted Agents

Running AI agents in CI to analyze untrusted code presents a fundamental problem: the agents themselves can become attack vectors. They are susceptible to prompt injection through carefully crafted code comments, filenames, or repository structures. A malicious PR could attempt to manipulate the reviewing agent into approving dangerous changes, exfiltrating secrets, or altering the review process itself.

Consequently, while the code under review cannot be fully trusted, neither can the agents reviewing it.

Isolated Agents

Docker's Compose-based security reviewer architecture tackles this trust challenge by treating AI agents as untrusted components. These agents operate within heavily isolated Docker containers with strictly controlled inputs and outputs:

• Read-only code mounting: The code being audited is mounted read-only, preventing the agent from modifying it. This temporary copy of the upstream repository also ensures the agent cannot modify scripts that might be accidentally executed outside the container.
• Isolated output directory: The agent can only write to a specific, isolated output directory. A CLI wrapper then extracts only predefined files (a Markdown report and a text file of labels, both with fixed names), ensuring any malicious scripts or files written to that directory are deleted.
• No direct Internet access: The reviewer container is isolated from external services.
• CI secrets and API credentials isolation: Critical secrets and API keys never enter the reviewer container. Instead, a lightweight reverse proxy on a separate Docker network accepts requests from the reviewer, injects inference provider API keys for outbound requests, and shields these keys from the containerized code under review.

This entire system is encapsulated in a Docker Compose stack and wrapped by a convenient CLI, allowing the agent to run both locally and within CI environments.

Crucially, this architecture ensures that even if a malicious PR successfully manipulates an agent through prompt injection, the damage is contained: the agent cannot access secrets, modify code, or communicate with external attackers.

CI Integration and GitHub Checks

The review workflow is automatically triggered when a PR is opened or updated. For external PRs, manual triggering is required to prevent malicious PRs from consuming excessive inference API credits. These reviews are surfaced directly as GitHub Status Checks, with each reviewed server receiving dedicated status checks for any analyses performed.

The resulting check status corresponds to the risk level determined by the agent: critical findings lead to a failed check that blocks merging, high and medium findings produce neutral warnings, while low and info findings pass. While these criteria are still being refined (as agents are configured to be highly pedantic), and reports are currently reviewed manually, the goal is to fine-tune heuristics for eventual auto-approval and merging of most updated PRs. In the interim, these reports act as a scalable "canary in the coal mine," alerting Docker MCP Registry maintainers to both malicious and accidental upstream risks.

It is important to note that the agent code in the MCP Registry repository is a functional example (available under an MIT License). The actual security review agent used by Docker resides in a private repository with additional isolation, but adheres to the same architectural principles.

Reports and Risk Labels

Here’s an example of a report produced by the automated reviewers:

# Security Review Report

## Scope Summary
- **Review Mode:** Differential
- **Repository:** /workspace/input/repository (stripe)
- **Head Commit:** 4eb0089a690cb60c7a30c159bd879ce5c04dd2b8
- **Base Commit:** f495421c400748b65a05751806cb20293c764233
- **Commit Range:** f495421c400748b65a05751806cb20293c764233...4eb0088a690cb60c7a30c159bd879ce5c04dd2b8
- **Overall Risk Level:** MEDIUM

## Executive Summary

This differential review covers 23 commits introducing significant changes to the Stripe Agent Toolkit repository, including: folder restructuring (moving tools to a tools/ directory), removal of evaluation code, addition of new LLM metering and provider packages, security dependency updates, and GitHub Actions workflow permission hardening.

...

The reviewers can perform both differential analyses (examining changes introduced by a specific set of upstream commits) and full analyses (reviewing entire codebases). The intention is to run differential analyses for PRs and full analyses regularly.

Why Behavioral Analysis Matters

Traditional scanners are crucial, but they typically focus on vulnerabilities like CVEs in dependencies, syntactical errors (e.g., a missing break in a switch statement), or memory safety issues (e.g., dereferencing an uninitialized pointer). MCP, however, necessitates an examination of code's behavior. The recent malicious postmark-mcp package impersonation, where a single line of backdoor code quietly BCC'd outgoing emails to an attacker, underscores why the Docker registry combines provenance with behavior-aware reviews before shipping updates.

Real-World Results

Early scans have already uncovered several real-world issues in upstream projects, affecting both MCP servers and a similar agent in Docker's Hardened Images pipeline. Fortunately, no malicious code has been found yet, only logic errors with security implications. The granularity and subtlety of issues identifiable by these agents are impressive.

Trust Levels in the Docker MCP Catalog

Beyond the technical changes, Docker has also introduced publisher trust levels within the Docker MCP Catalog, making them visible in both the Docker MCP Toolkit in Docker Desktop and on Docker MCP Hub. Each server now features an icon indicating whether it originates from a "known publisher" or is maintained by the community. While all code is still subject to review, these indicators provide additional context regarding the MCP server's origin.

Figure 1: An example of an MCP server (AWS Terraform MCP) published by a known, trusted publisher.

Figure 2: The Fetch MCP server, an example of an MCP community server.

Impact on the Community

Publishers now benefit from a steady stream of upstream improvements, backed by a documented, auditable trail of code changes. Commit pins ensure each release is precisely attributable, while the nightly updater keeps the catalog current without additional effort from publishers or maintainers. AI-powered reviewers scale vigilance, allowing human reviewers to concentrate on critical edge cases.

Simultaneously, developers using MCP servers gain clarity about a server’s publisher, making it easier to distinguish between official, community, and third-party contributions. These enhancements collectively strengthen trust and security for everyone contributing to or relying on MCP servers within the Docker ecosystem.