Verify Safeguard in the Official MCP Registry, Then Connect It

Safeguard's remote MCP server is listed in the official MCP Registry as sh.safeguard/safeguard, version 1.0.0, pointing at https://mcp.safeguard.sh/mcp over Streamable HTTP. The sh.safeguard prefix was verified through a DNS record on safeguard.sh, so the listing provably comes from the owner of that domain. Check the name, the domain, the URL, the transport and the version against this post and Safeguard's docs, then connect Claude from its connector directory and sign in.

This post is for the AI platform owner asked to "add Safeguard to our assistant" and for the security reviewer who has to approve that connection. Both need an accurate picture of what the registry checks, a repeatable way to verify a listing, and a connection flow that gives the assistant no more access than intended.

Key takeaways

• The MCP Registry is a metadata catalog, not an app store. It stores a server.json record per server version and checks one thing at publish time: that the publisher controls the namespace in the server's name. It does not scan server code and its moderation is minimal by its own description.
• Namespaces are reverse DNS. sh.safeguard/safeguard can only be published by someone who proved control of safeguard.sh, through a TXT record at the domain apex or a file under /.well-known/ on the domain. GitHub logins can only publish under io.github.<name>/.
• The registry does not verify the remote URL. A domain namespace proves who published the record, not who runs the endpoint it points to. You still compare the URL with the publisher's own documentation.
• Safeguard's listing is verifiable from your terminal. One registry API call, one DNS lookup and two OAuth discovery requests confirm the publisher, the endpoint and the sign-in model. Every command and output in this post was run on 25 October 2026.
• Connect Claude from its connector directory first. Safeguard is listed there; you select it, sign in to Safeguard and click Authorize access. Other assistants follow per-assistant guides on docs.safeguard.sh.
• Maturity labels for everything covered here: Safeguard MCP server (GA), per-tenant MCP tool gating (GA, part of the MCP server), OAuth sign-in and MCP keys (GA), Claude connector directory listing (GA), agent identity (GA), Safeguard MCP Guardrail, which the docs call Guard (GA), policies and gates (GA), the Safeguard CLI (GA), autonomous remediation (GA, ships switched off), Gold Open Source (GA, free).

What the official MCP Registry is, and what it is not

The Model Context Protocol (MCP) is the open protocol that lets an AI assistant call tools and read data in other systems. As the number of MCP servers grew, finding them became a problem: servers were announced in blog posts, README files and community lists, with no shared format and no way to tell an official server from a copy. The MCP Registry is the project's answer.

According to the registry's own About page, it is the official centralized metadata repository for publicly accessible MCP servers. It provides a single place for server creators to publish metadata, namespace management through DNS verification, a REST API for clients and aggregators, and standardized installation and configuration information. Each record follows the server.json format: a unique name, where to find the server (a package or a remote URL), how to run it, and discovery data such as a description.

Four properties matter for anyone reviewing a listing.

It holds metadata, not code. For a server distributed as a package, the registry record points to that package on a package registry. For a remote server like Safeguard's, the record points to a URL. The registry never hosts the server itself.

It is built for aggregators. The docs say the registry is intended to be consumed primarily by downstream aggregators such as MCP server marketplaces, which pull new metadata on a regular but infrequent basis (the docs give once per hour as an example). Host applications are expected to read from those downstream catalogs, through an API that follows the registry's OpenAPI specification, rather than read the official registry directly. So the place your assistant shows you a server may be one or two steps removed from the official record.

It does not scan servers. The About page says security scanning is delegated to the underlying package registries and to downstream aggregators. The registry itself focuses on namespace authentication and metadata hosting.

Its moderation is light by design. The moderation policy says consumers should assume minimal to no moderation. The maintainers remove a short list of things, such as illegal content, spam and non-functioning servers. They do not remove low quality or buggy servers, servers with security vulnerabilities, or servers that duplicate other servers. A removed server gets a status of deleted, and its metadata stays readable through the API.

One more caveat applies to everything in this post: the registry is not yet generally available. Its documentation warns that breaking changes or data resets may happen before it is. Treat the API paths shown below as correct on 25 October 2026 and check the registry docs if one stops working.

So a registry listing is strong evidence about who published a record and no evidence about whether the server is safe to connect. The rest of this post covers both questions.

How reverse-DNS namespaces and verification work

