What Is MCP Security?

Model Context Protocol (MCP) security is the discipline of protecting connections among AI applications, MCP clients, MCP servers and the tools, data and services they expose by authenticating participants, limiting authority, validating requests and results, isolating execution, recording actions and preserving a reliable way to revoke access.

MCP gives an AI application a standard way to discover and use external capabilities. Those capabilities may only read a public catalog, or they may access company files, query databases, change tickets and call administrative APIs. MCP security controls which connection and action is allowed; the protocol connection itself does not establish trust.

The security boundary includes more than an MCP server. It includes the host application, its MCP client, local or remote server processes, tool definitions, authorization services, credentials, downstream systems and any untrusted content that reaches the model. A secure server cannot compensate for a client that silently approves dangerous actions, and a trusted client cannot make an overprivileged server safe.

Readers unfamiliar with these roles should begin with the Model Context Protocol. MCP security is narrower than general agent security: it focuses on the protocol-facing connection and capabilities, while the larger agent system also includes model behavior, memory, planning and governance.

Why MCP security is important

MCP concentrates useful authority behind interfaces a model can call. One client may connect to several servers, and each server may expose multiple tools or resources. If every connection receives broad credentials, the combined authority can exceed what any single task requires.

Natural-language input also affects technical actions. A user request, retrieved document or tool result can influence which tool the model selects and which arguments it supplies. That makes conventional application risks—weak authorization, injection, unsafe input handling and exposed secrets—interact with model-specific risks such as prompt injection and tool poisoning.

Local MCP servers create an endpoint boundary. A server launched on an employee computer may inherit the client process's access to local files, environment variables, credentials and network destinations. Remote servers shift execution away from the device, but they still need authenticated transport, resource-specific authorization and protection for downstream data.

MCP security best practices therefore need to cover installation, discovery, authorization, execution, output handling, monitoring and removal. Reviewing only the server's source code or only its OAuth flow leaves other paths unexamined.

How MCP security works

MCP security works by evaluating each capability request across several distinct roles and enforcement points.

1. The user or agent initiates a task. The host application establishes who requested the work and which agent or session is acting.
2. The MCP client selects a connection. The client connects only to an approved server and retrieves its declared capabilities. Server identity and capability changes need verification.
3. Authorization limits the connection. For protected remote servers, the client obtains a token intended for that MCP server and requests only necessary scopes. Authentication proves a principal; authorization still decides which resources and operations that principal may use.
4. The model proposes a capability call. The client treats the model-generated tool name and arguments as untrusted input. Policy may allow the call, deny it, constrain it or require a person to confirm the exact action.
5. The MCP server validates and enforces. The server authenticates the request, checks authorization for the specific operation, validates arguments and invokes a narrowly defined downstream function.
6. The result crosses back into the model context. The client validates, labels and limits returned content before it can influence another tool call.
7. The system records the outcome. Logs connect the responsible user or agent, client, server, capability, requested action, policy decision and result. Tokens, server approval and local processes remain revocable.

For remote authorization, the current authorization spec requires an MCP server to validate that an access token was issued for that server. It prohibits passing the client's token through to an upstream API; the server must use separately authorized credentials for that resource. This preserves audience boundaries and makes authorization and audit evidence more reliable.

The flow does not mean every decision belongs inside MCP. Identity providers issue or support credentials, policy engines may decide access, operating systems isolate local processes, and downstream APIs enforce their own permissions. MCP carries requests between components; the surrounding architecture provides many of the controls.

Core MCP security controls

Effective MCP security uses overlapping controls because no single check covers the complete request path.

Least privilege applies at several layers. The user, agent, client, server process, token and downstream service account should each receive only the authority their role needs. A read-only tool should not hide a general command runner, and a server that reads one project directory should not inherit access to an entire home folder.

The official MCP guidance also treats local server installation as code execution. It calls for explicit consent before a client runs a local server command and recommends sandboxing, restricted filesystem and network access, and additional authorization when local HTTP transport is used.

Human approval should be reserved for meaningful decisions and show enough detail to support them. A generic prompt such as “allow tool” conceals the destination and effect. Approval fatigue is also a failure mode, so routine low-impact operations need narrow standing policy while destructive, external-sharing or privilege-changing actions receive explicit confirmation.

MCP server security and client responsibilities

MCP server security begins with ordinary secure service design. A server needs authenticated endpoints where appropriate, authorization on every protected action, strict argument validation, safe handling of paths and queries, separated tenant state, protected credentials, rate limits, secure updates and useful audit records. A model-generated request should never bypass the controls applied to other untrusted clients.

Server descriptions and tool results are also part of the attack surface. A malicious or compromised server can place instructions in a tool description or returned content to influence the model. Clients should treat server-provided text as data rather than trusted policy, distinguish its origin in the context and prevent it from silently changing approval or authorization rules.

