How do you secure a remote MCP server that agents connect to over the network?

Treat a remote MCP server like any API that can act on real systems: authenticate every client with OAuth as the MCP specification describes, validate that each token was issued for this server, never pass client tokens through to other services, give every tool the least privilege it needs, and log and rate-limit every call. Then remember the model itself is not trusted: anything an injected agent can call, an attacker can call.

Transports

Local MCP servers usually run over stdio as a child process of the application, so the operating system's user permissions are the boundary. Remote servers use Streamable HTTP, which needs proper authentication because anyone on the network can try to connect.

Authorization in the specification

The MCP authorization specification (2025-06-18) builds on OAuth 2.1:

• A protected MCP server acts as an OAuth 2.1 resource server; an authorization server issues the tokens.
• Clients must use resource indicators (RFC 8707) to say which server the token is for.
• Servers must check that a token was issued specifically for them (audience validation).
• Token passthrough is forbidden: the server must not forward a client's token to some other API. If it needs to call a downstream service, it gets its own token for that.
• Tokens must be stored securely, since a stolen token makes requests that look legitimate.

Least privilege

• Expose narrow tools ("get_invoice", "create_draft_refund") rather than general ones ("run_sql").
• Scope tokens to the user and the actions they are allowed; act on behalf of the user so the agent cannot do what that user could not.
• Separate read and write tools, and require approval for irreversible writes in the client.

The confused deputy problem

The specification's security guidance warns about a server that holds broad credentials and acts for many clients. If it does not check who is asking, one client can get it to act with powers meant for another. Per-user authorization and consent prevent this.

Operational controls

• Rate limits and quotas per client.
• Input validation on every tool argument, with allow-lists for things like URLs and file paths.
• Audit logs of every call: who, which tool, which arguments, the result.
• Review third-party MCP servers like any dependency: who maintains it, what it can reach, pinned versions.

Prompt injection still applies

A tool description or tool result can carry injected instructions. Keep server descriptions under your control, and treat results as data.

A crisp summary: "OAuth with audience checks, no token passthrough, narrow tools, user-scoped permissions, and logs on everything."