MCP Security: How to Secure AI Tools, Servers and Data Access

Securing MCP means getting identity, tools, data and supply chain right. For remote servers, follow the specification's OAuth 2.1-based authorization: PKCE with S256, the resource parameter so tokens are bound to your server, strict audience and scope validation on every request, short-lived tokens and no token passthrough to upstream APIs. Expose narrow, least-privilege tools with validated arguments and approvals for consequential actions, treat tool descriptions and results as untrusted input, install only vetted servers and pin versions, isolate tenants and log every call.

MCP basics are in the MCP guide and implementation in how to build an MCP server. Injection attacks generally are covered in prompt injection prevention, and agent-level controls in AI agent guardrails.

The MCP authorization security considerations set clear requirements. Clients must use PKCE (with S256 where possible) and include the resource parameter defined in RFC 8707, so tokens are bound to the intended MCP server. Servers must validate that every token was issued specifically for them and reject others. Servers that call upstream APIs act as their own OAuth clients and must not pass through the token they received. Authorization servers should issue short-lived tokens and rotate refresh tokens for public clients, and clients must validate the issuer parameter to prevent mix-up attacks.

The 2026-07-28 revision prefers Client ID Metadata Documents for client registration and deprecates Dynamic Client Registration (still allowed for compatibility). Authorization servers fetching client metadata should guard against server-side request forgery, warn on localhost-only redirect URIs and clearly show the redirect host during consent. MCP proxy servers that use a static client ID with third-party authorization servers must obtain user consent for each dynamically registered client, which prevents the confused deputy problem.

Framework-neutral guidance for function calling is in AI tool security, and agent identities in AI agent access control.

Models read tool descriptions and tool results, and both can carry instructions. A malicious server can hide directives in descriptions; a document or web page returned by a tool can tell the model to call another tool with sensitive data. Hosts should show users which servers and tools are active and ask for approval on sensitive calls; servers should never assume the model's request reflects the user's intent. Limit what any single model session can do across servers. See prompt injection prevention.

Local stdio servers run as processes with the user's permissions. Install servers only from trusted publishers, review their code or provenance, pin versions, and update deliberately. In organizations, maintain an approved list of servers and block others. Consider sandboxing local servers with restricted file system and network access.

Multi-tenant MCP servers must scope every query to the authenticated tenant and user. Minimize the data returned to models, which may be sent to third-party model providers. Respect data residency requirements and document which data flows through MCP in your privacy records.

Log every request: authenticated user, client, tool, arguments (redacted), result status, latency and upstream calls, with trace context. Alert on unusual patterns such as bursts of write calls, access across tenants or repeated authorization failures. Be able to revoke tokens, disable tools and block clients quickly.

MCP's specification gives remote servers a clear, standards-based authorization model, which is better than ad hoc API keys pasted into assistants. It cannot stop a model from being manipulated, a user from approving a harmful action, or a malicious local server from abusing the permissions it runs with. Defence in depth (narrow tools, server-side permissions, approvals, monitoring) is still required.

Organizations should keep a catalogue of approved MCP servers with owner, purpose, data classes, tools, authentication method and permitted clients, and block or warn on unapproved servers on managed devices. New servers go through a light security review: who publishes it, what it can access, how it authenticates, whether it passes tokens through and how it logs. This is the MCP equivalent of approving browser extensions or SaaS integrations; see security review practices for the general approach.

An illustrative scenario, not a client case: a company's internal MCP server for HR data initially accepted any valid token from its identity provider. A review finds tokens issued for other internal apps work too. The team adds audience validation, per-tool scopes (employees can read only their own records, HR staff can read their department) and logging, and removes a generic search tool that could reach salary fields.

MCP security is standard security applied carefully to a new kind of client: audience-bound tokens, no passthrough, least-privilege tools, untrusted inputs, vetted servers and full audit trails. Related: MCP guide, prompt injection prevention and guardrails.