Claude MCP Security: How to Review a Connector

A Claude MCP security review checks a connector before anyone enables it: who hosts the server, how it authenticates, which tools it exposes, what each tool can read, write, delete or act on, how it handles untrusted content, who approves its actions, and how it is logged and revoked. Anthropic states in its Claude Code security documentation that it reviews connectors against listing criteria for its directory but "does not security-audit or manage any MCP server," so that review is your job or your provider's. The checklist below is the one NetSys uses before a connector goes into a Team or Enterprise organization.

If MCP itself is new to you, start with what MCP is and why it matters for a business, which explains the standard and the OWASP risk list. This guide picks up where that one stops: the operational review of one specific connector.

Where do MCP connectors appear in Claude, and who can add them?

The Model Context Protocol (MCP) is the open standard Claude uses to reach outside systems; an MCP server exposes tools and data, and Claude calls them. As of October 2026, Anthropic's custom connectors article says remote MCP connectors are available on every plan, with Free limited to one. On Team, only Owners and Primary Owners can add one; on Enterprise, Owners, Primary Owners and anyone with a custom role that includes Manage access to Libraries. Members then connect individually. In Claude Code, servers are also configured in local, project or user scope, and administrators can deploy servers for everyone or block them by name or URL pattern, per the Claude Code MCP documentation.

Two behaviors from those pages set the tone for the review. Claude connects to remote servers from Anthropic's cloud, not from the user's device, so a server behind your VPN will not connect and a private server needs Anthropic's IP addresses allowlisted. And during Research, Claude can invoke connector tools automatically without further approval, which is why Anthropic tells users to click "Allow always" only for tools they trust unsupervised.

Step 1: Who hosts the server, and how does it authenticate?

Establish who operates the server, where it runs and who can change its code. A connector from a vendor you already contract with is a different risk from one a developer found in a directory. Then look at authentication. Claude offers "Sign in now," "Sign in when needed" or "No sign in"; OAuth can use Claude's published identity, automatic registration or your own OAuth client; and fixed request headers such as API keys are stored encrypted. The point that catches organizations out: on Team and Enterprise, a fixed credential is shared by everyone who uses the connector, so a bearer token pasted by an owner becomes every member's access. Prefer OAuth with per-user sign-in, and if a shared credential is unavoidable, scope it to a service account with the narrowest rights.

On the server side, the MCP security best practices in the specification set hard rules a reviewer can ask about: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server" (the token passthrough anti-pattern), servers "MUST NOT use sessions for authentication," session IDs must be secure and non-deterministic, and proxy servers that front a third-party API must implement per-client consent to avoid the confused deputy problem. A vendor who cannot answer these questions about their own server has not thought about them.

Step 2: What tools does it expose, and what is the least privilege?

List every tool the server exposes and classify each one: read, write, delete, or acts on behalf of a user (sends mail, posts a message, triggers a workflow). Then compare the list with the one workflow you are enabling the connector for. The specification's guidance on scope minimization is blunt: broad up-front scopes such as wildcard or "full-access" grants expand the blast radius of a stolen token, muddy the audit trail and make revocation disruptive, and the recommended model starts with low-risk read operations and raises privileges only when a privileged operation is first attempted. In Claude, Team and Enterprise owners can disable specific tool calls that render interactive connectors, and Anthropic's Enterprise page describes org-wide connector approval with per-tool permissions. On the API side, Anthropic's Managed Agents MCP connector (beta) defaults every MCP toolset to "always ask" and lets you disable all tools and allowlist the few you want, which is the right default to copy.

Step 3: How does it validate inputs and handle outputs?

Ask the operator what the server does with the arguments Claude sends: are identifiers validated, are queries parameterized, is there a size limit, can a tool be asked for records outside the signed-in user's scope? Then ask what comes back. Tool results flow into Claude's context, so a server that returns raw web pages, email bodies or customer-supplied free text is returning untrusted content, which is the next step's problem. Anthropic's own note is that server developers may change tool behavior after you connect, so the review is not one-time: pin a version where you can, and re-review when the tool list changes.