Every server name in the registry has two parts separated by a slash: a namespace, then a server name. The namespace is written in reverse DNS order, so the domain safeguard.sh becomes sh.safeguard, and a server called safeguard under it becomes sh.safeguard/safeguard.

The registry's Authentication guide says the method a publisher uses to log in decides which namespaces they may publish under. There are three methods.

GitHub-based names

A GitHub login always grants the personal namespace io.github.<your-username>/*. Publishing under an organization namespace requires the Owner role in that organization; ordinary membership is not enough. For a reviewer, the point is simple. An io.github. name tells you which GitHub account or organization published the record. It says nothing about any company domain.

DNS verification

DNS verification is the method Safeguard used. The publisher generates a key pair, publishes the public key in a TXT record at the apex of the domain, and then logs in to the registry by signing a challenge with the private key. The registry looks up the TXT record and checks the signature.

The record has a fixed shape:

example.com. IN TXT "v=MCPv1; k=ed25519; p=<base64 public key>"

v=MCPv1 marks it as an MCP registry proof. k= names the algorithm; the docs support Ed25519 and ECDSA P-384, and show the same flow with keys held in cloud key management services. p= is the public key.

Three details from the docs are worth knowing because they explain most failures and most confusion:

• The record must sit at the apex. It goes on example.com itself, not under a selector such as _mcp-auth.example.com. The registry recognises the common wrong selectors and returns a specific error when it finds a record there.
• Several keys can be published. The registry tries all valid MCPv1 records on the domain, so a second key does not block the right one. The docs still advise removing retired keys, and warn that a stale record can cause verification to fail after a key rotation.
• Verification happens at login. The proof is checked when the publisher logs in to publish. That is why the record is still visible on safeguard.sh today, and also why you should not treat its presence or absence on a later day as the whole story.

HTTP verification

HTTP verification proves the same thing through the web server instead of DNS. The publisher hosts the same v=MCPv1; k=...; p=... proof record as plain text at https://<domain>/.well-known/mcp-registry-auth. The registry fetches it from its own cloud infrastructure with a plain HTTPS GET, a 10 second timeout and no redirect following, so the file has to be reachable from the public internet exactly at that path.

What verification proves, and what it does not

The Remote Servers guide is direct about the limit. When you publish, the registry verifies that you control the namespace in the server name. It does not verify that you control the remote URL, whatever authentication method you used. A server named com.example/weather proves control of example.com, but the registry does not check that its remote URL is on example.com.

The registry adds one safeguard here: each remote URL can be used by only one server name, so publishing fails if another server already uses the same URL. That stops two records from claiming the exact same endpoint. It does not stop a record from pointing at an endpoint on someone else's domain.

The guide's own advice to publishers is to use DNS or HTTP authentication when the remote URL is on a domain they control, so that users can see the server name and the remote URL belong to the same publisher. That is the check you, as a reviewer, should make: does the namespace's domain match the endpoint's domain?

Why a reviewer has to check before approving a connection

A connection between an assistant and an MCP server is a delegation of authority. After you approve it, the assistant can call whatever tools the server exposes, as you, with whatever access your account has on the other side. Getting the server wrong has real cost.

There are three ways it commonly goes wrong.

Look-alike names. A keyword search in any catalog returns everything whose name or description contains the word. When we searched the official registry for "safeguard" on 25 October 2026, it returned two servers. One was Safeguard's. The other was an unrelated, package-based server published under a different company's namespace that happens to use the same word. Nothing about that is improper, and the registry does not remove servers that resemble others. But an approver skimming a list could pick the wrong one. The namespace is how you tell them apart.

Packages that claim to be a hosted server. Some vendors run their MCP server as a hosted endpoint and never publish a package. If a package claiming to be that vendor's server shows up on a package registry, it did not come from the vendor. Safeguard's docs say this plainly: Safeguard does not publish an npm package or a local bridge for its MCP server, and you should treat any package that claims to be the Safeguard MCP server as untrusted. The docs add that the server never reads environment variables such as SAFEGUARD_API_KEY from your machine, and that instructions which set that variable or start a local bridge with npx are out of date.

Over-broad tool access. Even the right server can expose more than you intended if every tool is visible from the first connection. The server side has to offer a way to start narrow.

The MCP specification gives reviewers a baseline for the sign-in part. Its authorization section (revision 2025-11-25) says MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so that clients can discover the authorization server; that clients must implement PKCE and use the S256 code challenge method when technically capable; that clients must include the resource parameter so tokens are bound to the intended server; and that servers must validate that access tokens were issued specifically for them. It also points to the specification's security guidance on why token passthrough is forbidden. You do not need to audit a vendor's implementation line by line, but you can check that the public discovery documents exist and say what the specification expects. Step 6 below shows how.

Safeguard's listing, field by field

Safeguard published sh.safeguard/safeguard to the official registry on 25 October 2026. The registry API returns this record for version 1.0.0 (formatted for reading; we did not change any value):

{
  "server": {
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
    "name": "sh.safeguard/safeguard",
    "description": "Software supply chain security: SBOMs, vulnerabilities, fixes, policies and compliance data.",
    "title": "Safeguard",
    "version": "1.0.0",
    "websiteUrl": "https://safeguard.sh",
    "remotes": [
      {
        "type": "streamable-http",
        "url": "https://mcp.safeguard.sh/mcp"
      }
    ]
  },
  "_meta": {
    "io.modelcontextprotocol.registry/official": {
      "status": "active",
      "statusChangedAt": "2026-10-25T16:12:54.624579Z",
      "publishedAt": "2026-10-25T16:12:54.624579Z",
      "updatedAt": "2026-10-25T16:12:54.624579Z",
      "isLatest": true
    }
  }
}

Here is what each field tells you and what to compare it with.

The registry's Versioning guide adds context for the version field. A version string must be unique for each publication, and once published the version and its metadata cannot be changed. The registry marks a version as latest by semantic version order when it can parse the string. For a reviewer, that means approving "sh.safeguard/safeguard 1.0.0" is approving a fixed record. If the publisher later changes the endpoint, that is a new version you can see and review.

Step by step: verify the publisher before you approve

You can run all of the following from a laptop with curl, dig and python3. Nothing here needs a Safeguard account or any credentials. We ran each command on 25 October 2026 and show what came back.

1. Fetch the exact version from the registry API. The registry's aggregator guide documents three read endpoints: list all servers, list a server's versions, and get one version (with latest as a special version). Path parameters must be URL-encoded, so the slash in the name becomes %2F.

   curl -s "https://registry.modelcontextprotocol.io/v0.1/servers/sh.safeguard%2Fsafeguard/versions/1.0.0"
   

   The response is the JSON record shown above. To see every version Safeguard has published, call the versions endpoint instead:

   curl -s "https://registry.modelcontextprotocol.io/v0.1/servers/sh.safeguard%2Fsafeguard/versions"
   

   On 25 October 2026 that returned one server entry, version 1.0.0, with "metadata":{"count":1}.

2. Check the namespace, not the title. The title field is free text and any publisher can set it to "Safeguard". The name field is what the registry verified. Reverse its namespace: sh.safeguard reads as safeguard.sh. If you started from a keyword search, this is the step that separates the vendor's own record from unrelated servers that share a word:

   curl -s "https://registry.modelcontextprotocol.io/v0.1/servers?search=safeguard"
   

   Read the name of every result. Only the one under sh.safeguard/ was published by the owner of safeguard.sh.

3. Confirm the domain proof is published. Look up TXT records at the apex of safeguard.sh and filter for the MCP proof:

   dig TXT safeguard.sh +short | grep MCPv1
   

   Through a public resolver on 25 October 2026 this returned a record of the form:

   "v=MCPv1; k=ed25519; p=x8zc8Mfb1X65XMIygy9U/J3AbKq93yrR5670q26r60A="
   

   One practical note: our first lookup through a local resolver did not show the record, because the resolver had cached the domain's TXT set from before it was added. A query through a public resolver showed it. If you see nothing, try dig @1.1.1.1 TXT safeguard.sh +short or wait for the cache to expire before drawing a conclusion. And remember from the section above that the registry checks the proof when the publisher logs in; the registry record itself is the primary evidence, and the TXT record is corroboration.

4. Compare the remote URL with the vendor's own documentation. The registry does not check URL ownership, so this comparison is yours. Safeguard's MCP overview page at docs.safeguard.sh/docs/mcp says Safeguard hosts the MCP server at https://mcp.safeguard.sh/mcp, and that every per-assistant guide uses an endpoint on the mcp.safeguard.sh host. The listing's URL matches, and its host is a subdomain of the namespace's domain. Both conditions should hold for any server you approve.

   You will notice that the Claude guide uses a different path, https://mcp.safeguard.sh/mcp/anthropic, described as an endpoint built for Claude. Same host, same publisher. The registry allows each remote URL to be claimed by only one server name, and Safeguard's registry record lists the general endpoint.

5. Check transport, packages and status. The transport is streamable-http, which the registry guide recommends for remote servers. There is no packages array, which matches the docs' statement that no package exists. The status is active. If any of these differ from what you expect when you run the check, stop and ask the vendor.

6. Check the sign-in model from the public discovery documents. An MCP server that uses OAuth should answer an unauthenticated request with a 401 and point the client at its protected resource metadata, as RFC 9728 and the MCP authorization section describe. Send an empty POST and print only the response headers:

   curl -s -D - -o /dev/null -X POST -H 'Content-Type: application/json' -d '{}' https://mcp.safeguard.sh/mcp
   

   The relevant lines that came back:

   HTTP/1.1 401 Unauthorized
   Www-Authenticate: Bearer realm="https://mcp.safeguard.sh", resource_metadata="https://mcp.safeguard.sh/.well-known/oauth-protected-resource/mcp"
   

   Then fetch the protected resource metadata:

   curl -s https://mcp.safeguard.sh/.well-known/oauth-protected-resource/mcp
   

   {"resource":"https://mcp.safeguard.sh/mcp","authorization_servers":["https://mcp.safeguard.sh"],"bearer_methods_supported":["header"],"scopes_supported":["openid","profile","email"],"resource_documentation":"https://docs.safeguard.sh/docs/mcp"}
   

   And the authorization server metadata it names:

   curl -s https://mcp.safeguard.sh/.well-known/oauth-authorization-server
   

   The fields a reviewer cares about, from the response on 25 October 2026:

   {
     "issuer": "https://mcp.safeguard.sh",
     "registration_endpoint": "https://mcp.safeguard.sh/register",
     "response_types_supported": ["code"],
     "grant_types_supported": ["authorization_code", "refresh_token"],
     "code_challenge_methods_supported": ["S256"]
   }
   

   Read it this way. The protected resource names itself as https://mcp.safeguard.sh/mcp, which matches the registry URL. The authorization server is on the same host. PKCE with S256 is the only code challenge method offered, which is what the MCP specification asks clients to use. A registration_endpoint is present, which means clients can register themselves (OAuth 2.0 Dynamic Client Registration, RFC 7591) instead of you copying a client ID by hand. The resource_documentation link points back to Safeguard's docs, closing the loop.

7. Reject anything that asks you to install a package. If a setup guide for "the Safeguard MCP server" tells you to run npx, install an npm package, or set SAFEGUARD_API_KEY in your environment, it is either out of date or not from Safeguard. The docs say so in those words. A hosted server needs only its URL and a sign-in.

8. Record what you approved. Write down the server name, the version, the remote URL, the date you checked, and the client you approved it for. When a new version appears in the registry, you have a baseline to compare against.

None of these steps tells you whether the server is well built. They tell you that the record, the domain, the endpoint and the sign-in flow belong to the same publisher. Whether to trust that publisher with your data is the separate decision your vendor review exists to make.

Step by step: connect your assistant to Safeguard

With the publisher verified, connecting is short. You need a Safeguard account first; create one or sign in at app.safeguard.sh.

Claude: add Safeguard from the connector directory

Safeguard's MCP server (GA) is listed in Claude's connector directory. Safeguard's Claude guide calls this the shortest route, because there is no URL to paste.

1. Sign in to claude.ai. The directory lives inside Claude. The docs note that opening the directory link without a Claude session lands you on the Claude home page instead.
2. Open the Safeguard entry in Claude's connector directory.
3. Select Safeguard and connect.
4. Sign in to Safeguard when Claude sends you there. Before you click anything, read the sign-in page. The docs tell you to check two things: the app name, and the host the page says the authorization code will be sent to. This is the moment that catches a redirect to somewhere you did not expect.
5. Click Authorize access. Claude now has the Safeguard tools your workspace has enabled.
6. Ask a first question. The docs' starter prompts work in any assistant: "List my security projects", "Find critical vulnerabilities", "Show me all SBOMs", "Generate a remediation plan for my npm project", "Which packages violate my license policy?"

Two notes from the docs for administrators. On Claude Team and Enterprise plans, an Owner or Primary Owner adds the connector for the organization first, and members then connect it from their own connector settings. And Claude Desktop uses the connectors in your Claude account, so once Safeguard is connected on the web it is available in Desktop too. The docs say not to add Safeguard to claude_desktop_config.json, because that file is for local servers and Safeguard's server is hosted.

If the directory is not available on your Claude plan or in your workspace, Safeguard's Claude guide documents a manual route that always works. We cover it, along with the ChatGPT routes and the IDE extension, in Safeguard in your IDE and in the Claude and ChatGPT connector directories, so we will not repeat it here.

Other assistants

Safeguard's MCP overview links a guide for each supported assistant. Every guide uses an endpoint on the mcp.safeguard.sh host and the same sign-in page.

The docs recommend OAuth wherever a client supports it, and name Claude, ChatGPT, Cursor, VS Code and Gemini CLI as clients that sign in that way. The alternative is an MCP key, meant only for a client that can send nothing but a fixed Authorization header. A Safeguard user creates one under Settings, Developer, choosing the key type MCP key; it is shown once. The docs add three facts an approver should know about keys:

• An MCP key acts as the member who created it, across the whole workspace. Give it only to a client you trust and keep it out of source control.
• Revocation takes effect within a minute. The server rechecks each key at least once a minute, so a revoked key, a key whose owner's account is closed, or a key in a workspace whose API-key access is turned off stops working quickly.

What the assistant can see and do once connected

Verification answers "is this the right server". This section answers "what did I just allow".

It acts as you, inside your role

The docs state that whichever way you authenticate, the assistant acts as you. It can see and do only what your Safeguard role allows, within the tools your workspace has turned on. It does not get a separate, broader service identity. Safeguard's agent identity capability (GA) is designed to track which agent holds what access, at what level, which is the record a reviewer wants when several assistants and agents are connected over time.

It starts with a small, read-only tool set

Safeguard's MCP server registers hundreds of tools covering vulnerability management, SBOM analysis, findings, compliance, remediation planning, SCM integration and policy gates. A new workspace does not expose them all. Per the tool availability and gating page, a new workspace starts with a small default set in which every tool is a read: listing products, listing and reading projects, listing vulnerabilities, reading one CVE, and listing findings. Nothing in that set can create, change or delete anything, or handle a credential, so a client can approve the whole set at once.

Every other tool, including the ones that add an integration or start a scan, ships disabled. A Safeguard administrator enables tools one by one for the tenant. Each tool has its own feature flag of the form mcp:tool:<tool_name>, and the docs describe the design as least privilege by default: start narrow and widen access deliberately as you build trust in each capability.

In practice, with the default tools the assistant reads results that already exist in the tenant. It cannot start a scan, change a finding's triage state, open a ticket or raise a fix pull request; those actions live in the Safeguard web app, CLI and CI integration unless an administrator enables the matching tools.

Discovery and execution are gated from the same source

The gating page explains that when an assistant connects, the server resolves the set of tools enabled for the tenant and uses that one set for both tools/list (what the assistant is told exists) and tools/call (what it may run). An assistant can never see a tool it cannot call, or call a tool it cannot see. A disabled tool does not appear in the list at all.

If an assistant does try to call a tool your tenant has not enabled, the server returns a normal tool result with an error flag, not a broken connection. The docs show this example:

{
  "content": [
    {
      "type": "text",
      "text": "Tool \"safeguard_scan_manifest\" is not enabled for this tenant. An administrator can enable it via MCP tool feature flags."
    }
  ],
  "isError": true
}

It fails closed

If tool resolution cannot complete, for example during a transient outage, the server falls back to the small default set rather than exposing anything wider; the docs call this "fail safe, never fail open". Changes to the enabled set are rechecked on the order of a minute, but many MCP clients cache the tool list per session, so reconnect the assistant after a change.

Beyond Safeguard's own server: MCP Guardrail for any MCP server

Tool gating governs Safeguard's own MCP tools. Most teams connect assistants to more than one MCP server, and some build their own. Safeguard MCP Guardrail (GA), which the docs call Guard, applies live policy to MCP traffic in general.

The docs describe the Guard proxy as a reverse proxy gateway you run in front of one or more MCP servers, including ones whose code you do not control. You register the upstream server with Guard, create a proxy URL bound to that server (and optionally to one agent and one policy), and point your agent's MCP client at the proxy URL instead of the upstream server. Guard evaluates every JSON-RPC call against your Safeguard policy before forwarding allowed calls, and blocked requests never reach the upstream server.

Guard policies are authored in your Safeguard workspace, not in files in a repository. Each rule matches on method, tool name (glob wildcards allowed) or agent ID, and resolves to allow, deny or monitor, evaluated in priority order where the first match wins. Rules can also carry input filters (block a pattern, cap request size, catch jailbreak phrasing) and output filters (mask personal data in responses, redact fields, cap row counts). Guard writes an append-only audit trail for every request it evaluates, allowed, denied or monitored, and supports alert rules and signed webhooks.

The docs are explicit that tool gating and Guard are independent. Turning off a Safeguard tool under feature flags does not create a Guard policy, and a Guard policy does not change Safeguard's feature flags. The docs also say that most teams only need Guard once they build or operate MCP servers or agents of their own; connecting an assistant to Safeguard alone does not require it.

The MCP overview also says no Guard SDK package is published on PyPI, npm or the Go module proxy today, so any package claiming to be it did not come from Safeguard. The proxy is the route available now.

For the full walkthrough of creating a guardrail, routing a client through it and rolling out in monitor mode before enforcing, see Put a policy proxy in front of MCP servers with Safeguard MCP Guardrail.

Decision table: what each signal proves

Use this when you review any MCP listing, not only Safeguard's.

Requirement vs what Safeguard does vs what you still own

What Safeguard does not do

• It does not vet other publishers' MCP servers for you. The registry checks namespaces and Safeguard's MCP server is about your own supply chain data. Neither tells you whether a third-party MCP server is safe. MCP Guardrail can put policy in front of a server; it does not certify one.
• It does not control which servers your assistant can discover. Catalogs inside Claude, ChatGPT and other clients come from those vendors and their aggregators. Safeguard has no say over what they list or how they rank it.
• It does not expose every tool by default, and the default tools only read. With the default set, an assistant cannot start scans, change triage states, open tickets or raise fix pull requests. Those need an administrator to enable the matching tools, or happen in the web app, CLI and CI.
• Tool gating is per tenant, not per user. Everyone in the same tenant and context sees the same enabled tools. Per-agent rules are a Guard policy, which you configure and operate.
• It does not publish a package, bridge or SDK you can install for the MCP server. If you find one, it is not from Safeguard. The Guard SDK described in the docs is not published to any package registry today.
• It does not change your assistant's own controls. Plan limits, workspace policies on custom connectors, and per-tool approval prompts inside the assistant are set by the assistant's vendor and your administrators.
• It does not guarantee the registry's availability. The registry's own docs say it provides no uptime or data durability guarantees and is not yet generally available. Your approval record should not depend on the registry being reachable later.

Common mistakes

Choosing by title. The title field is free text. Two different servers can both call themselves the same thing. Always choose by name, and read the namespace.

Assuming a verified namespace means a verified endpoint. The registry docs say plainly that URL ownership is not checked. Compare the URL with the vendor's docs every time.

Installing a package for a hosted server. If the vendor's docs say the server is hosted, any package claiming to be it is untrusted. For Safeguard this is in the docs in plain words.

Putting a hosted server in a local config file. Adding Safeguard to claude_desktop_config.json is the wrong route; that file is for local servers. Connect through the Claude account instead and Desktop picks it up.

Clicking Authorize access without reading the page. The sign-in page shows the app name and the host the authorization code will go to. Those two lines are the last chance to catch a misdirected flow.

Reaching for an MCP key when OAuth works. A key acts as its creator across the whole workspace and has to be stored somewhere. OAuth needs nothing copied. Use keys only for clients that cannot do OAuth.

Enabling every tool on day one. The default set is small for a reason. Add tools as a specific need appears, and record why.

Reading a missing TXT record as a failed verification. Resolvers cache. We saw a stale answer from one resolver and the correct one from a public resolver minutes apart. And the registry checked the proof at publish time; the record in the registry is the primary evidence.

FAQ

Is Safeguard in the official MCP Registry?

Yes. It is listed as sh.safeguard/safeguard, version 1.0.0, published on 25 October 2026 with status active. The record points to https://mcp.safeguard.sh/mcp over Streamable HTTP and was verified by DNS on safeguard.sh.

How do I know the listing is really from Safeguard?

The sh.safeguard namespace can only be published by someone who controls safeguard.sh. The registry checked that through a signed DNS proof when the record was published, and the proof record is visible in safeguard.sh's TXT records. Then confirm the URL matches docs.safeguard.sh/docs/mcp.

Does the MCP Registry scan servers for security problems?

No. Its docs say security scanning is delegated to package registries and downstream aggregators, and its moderation policy says to assume minimal to no moderation. It removes a short list of things such as spam, illegal content and broken servers, but not servers with vulnerabilities.

Do I need to install anything to use the Safeguard MCP server?

No. The server is hosted. Safeguard publishes no npm package, local bridge or environment variable setup for it, and the docs say to treat any package claiming to be the Safeguard MCP server as untrusted.

What can my assistant do with Safeguard after I connect it?

It acts as you, within your Safeguard role. A new workspace exposes a small set of read-only tools for products, projects, vulnerabilities and findings. A Safeguard administrator can enable more tools one at a time, such as scanning, remediation planning, SBOM comparison and policy gate checks.

Can I connect ChatGPT or other assistants instead of Claude?

Yes. Safeguard's docs have a guide per assistant, including ChatGPT, Le Chat, Microsoft Copilot, Gemini, Cursor and others, at docs.safeguard.sh/docs/mcp. All of them use an endpoint on mcp.safeguard.sh and the same Safeguard sign-in page.

Should I use OAuth or an MCP key?

Use OAuth wherever the client supports it. There is nothing to copy or rotate. Use an MCP key only for a client that can send nothing but a fixed Authorization header, and remember that a key acts as its creator across the whole workspace.

How do I control what an assistant does with other MCP servers?

Use Safeguard MCP Guardrail (GA), which the docs call Guard. You point the client at a Guard proxy URL in front of the server, and Guard applies allow, deny or monitor rules to each call and logs every decision. It is independent of Safeguard's own tool gating.

What happens if the registry goes down or resets?

Nothing changes for an assistant that is already connected; it talks to mcp.safeguard.sh, not to the registry. The registry docs say there are no uptime or durability guarantees yet, which is one more reason to keep your own record of the version and URL you approved.

Fix the vulnerabilities your assistant finds

Once an assistant can read your Safeguard data, the first questions are usually "what is vulnerable" and "what do we fix first". The answer to the second question is where most teams lose time, so here is how Safeguard approaches it.

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.

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.

See how Safeguard would help

The first demo shows the connection this post is about: Claude connected to the Safeguard MCP server with OAuth, and the choice of which tools Claude can use. It is the same flow you reach from the connector directory, ending at the same Safeguard sign-in page and the same per-tool controls described above.

Click through it at your own pace, or open it full screen.

The second demo shows the other half of the story: acting on what the assistant finds. In a real Safeguard CLI session, you ask the CLI to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows the /permissions, /model and /scan commands. Where the default MCP tools only read, the CLI is where a developer turns a finding into a tested change.

Click through it at your own pace, or open it full screen.

To try it yourself, download the Safeguard apps and CLI at safeguard.sh/download and read the docs at docs.safeguard.sh/docs. For the announcement of the registry listing, see the press release. For a map of every capability, see what Safeguard does today. For how release gates are written in plain English, see plain English security policies to release gates.

Quick check

Sources

• MCP Registry docs: About
• MCP Registry docs: Authentication
• MCP Registry docs: Publishing Remote Servers
• MCP Registry docs: Versioning
• MCP Registry docs: Moderation Policy
• MCP Registry docs: Registry Aggregators
• MCP Registry API: sh.safeguard/safeguard version 1.0.0
• MCP Registry search: sh.safeguard/safeguard
• Model Context Protocol specification 2025-11-25: Authorization
• RFC 9728: OAuth 2.0 Protected Resource Metadata
• RFC 7636: Proof Key for Code Exchange
• RFC 7591: OAuth 2.0 Dynamic Client Registration
• Safeguard docs: MCP Integrations
• Safeguard docs: Claude
• Safeguard docs: ChatGPT (OpenAI)
• Safeguard docs: Le Chat (Mistral)
• Safeguard docs: Tool availability and gating
• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: Guard Policies
• Safeguard MCP protected resource metadata
• Safeguard MCP authorization server metadata
• Safeguard press release: MCP Registry listing

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.