Before you connect it: a short approval check for MCP servers

Sooner or later someone on your team asks to connect an AI assistant to a company system. The request usually names an MCP server: a small piece of software that sits between the assistant and a tool such as your ticketing system, a database or a document store. It takes minutes to install and makes the assistant far more useful.

It is also a new integration with access to your data, and it deserves the same approval as any other. This article gives an operations or technology lead a short check to run before saying yes. It is written for servers from third parties.

What you are actually approving

MCP, the Model Context Protocol, is an open standard for connecting AI applications to tools and data. The assistant (the client) asks a server which tools it offers, and then calls them. Per the MCP specification, tools section, tools are designed to be model-controlled: the language model can discover and invoke them based on the conversation.

That sentence is the reason to be careful. When you approve a server, you do not approve a fixed set of actions that a person triggers. You approve a set of capabilities that a model may decide to use, including in response to text it read in an email, a ticket or a web page. For that second risk, see our article on prompt injection controls for AI agents. The check below is about the other half: whether the server itself deserves the access you are about to give it.

The current version of the specification at the time of writing is 2026-07-28. The protocol is still changing, so check the current text.

Question 1: who publishes it, and where does it run?

Start with the publisher, then the place the software runs.

• Publisher. Is it from the vendor of the system it connects to, from a named company, or from an individual developer on a code-hosting site?
• Local or remote. A local server runs on the employee's machine, and the specification's security guidance says such servers can have direct access to the user's system and run with the same privileges as the client (MCP security best practices, local server compromise). A remote server runs on someone else's infrastructure, which means your data leaves your network on every call.
• Where it came from. Installing a local server often means running a package from a public registry. That is software supply chain exposure, which OWASP lists as LLM03:2025 Supply Chain in its Top 10 for LLM applications.

A word on the official MCP Registry, because people treat it as a vetting step. Its own documentation says it verifies namespace ownership, so that a server name ties to a verified GitHub account or domain, and that it delegates security scanning to the underlying package registries and to downstream aggregators. It also describes itself as being in preview. A listing tells you who claims to publish a server. It does not tell you the code is safe.

Question 2: which tools does it expose, and which of them write?

Get the full tool list, descriptions included, and sort the tools into three groups: read, write inside the system (create a ticket, edit a record) and anything with wider reach (delete, send, export, run code or queries).

Approve by group, not by server. A good first approval is read-only, with each write tool added separately and a reason recorded for it. This follows the same logic as least-privilege access for AI agents: the assistant should have the narrowest access that does the job.

Two points from the specification matter here. First, it says clients must consider tool annotations, which describe tool behavior, untrusted unless they come from trusted servers. A tool labelled "read-only" in its metadata is a claim by the server, not a guarantee. Second, it says there should always be a human in the loop with the ability to deny tool invocations, and that applications should present confirmation prompts for operations. Check whether your AI client actually does this for the tools you are enabling, and whether the people using it can switch confirmations off.

The tool list can also change after you approve it: the specification lets servers notify clients when it does. That is one more reason to pin a version.

Question 3: how does it sign in?

For servers reached over HTTP, the specification's authorization section describes an OAuth-based flow. Authorization is optional in the protocol, so a remote server without it is allowed by the standard but is a red flag for anything touching company data. For a local server using the standard input/output transport, the specification says it should not follow that flow and should take credentials from the environment instead.

In practice, check these points:

• Whose identity does it use? A sign-in that carries the individual user's permissions is easier to audit and limit than one shared service account for the whole team.
• How narrow is the consent? The authorization specification recommends least-privilege scopes, and its security guidance lists publishing all possible scopes, or using wildcard scopes such as "full-access", among common mistakes. If the consent screen asks for everything, ask why.
• Does the server accept only tokens meant for it? The specification forbids "token passthrough", where a server accepts tokens issued for another service and forwards them. A server that cannot explain how it avoids this is a poor candidate for production data.
• Where do secrets live? A local server configured with an API key in a plain-text file on a laptop is a credential you now have to manage. Decide who rotates it.

You do not need to audit the OAuth implementation yourself, but get the vendor's answers to these questions in writing.

Question 4: is the version pinned?

Many local servers are started with a command that fetches the latest release each time. That means the code running on your people's machines can change without anyone reviewing it. Pin the exact version you reviewed and make updates a deliberate step with a short re-check of the tool list. For a remote server you cannot pin the code, so ask how the vendor announces changes.

Question 5: who owns it, and how does it come out?

Every approved server needs a named internal owner: someone who answers for it, reviews it on a schedule, and gets the call when the vendor announces a problem.

Write down the exit before the entry. Who can disable it, how fast, and which credentials must be revoked afterwards? If removal means hunting through individual laptops for configuration files, find that out before approving.

A one-page record

Keep the decision to a page you can find later:

1. Server name, publisher, local or remote, version or release channel.
2. Systems it connects to, and the account or identity it uses.
3. Approved tools, grouped as read, write and wider reach, with a reason for each write tool.
4. Sign-in method and scopes granted.
5. Internal owner, review date and how to switch it off.
6. What was not checked.

The last line matters: separate vendor claims from what you verified. OWASP's entry on excessive agency, LLM06:2025, describes the failure this record is meant to prevent: an LLM-based system given more functionality, permissions or autonomy than the task needs.

If the connection will reach several systems, add them one at a time, as described in connecting an AI agent to CRM, email and documents.

When this check is not enough, and what to do next

This is a first-pass check, not a security audit. Regulated or highly sensitive data needs a proper security and legal review. MCP is young and clients differ in how they handle consent and updates, so treat every answer as valid only for the version you reviewed.

The lesson: approve a specific server, at a specific version, with specific tools, for a named owner. Never approve "MCP" in general.

Your next step is concrete. Take the request that is open on your desk, send the five questions to the person who asked, and fill in the one-page record before anything is connected. If you want help running that review for the systems that matter most, see our AI consulting service.

Sources

• Model Context Protocol, Specification, version 2026-07-28, project documentation, current version at 3 November 2026.
• Model Context Protocol, Tools, 2026: model-controlled tools, human in the loop, untrusted annotations, security considerations.
• Model Context Protocol, Authorization, 2026: optional authorization, HTTP versus standard input/output transport, scope selection, token handling.
• Model Context Protocol, Security Best Practices, 2026: local server compromise, token passthrough, scope minimization.
• Model Context Protocol, The MCP Registry, 2026: namespace verification, delegated security scanning, preview status. Statements about the registry are the project's own.
• OWASP GenAI Security Project, LLM03:2025 Supply Chain and LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025.