Why an MCP registry needs a real process
When we first set up MCP registries inside enterprises, the registry itself was the easy part. A small service, a database table, a UI. The hard part was what happened around it. Engineers wanted servers added today, security wanted three weeks of review, and procurement wanted a vendor questionnaire that nobody had time to fill in. The registry became a bottleneck within a month, and engineers started running unregistered MCP servers on their laptops because the official path was too slow.
The fix was not to lower the bar. The fix was to design an onboarding process where the bar was actually achievable, where the work was distributed across the right teams, and where the SLA was honest about how long each step took. This post walks through the onboarding flow we have settled on after running it across several mid-sized engineering organizations.
The intake form, and what it should ask
Onboarding starts with a short intake form. The form has to be short or engineers will not fill it in honestly. Five fields are enough. The first is the server identifier, either a public registry handle for a third-party server or a repository URL for an internal one. The second is the requesting team and a single named owner who will be responsible for the server going forward. The third is the intended use case in two or three sentences. The fourth is the data classification the server will touch, picked from a fixed list of public, internal, confidential, and regulated. The fifth is whether the server performs any write or destructive actions.
Anything more elaborate than that gets ignored or filled in carelessly. The point of the form is not to do the security review. The point is to route the request to the correct review track and to capture the metadata the registry will store forever.
Three review tracks
Not every MCP server needs the same review. We use three tracks. The fast track is for read-only servers that touch public or internal data, do not call out to third-party APIs with customer data, and come from a source the org has already vetted. These get reviewed by a tech lead in the requesting team, with security visibility but not security approval. Most documentation and code-search servers fit this track, and the SLA is one business day.
The standard track is for servers that touch confidential data, perform write actions on internal systems, or come from a third party we have not seen before. These go through a security engineer who runs a checklist covering authentication, scoping, logging, and the tool surface. The reviewer reads the server's manifest, looks at the tool descriptions, and checks whether any tool can be coerced into a confused-deputy attack. The SLA here is three to five business days.
The heavy track is for servers that touch regulated data, perform irreversible actions, or are exposed to untrusted input. These get a full threat model, a code review if the source is available, and a sign-off from both security and the data owner. The SLA is two to three weeks, and the requesting team should know up front that this is what they signed up for. The point of being explicit about the heavy track is to make sure people pick it consciously, rather than discovering halfway through a fast-track review that the server actually belongs in the heavy track.
What the security review actually checks
For both the standard and heavy tracks, the review covers the same six areas. The first is authentication. Does the server require a credential, what kind, and is the credential issued by the org's identity provider rather than a long-lived static token. The second is scoping. Are the credentials the server will use scoped to exactly the resources its declared tools need, or are they overprovisioned. The third is the tool surface. For each tool, what does it do, what arguments does it take, and what is the worst case if the model calls it with adversarial arguments.
The fourth is logging. Does every tool call produce an audit record that includes the calling user, the calling agent, the model, the arguments, and the result. The fifth is drift. Does the server's manifest match its declared capabilities, and is there a mechanism to detect when the manifest changes in production. The sixth is data flow. What data leaves the org through this server, where does it go, and is that flow allowed under the data classification we recorded at intake.
A reviewer who works through these six areas will catch the vast majority of real problems. The areas are also stable enough that they can be turned into a checklist that less experienced reviewers can run, with escalation paths for the ambiguous cases.
The approval artifact
Every approved server produces an approval artifact stored alongside the registry entry. The artifact captures the review track, the reviewer, the date, the scope of approval, and any conditions. Conditions are important. A server might be approved for read-only access to a specific dataset, with the condition that any expansion in scope triggers a re-review. Conditions get encoded as policy rules so they are enforced automatically rather than living as a sentence in a wiki page that nobody reads.
The artifact is also the answer to audit questions. When a regulator asks how an MCP server got into production, the artifact is the evidence. If you do not have an artifact, you do not have a defensible answer, and the rest of the program does not matter.
Continuous review, not one-and-done
The mistake we made the first time around was treating onboarding as a one-time event. A server gets approved, it goes into the registry, it stays there. That works until the server changes. New tools appear, descriptions get rewritten, scope expands. Within six months, the server in production no longer matches the server that was approved.
The fix is a continuous review loop. The registry compares the server's current manifest to its approved manifest on a schedule. Any drift triggers a lightweight review. Most drift is benign and gets approved automatically based on rules. Drift that adds a new write tool, expands data scope, or changes authentication triggers a real review, with the server's previous approval suspended until the review completes. We covered the mechanics of this in mcp-server-capability-drift-detection.
Communicating the process
A registry process only works if engineers know about it and trust it. The single highest-leverage thing we have done is publish the SLAs publicly and report against them every month. When the fast track is genuinely one business day, engineers use it. When standard reviews are completed in five days instead of three weeks, the heavy track stops feeling like a punishment. Trust in the process is what keeps unregistered servers out of laptops.
The other piece is making the registry the path of least resistance. If using a registered server is easier than running an unregistered one, because credentials are pre-provisioned and the proxy is already wired in, engineers will use the registry without being told to. That is the goal. The registry is not a gate, it is the default.
How Safeguard Helps
Safeguard provides the registry, the review workflow, and the runtime enforcement as a single integrated platform. Intake forms route to the right track automatically based on the data classification and tool surface, approvals produce signed artifacts that satisfy auditors, and the same approval state drives runtime policy decisions so an unapproved server simply cannot be called by an agent. Continuous drift detection runs in the background, and re-reviews are triggered without engineers having to remember to file them. Onboarding stops being a bottleneck and starts being the boring, predictable part of the program.