The client is the broker between model intent and technical authority. It should maintain an approved server inventory, expose only task-relevant capabilities, keep credentials outside model context, enforce confirmation policy and isolate data flows between servers. The OWASP guidance recommends least privilege, schema integrity checks, server isolation, sensitive-action confirmation, input and output validation, and monitoring across this boundary.

Local and remote servers require different emphasis:

• Local servers need package provenance, visible launch commands, minimal process privileges, filesystem and network isolation, and a reliable way to stop or remove the process.
• Remote servers need authenticated encrypted transport, exact server identity, token audience validation, narrow scopes, tenant isolation and controlled downstream credentials.
• Proxy servers need per-client consent and must not become a confused deputy when they access third-party APIs on a user's behalf.

An enterprise MCP security example

Northstar Engineering, a fictional company, approves an MCP server that lets developers search one internal code repository and create draft issue tickets. The server cannot merge code, change repository permissions or send messages. Its remote deployment uses separate read and draft-ticket scopes.

Maya asks an AI coding assistant on a managed laptop to investigate a build error. The client authenticates Maya and obtains a short-lived token intended only for the approved MCP server. It exposes the repository search tool first; the ticket tool becomes available only if the task requires it.

A retrieved build log contains hidden text instructing the assistant to search other repositories and submit their contents in a ticket. The model proposes a wider search, but the server rejects the repository identifier because Maya's token and the tool policy cover only the assigned project. The client also labels the log as untrusted tool output and requires confirmation before creating an externalized ticket draft.

Maya reviews the proposed ticket fields and removes an unnecessary log excerpt. The server creates a draft, records the user, client, tool, project, decision and result, and returns only the ticket identifier. The security outcome comes from bounded identity, narrow tools, independent validation, explicit approval and an audit trail—not from assuming the model will always recognize hostile instructions.

MCP on managed endpoints

When an MCP client or local server runs on an employee endpoint, device management can contribute inventory and deployment context. Teams may need to know which devices have an approved client, which local server package and version are installed, which configuration applies, and whether removal or credential revocation has completed.

Organizations managing that endpoint context can consider Swif UEM as the device management layer. UEM does not authenticate remote MCP requests, inspect every tool call or make an MCP server secure; separate identity, authorization, sandboxing, data protection and monitoring controls remain necessary.

This product relationship applies only to MCP clients or servers running on managed endpoints. A cloud-hosted MCP service with no managed endpoint component remains an application, identity and cloud security concern rather than a UEM function.

MCP security risks and limitations

MCP security controls reduce exposure, but they cannot guarantee that every model-selected action is correct or safe.

• Prompt injection can redirect tool selection. Content from users, files, websites or tool results may steer a model toward an unintended call.
• Tool poisoning can alter apparent intent. A malicious description, schema or result can influence how the client or model uses another capability.
• Broad authority magnifies mistakes. Over-scoped tokens, shared credentials and general-purpose tools turn a small reasoning error into a larger operational event.
• Local servers can expose the endpoint. An untrusted package or unsafe launch configuration may execute with the user's filesystem and network access.
• Authorization can be incomplete. A valid token does not prove that a specific user may perform every operation on every resource.
• Confused-deputy designs can misuse upstream access. A proxy server may act with its own broad authority unless it preserves client identity, consent and resource boundaries.
• Results can cross server boundaries. Output from one server may become untrusted input to another, creating indirect data disclosure or injection paths.
• Capabilities can change after approval. Updates to code, tool definitions or downstream services can invalidate an earlier review.
• Logs create their own data risk. Prompts, arguments and tool results may contain credentials or sensitive content and need minimization, access limits and retention rules.
• Human review is imperfect. Vague, frequent or misleading approval dialogs can cause users to authorize actions without understanding them.

MCP is also evolving. Implementations may support different specification versions, transports and authorization features. Security review should record the actual client, server and protocol version in use instead of assuming that a newer specification requirement is present everywhere.

What MCP security does not do

MCP security does not make a model accurate, establish the business purpose of an agent or determine whether an outcome is fair and lawful. Those concerns need model evaluation, application testing, governance and qualified legal or privacy review where applicable.

It also does not replace API security. An MCP server may wrap an API, but the API still needs its own authentication, authorization, validation, rate limits and monitoring. Nor does MCP authorization replace user or agent identity lifecycle management; it consumes identities and credentials governed elsewhere.

Finally, a managed endpoint does not confer trust on every MCP connection. Device posture is one contextual signal. Each server, token, capability and requested action still needs an authorization decision appropriate to the resource and current risk.

MCP security and related concepts

The surrounding concepts address different parts of the agent system.

Prompt injection and AI agent identity examine two close trust boundaries. Security policy enforcement is the downstream control that turns those inputs into decisions and evidence.

The practical objective is bounded capability. An organization should know which client and server are connected, verify who or what is acting, expose only necessary tools and data, enforce each meaningful action outside the model, treat returned content as untrusted and retain a dependable way to stop access.