Step 4: How is prompt injection contained, and where are the approval gates?

Prompt injection is text inside the data (a web page, a document, an email, a ticket) written to make the model do something its user did not ask for. Anthropic's Claude Code documentation warns that "servers that fetch external content can expose you to prompt injection risk," and its connectors article says malicious servers may contain prompt injections. You cannot filter it out reliably, so you contain it: keep write and act tools behind an approval, keep "Allow always" off for anything that changes data, separate read-only connectors from write-capable ones, and do not pair a connector that reads untrusted content with one that can send mail or move money in the same session without a person in between.

Claude Code has two details worth knowing. Project-scoped servers in a repository's .mcp.json prompt for approval in interactive sessions but load without asking in non-interactive, SDK and cloud sessions, and credential environment variables are read as empty when that file is expanded, so a project file cannot forward your API key to a remote server. Both are reasons to review .mcp.json in code review like any other dependency; the wider setup is in Claude Code for a company.

Step 5: How is it logged, evaluated and revoked?

Decide before enabling how you will know what the connector did. On Enterprise, chat and Cowork activity is captured by the audit logs and the Compliance API; Team does not list audit logs, so logging has to come from the server side or the connected system. Build a short test set: five realistic prompts the workflow needs, three it must refuse, and one that includes planted injection text in the data. Run them before launch and after any tool change. Finally, confirm revocation: users remove a connector under Customize > Connectors, owners remove it for the organization, and the underlying OAuth grant or API key is revoked at the source system. Editing a connector in Claude requires removing and re-adding it, which is a useful forcing function for a re-review.

What does the review checklist look like?

What does NetSys do for MCP connectors?

NetSys builds and reviews MCP connectors for companies running Claude. Our MCP server development service covers the decision between a native connector and a custom one, read and write tool scopes, authentication, input validation, approval gates, logging and test cases, with deployment ownership and support agreed up front. The security review above is also part of our AI security assessment, which looks at AI identity, connectors, data and permissions before staff use Claude on company data. A published example of scoped integration work is our Microsoft Graph connectors case study, where each connector reaches only the data its workflow needs and every permission is documented in Entra ID. For the Microsoft 365 connector specifically, see Claude Microsoft 365 connectors: permissions before rollout.

Frequently asked questions

Is MCP secure?

MCP is a protocol, so the security of any given connector depends on the server, the client and how it is configured. The specification publishes security best practices with mandatory rules for servers, Claude adds organization controls such as owner-only connector creation and per-tool permissions on Enterprise, and the rest is review and least privilege. Anthropic does not security-audit MCP servers, so someone has to.

Does Anthropic vet the connectors in its directory?

Anthropic says it reviews connectors against its listing criteria before adding them to its directory, and that it does not security-audit or manage any MCP server. Treat a directory listing as a sign the connector exists and meets listing rules, not as a security assessment.

Who can add an MCP connector in Claude Team?

Only Owners and Primary Owners, in Organization settings under Connectors. Members then connect individually. On Enterprise, a custom role with Manage access to Libraries can also add connectors, and owners can approve connectors org-wide with per-tool permissions.

What is the biggest MCP risk for a small business?

Two combine badly: a connector nobody reviewed that reads untrusted content, paired with a tool that can act, such as sending mail or changing a record, with approvals turned off. Prompt injection in the content then drives the action. Keeping write tools behind approval and separating untrusted sources from write-capable connectors removes most of that risk.

How should developers configure MCP in Claude Code?

Use HTTP transport for remote servers (SSE is deprecated), keep shared servers in a reviewed .mcp.json, use the organization's denied and managed server settings to block unapproved servers and deliver approved ones, and remember that non-interactive and cloud sessions load project servers without a prompt.

Should we build a custom MCP server or use a native connector?

Use the native connector where one exists and its scopes fit; build a custom server when the system is niche or homegrown, when you need narrower scopes than the native connector offers, or when you need your own logging and approval logic. The build is scoped so that each tool, scope and approval is written down before launch.

NetSys builds and reviews MCP connectors with the scopes, approvals and logs written down before launch. Request an integration scope from a NetSys engineer.