Give Every MCP Server an Owner

OX Security found six expired domains behind publicly indexed MCP servers. Whoever registers one next receives the agent calls sent to it.

The research covered more than fifteen thousand servers listed on five MCP registries, running on about five thousand hostnames. It found that 2.3% no longer resolve. A saved connection can remain in an agent's configuration after the party that originally ran it has stopped controlling the address.

Who controls the host your agent is calling? MCP servers give agents tools and access to data, so that answer affects where the agent sends information and which credentials support the connection.

Write down what the connection can do

For each connection, Glanit's guidance on vetting MCP servers recommends recording:

• An owner who knows why the connection exists.
• The transport, meaning how the agent connects.
• The SDK and its pinned version.
• The authentication method.
• The credentials the server holds.
• The exposed tools, marked as reads or writes.

Pin the version. Glanit recommends refusing installations that leave it unspecified, so approval covers a particular version of the server.

Authentication to the server and credentials held by it describe separate access. For example, an agent can authenticate to a connector that holds a credential for the business system behind it. The inventory lets the team follow that connection through to the data and operations entrusted to the server.

Use a reference that lets the owner locate a credential for revocation. Its service and purpose help identify which access to close when the connection ends. The inventory can point to the credential without copying its secret value into the list shared for review.

A tool description can change what the agent calls

The model reads a tool's description when deciding whether to call it. Changing that description can change which operation the model chooses, even if the tool's name hasn't changed.

Glanit recommends approval again whenever the server changes, including its tool descriptions. Compare a hash of the tool list on every connection. The approved list includes descriptions, so a different hash reveals a change that can go through review before the agent relies on the revised tools.

And retain the list that was approved so the team can compare the previous wording with the change. During review, the full description shows how the tool is presented to the model, along with the permissions attached to the operation.

Check who gets the remote calls

Check the domain's registrant when reviewing a remote server. A hostname that answers can still belong to someone new. Compare who controls it now with the party named in the connection's approval.

For a hostname that no longer resolves, check which work still refers to the connection before discarding its configuration. The saved entry can help identify the affected agents and the credentials associated with their calls.

For a server holding credentials, the record also shows what access was entrusted to it. That lets the team understand the connection while establishing who operates it. If ownership can't be established, hold the agent's calls while the uncertainty is resolved.

This check applies when an approved connection is revisited too.

Remove the connections nobody claims

Find which agents still call an unclaimed server before removing access. Their work may have to move to an approved connection, or a named owner can take over a server that remains necessary. That owner takes responsibility for the reviewed version and tool list.

For a connection being retired, account for the work using it and move that work before closing access. Revoke the unused token.