25 October 2026. Safeguard.sh Inc today published its remote Model Context Protocol (MCP) server in the official MCP Registry, the open catalog of MCP servers maintained by the Model Context Protocol project. The listing is named sh.safeguard/safeguard and points to Safeguard's hosted endpoint at https://mcp.safeguard.sh/mcp.
The registry checks that a publisher controls the namespace in a server's name. Safeguard verified its listing through a DNS record on safeguard.sh, so the sh.safeguard prefix shows that the listing comes from Safeguard itself and not from a third party using a similar name.
What the listing gives AI assistants
MCP is the open protocol that lets AI assistants and agents call tools and read data from other systems. Safeguard ships its own remote MCP server, so a team can connect an assistant directly to its software supply chain security data and ask questions in plain language.
Once connected and signed in, an assistant can:
- query the vulnerabilities, SBOMs, packages, licenses and findings in a Safeguard account;
- read compliance data;
- generate AI remediation plans and compare SBOMs;
- work with policy gates and SCM integrations.
Which tools an assistant can use is governed per tenant. A curated set is enabled by default, and administrators enable more for each workspace. The endpoint requires a Safeguard sign-in, so the listing does not expose any customer data.
Why a registry listing matters
AI clients and MCP directories increasingly read the official registry to discover servers. A verified listing means:
- teams can find Safeguard's server where they already look for MCP servers;
- security reviewers can confirm that the server name, the publisher's domain and the endpoint belong together before they approve a connection.
How to connect
- Claude users: add Safeguard from Claude's connector directory. Step by step instructions are at docs.safeguard.sh/docs/mcp/claude.
- Other assistants: guides for ChatGPT, Le Chat, Microsoft Copilot and others are at docs.safeguard.sh/docs/mcp. Each uses an endpoint on the mcp.safeguard.sh host.
- Registry entry: see the listing at registry.modelcontextprotocol.io, or read version 1.0.0 through the registry API.
For a step by step guide to checking the listing and connecting an assistant, read Find and connect Safeguard from the official MCP Registry.
Availability
The Safeguard MCP server is generally available to Safeguard customers today. The registry listing is live as of 25 October 2026.
About Safeguard
Safeguard.sh Inc builds software supply chain security tools, including:
- SBOM generation and analysis;
- vulnerability management;
- autonomous remediation;
- policies and gates;
- Gold components.
Learn more at safeguard.sh.
Media contact: press@safeguard.sh
An assistant connected through the registry listing can also help with the step most teams find slowest: getting the fix into production. Here is how Safeguard approaches that.
Fix it without waiting for upstream
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.
3. Gold Registry: start from components that are already fixed
Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | Safeguard policies and gates in CI |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
