Claude Connectors Security: Controlling Remote MCP Server Access
Claude connectors give an application a route to approved remote MCP servers. Secure deployments need a defined server inventory, authorization at the MCP server, narrow tool permissions, trusted connector configuration, and request-level policy for the LLM traffic that begins the flow. This article maps those controls to their actual boundaries.
A Claude connector can make a remote MCP server available to a model during one API request. That changes the security question from "can the model answer?" to "which remote system may receive an action, and under whose authority?" The connector configuration is now part of the application's security boundary.
I would require the team to name every remote MCP server on a single page, including its owner, URL, authorization method, exposed tools, and data classification. The page is less glamorous than a 47-slide agent architecture deck. It is also where a real review starts.
TL;DR
- Claude connectors require security controls at the application, Claude request, MCP authorization, and remote-tool boundaries.
- Each connector should name a trusted remote server, a purpose, an owner, and the narrowly scoped tools it exposes.
- MCP server authorization limits what the connector may access, while request-level policy limits what an authenticated caller may send to an LLM endpoint.
- DeepInspect governs routed HTTP AI requests and provides per-decision evidence; it does not replace MCP server authorization or tool-specific controls.
Remote MCP server boundary
Anthropic's MCP connector documentation explains that the Claude API can connect to remote MCP servers and use their exposed tools. This is a useful integration pattern. It also means a server outside the application process can receive actions initiated during a model run.
The first control is inventory. A connector configuration should point to a server the enterprise has approved, rather than accepting arbitrary server locations at runtime. The owner needs to review the tools exposed by that server and the data each tool can return. A search connector and a connector that creates records in a production system have different approval requirements, even when both use the same protocol.
The MCP authorization specification defines an OAuth-based authorization model for protected resource servers. Its role is specific: the MCP server controls access to its protected resources. That server-side authorization must remain narrow. A model prompt should never become the authority source for a sensitive write operation.
Tool permissions and data paths
A connector can expose a tool description to the model. The model receives that description as input and can decide to call the tool. A secure design treats tool descriptions and tool responses as untrusted input to the model. Retrieved content receives the same treatment. That is the same practical concern covered in indirect prompt injection, where instructions hidden in retrieved material can influence a later model action.
Separate the controls by the decision they make:
- The application decides which connector configuration is allowed for a user or workload.
- The MCP server authorizes access to its protected resource and validates the token it receives.
- The remote tool enforces its own business permissions, such as read-only access or a required approval for a write.
- The LLM request policy evaluates the authenticated caller, prompt classification, route, and policy before the model receives the request.
Each control should fail in a way the next reviewer can see. A rejected token is recorded in the MCP server audit trail, and a blocked prompt appears in the request-level policy record. The destination system retains a declined business action in its own audit trail.
The hands-on test should use a deliberately limited account. Put a connector against a staging repository or a narrow test tenant, and attempt an allowed read. Then verify that an out-of-scope action remains rejected by the destination. Capture the request ID and timestamp in every record. This test is more useful than a generic claim that a connector is "secured."
Request-level enforcement
MCP authorization begins after an application has chosen to call Claude and Claude has selected a remote tool. There is an earlier decision on the HTTP path: may this authenticated caller send this content to this model route at all? That is the AI request boundary.
A request-layer proxy can inspect the routed HTTP AI traffic before it reaches the model endpoint. It evaluates identity context supplied by the application, role, data classification, destination, and organizational policy. It can block or redact a request before the provider sees it. This control does not repair a vulnerable remote tool, discover unknown MCP servers, or replace a resource server's token checks. Those responsibilities remain with the application and MCP layers. The destination system retains responsibility for its own controls.
I think security teams should reject a connector design that puts every sensitive action behind one broad OAuth grant. The model becomes a flexible caller. The permission should remain as narrow as the business action, with a recorded decision each time the AI request crosses its boundary.
DeepInspect
DeepInspect is a stateless proxy for HTTP AI traffic between authenticated users or agents and LLM endpoints. It evaluates identity, role, classification, model authorization, and organizational policy for each routed request. The proxy produces a signed, tamper-evident per-decision audit record outside the calling application's write path.
That role complements a secured Claude connector deployment. The MCP server retains authority over its protected resources and tools. The application owns connector inventory and configuration. DeepInspect provides a policy decision point for the routed AI request that begins the flow. Book a technical deep dive at deepinspect.ai.