Skip to main content

Model Context Protocol (MCP) Security

Model Context Protocol (MCP) Security

Table of Contents

Quick Answer

MCP security protects the connections that let AI applications use external tools, resources, files, data, and APIs. The main controls are trusted server selection, scoped authorization, least-privilege tools, protected credentials, argument validation, sandboxing, human approval for sensitive actions, and complete audit logs.

What Is MCP Security?

Model Context Protocol (MCP) security is the practice of safely connecting AI applications to external capabilities. MCP standardizes how a host application communicates with servers that expose tools, resources, and prompts. The protocol makes integration easier, but it does not automatically decide whether a server, tool, requested action, or returned result should be trusted.

The safest design separates connection from permission. An agent may discover a tool, but a deterministic policy layer must still verify identity, scope, target resource, argument values, business rules, and whether a person must approve the action.

How MCP Hosts, Clients and Servers Work

The host contains the AI application and creates a client for each server connection. The server exposes capabilities, while a separate policy boundary decides which identity may use which capability against which resource.

Application zone

UserIntent and consent
MCP Host / AI ApplicationModel and orchestration
MCP ClientManages one server connection
Policy and authorization boundary Identity · scopes · arguments · approval
Secure transport

Server zone

MCP ServerExposes approved capabilities
ToolsResourcesPrompts
Files · Databases · External APIs

Connection is not permission. Discovery and transport never replace resource-level authorization and business-policy checks.

MCP separates the host and client from the server, but every capability still needs an explicit policy and authorization decision.
ComponentRolePrimary riskRequired control
HostRuns the AI applicationOver-trusting model outputPolicy enforcement
ClientManages a server connectionUnsafe discovery or authorizationServer verification
ServerExposes capabilitiesExcessive accessAuthentication and scoped authorization
ToolPerforms an actionTool misuse or poisoningSchema and action validation
ResourceSupplies dataLeakage or context injectionAccess control and filtering
TransportCarries messagesHijacking or interceptionSecure transport and session handling

MCP Trust Boundaries

Every boundary can carry identity, permissions, data, instructions, or executable intent. A model response is not authorization. A tool schema is not proof that the implementation behaves as described. A valid token is not proof that the current user should access the requested record. Each layer must independently enforce its responsibility.

Top MCP Security Risks

The OWASP MCP Top 10 is currently a beta-stage living document. It highlights token exposure, excessive scope, tool poisoning, supply-chain compromise, unsafe execution, intent-flow subversion, weak authentication, missing telemetry, shadow servers, and context over-sharing.

MCP risk coverage map

GroupCategories
Identity and authorization3
Tools and supply chain3
Execution and intent2
Audit and governance1
Context and data1
Insecure Lab grouping of the OWASP MCP Top 10 beta categories. This is a coverage map, not a severity ranking.

MCP Authentication vs Authorization

DecisionQuestion
AuthenticationWho is the user, client, service, or agent?
AuthorizationWhich resources and actions may this identity use?
Policy validationIs this exact requested action safe in the current context?
ApprovalDoes a person need to confirm the impact?

OAuth and Scoped Access

For remote servers that handle user data or sensitive operations, use OAuth-based authorization with protected-resource metadata, authorization-server discovery, PKCE, explicit consent, minimum scopes, short-lived tokens, protected token storage, and no token passthrough. OAuth starts the authorization process; the application must still enforce resource-level and business-level policy.

Local vs Remote MCP Servers

AreaLocal serverRemote server
Main exposureLocal process, files and user privilegesNetwork, identity and external APIs
CredentialsLocal credential store or tightly scoped environmentOAuth or equivalent scoped authorization
Key controlSandboxing and process permissionsAuthentication, authorization and transport security
Common mistakeRunning with full user privilegesBroad scopes or weak server trust

Third-party server review

Can This MCP Server Be Trusted?

Review the server before installation and again whenever definitions, versions or permissions change. Approval should be based on verifiable ownership, constrained access, observable behavior and a practical revocation path.

  1. Ownership and provenance

    Confirm who maintains the server and how it is distributed.

    Verify
    • Use an approved registry or documented source.
    • Record owner, version and business purpose.
    • Reject unclear or abandoned projects for sensitive use.
  2. Requested permissions

    Review the exact tools, resources, scopes, files and network destinations requested.

    Verify
    • Prefer read-only access.
    • Separate high-impact write tools.
    • Avoid broad wildcard scopes.
  3. Tool descriptions and schemas

    Treat descriptions, parameter schemas and tool results as untrusted metadata.

    Verify
    • Pin approved definitions.
    • Diff changes before rollout.
    • Validate actual behavior outside the model.
  4. Execution environment

    Limit what local or remote servers can reach.

    Verify
    • Sandbox local processes.
    • Restrict outbound network access.
    • Keep secrets out of general environment variables.
  5. Monitoring and revocation

    Every connection needs logs and a practical way to stop it.

    Verify
    • Log discovery, consent and calls.
    • Alert on unusual actions or schema changes.
    • Revoke tokens and disable servers quickly.
ApproveEvidence supports the intended, least-privilege use.
RestrictReduce scope, isolate execution or require approval.
RejectOwnership, behavior or revocation controls are unclear.

MCP and Agent-Security Timeline

Protocol guidance and external evidence relevant to MCP identity, authorization, server trust and operational control.

  1. Protocol

    Model Context Protocol

    MCP authorization guidance matured

    The MCP specification documented OAuth-based authorization, resource metadata, scopes, PKCE, consent, and token-handling expectations.

    Official MCP authorization guide
  2. Framework

    OWASP GenAI Security Project

    OWASP agentic security benchmark released

    OWASP published the Top 10 for Agentic Applications 2026, making identity, tools, memory, supply chain, and autonomy distinct security concerns.

    OWASP Agentic Top 10
  3. Standard

    NIST

    NIST launched an AI Agent Standards Initiative

    NIST highlighted interoperable and secure agents, including identity, authentication, authorization, evaluation, and protocol standards.

    NIST announcement
  4. Incident

    OWASP GenAI Security Project

    Active exploitation reached an MCP workflow surface

    OWASP reported active exploitation involving unsafe Flowise CustomMCP configuration handling, reinforcing that orchestration and configuration are executable trust boundaries.

    OWASP Q1 2026 round-up

Case Study: Flowise CustomMCP Exploitation

OWASP's Q1 2026 exploit round-up reported active exploitation involving unsafe Flowise CustomMCP configuration handling. The defensive lesson is broader than one product: configuration, orchestration, custom tools, and server definitions can become executable trust boundaries. Treat them like code, restrict who can change them, patch quickly, and log every privileged configuration change.

This case study intentionally omits vulnerable configuration values and exploitation steps.

Secure MCP Deployment Checklist

  • Inventory approved MCP servers and record their owners.
  • Verify server provenance, package source and update process.
  • Use minimum scopes, short-lived credentials and secure storage.
  • Separate read-only tools from write, delete, payment and administration tools.
  • Validate tool arguments and business rules outside the model.
  • Restrict filesystem, process and network access.
  • Sandbox local servers and isolate trust domains.
  • Require approval for sensitive, irreversible or externally visible actions.
  • Log discovery, consent, calls, results and definition changes.
  • Provide token revocation, server disable and emergency rollback controls.

Explore AI Security Topics

FAQs

MCP security protects Model Context Protocol connections between AI applications, clients, servers, tools, resources, and external systems. It focuses on identity, authorization, server trust, untrusted context, tool permissions, secrets, execution controls, and auditability.

MCP provides a standard way to connect AI applications and external capabilities, but secure deployment still requires trusted servers, scoped authorization, protected credentials, argument validation, sandboxing, monitoring, and approval for sensitive actions.

Remote MCP deployments can use OAuth-based authorization so clients request limited scopes and users consent to access. The server should still verify the user, client, resource, action, and business policy for every sensitive request.

The host is the AI application, the client manages a connection from the host, and the server exposes tools, resources, or prompts. Security controls are needed at every boundary.

Local servers reduce some network exposure but can inherit powerful filesystem, process, credential, or user permissions. Remote servers add network, identity, transport, and third-party trust risks. Neither model is automatically safe.

Verify ownership, distribution, requested permissions, tools, data flows, update process, logging, revocation, and whether definitions or schemas can change after approval.

Sources and further reading