MCP Security: How to

Model Context Protocol has quickly become an important integration layer for AI applications and autonomous agents. Instead of building a custom connection every time an AI system needs to reach a database, development environment, business application or external service, MCP provides a standardized way for AI applications to discover data and capabilities exposed by servers. The current MCP specification, released on July 28, 2026, defines MCP as an open protocol connecting LLM applications with external data sources and tools.

That convenience has major security implications.

An LLM that exists only inside a chat interface has a relatively narrow capability boundary. An AI agent connected through MCP may be able to search private documents, query databases, call APIs, manipulate files or perform operations inside external systems. The protocol specification explicitly recognizes this power, noting that MCP can create arbitrary data-access and code-execution paths that require careful security and trust controls.

This makes MCP security an increasingly important part of AI application security.

The main question is not simply whether an MCP connection works.

The security question is:

What can the AI reach through that connection, under whose identity, with which permissions, and what happens when the model is manipulated or makes the wrong decision?

What Is MCP and Why Does It Matter for AI Security?

The Model Context Protocol provides a common interface through which AI applications can connect to external systems. MCP servers can expose resources, prompts and tools, while clients inside AI applications communicate with those servers through standardized protocol messages.

The most important security capability is often the tool layer.

The current MCP specification allows servers to expose tools that language models can invoke. Those tools may query databases, call APIs or perform computations, depending on what the server provides. The tool set available to a client may also vary according to the authorization associated with the current request.

This is powerful because it gives an AI model a standardized interface to external capabilities.

It is also exactly why MCP deserves a serious threat model.

The protocol itself does not decide whether a particular business operation is safe for the current user. A server developer still needs to define authentication, authorization, permission scope, input validation, downstream access and operational controls.

MCP standardizes connectivity.

It does not remove the need for application security.

How MCP Expands the AI Application Attack Surface

Without external tools, a language model mainly affects the information it generates.

With MCP, model reasoning can potentially influence real systems.

A legitimate user might ask an agent to inspect a project. The AI discovers an MCP tool, calls the server and receives the relevant information.

A more sensitive workflow might allow the AI to modify a ticket, create an object, interact with a database or perform another state-changing operation.

The attack surface now spans multiple components:

the human user,

the AI application,

the MCP client,

the MCP server,

the authorization infrastructure,

the exposed tool,

and the downstream system that ultimately performs the action.

An attacker does not necessarily need to compromise every component. A weakness at one trust boundary may allow abuse of a legitimate connection elsewhere.

This is why MCP security needs to be understood as end-to-end authorization and capability security, not simply protocol hardening.

The Most Important MCP Trust Boundaries

A secure MCP deployment needs a clear model of which components trust each other and why.

The protocol establishes communication between hosts, clients and servers, while HTTP-based MCP deployments can use the protocol’s authorization framework to protect restricted resources.

From a penetration-testing perspective, four boundaries deserve particular attention.

MCP Client

The MCP client operates inside the AI application and communicates with one or more servers.

It needs to know which servers are permitted, what authorization should be sent and how server responses should be handled.

A client can become an important security boundary because connecting to an MCP server may expose data or capabilities to the AI model.

Users should therefore understand which servers they are connecting to and which capabilities those servers provide. Anthropic’s guidance for remote MCP servers similarly warns users to connect only to servers they trust and to review the server’s security practices before establishing access.

In enterprise environments, this becomes an allowlisting and governance problem as much as a technical configuration problem.

Allowing employees or autonomous agents to connect arbitrary MCP servers can create uncontrolled paths between sensitive information and external services.

MCP Server

The MCP server exposes resources or capabilities to the client.

It is therefore responsible for enforcing the security boundary around whatever it exposes.

A protected server should not assume that a request is trustworthy merely because it arrived through a legitimate MCP client.

It must independently validate authorization and ensure the caller has permission to perform the requested operation.

The current MCP authorization specification treats protected MCP servers as OAuth resource servers and requires them to validate access tokens intended for their own resources.

That distinction is critical.

The server should trust validated authorization, not the language model’s decision that an operation appears appropriate.

Authorization Layer

Authorization determines which capabilities should be accessible under the current identity.

For HTTP-based MCP deployments, the current specification provides a standardized authorization framework based on established OAuth mechanisms. Protected Resource Metadata is used for discovery, and access tokens are expected to be scoped to the relevant MCP resource.

This creates a clean conceptual boundary.

The AI model determines which operation it would like to request.

The authorization layer determines whether that request is permitted.

Those roles should not be combined.

Connected Tools and Resources

The final boundary is the capability the MCP server exposes.

A tool may have very little impact, such as a simple calculation.

Another tool might access confidential records or modify production state.

The current MCP tool specification intentionally allows tools to interact with external systems, which means the security consequences of an invocation depend heavily on the underlying capability.

Security teams therefore need to classify tools by what they can actually do rather than treating every MCP function as equivalent.

MCP Authentication and Authorization Risks

Authentication establishes identity.

Authorization establishes what that identity may do.

In AI integrations, these concepts can become blurred because the human user, the AI application and the MCP client may all participate in the same operation.

The current MCP authorization guidance recommends authorization when servers handle user-specific information, administrative actions, auditable operations or enterprise environments requiring access controls.

The risk appears when that user identity disappears somewhere inside the workflow.

Imagine an employee asks an AI agent to retrieve a document.

The AI connects to an MCP server using a global service credential.

The MCP server retrieves the document from an internal system using broad administrative access.

If the backend does not preserve the requesting employee’s permissions, the agent may be able to retrieve much more information than the employee could access through the normal application.

The MCP connection technically works.

The authorization architecture is still broken.

This is exactly why authorization must follow the original actor through the tool chain wherever sensitive access is involved.

OAuth in MCP Should Not Become a Checkbox

Supporting OAuth does not automatically make an MCP deployment secure.

Authorization security depends on how tokens, clients, resource identifiers, scopes and redirects are implemented.

The July 2026 MCP authorization specification includes requirements around Protected Resource Metadata, authorization-server discovery, access-token audience validation, Resource Indicators and issuer validation. It also encourages least-privilege scope selection rather than immediately requesting every possible permission.

These controls matter because MCP can connect multiple independently operated components.

Without strong resource binding, a token issued for one service could potentially be misused against another service that incorrectly accepts it.

Without scope minimization, an AI application can accumulate permissions unrelated to the immediate task.

Without proper redirect and issuer validation, authorization flows themselves can become attack surfaces.

In other words, secure MCP authorization requires the same maturity expected from any serious OAuth deployment.

Why Token Passthrough Creates Security Problems

One of the clearest anti-patterns documented by the MCP project is token passthrough.

Token passthrough occurs when an MCP server accepts a token supplied by a client and forwards that token to another downstream service without correctly validating whether the token was issued for the MCP server itself.

The official MCP Security Best Practices explicitly identify this as an anti-pattern. MCP servers are expected to reject tokens not intended for them rather than functioning as transparent token relays.

The reason is trust separation.

An access token is not simply evidence that somebody authenticated somewhere.

It represents permission for a particular protected resource under particular conditions.

Allowing tokens to move freely between services weakens that boundary.

It can also make auditing substantially harder because the MCP server and downstream system may see different or misleading identities in their logs. The MCP security guidance specifically highlights control circumvention, audit problems, cross-service trust failures and potential data-exfiltration risk as consequences of improper token passthrough.

For security architects, the rule is simple:

A credential valid for one resource should not automatically become a universal AI credential.

Scope Minimization Is Critical for MCP

Permission scopes are especially important in MCP because one client may interact with a server exposing multiple tools.

The current authorization specification recommends that clients follow least privilege and request only the scopes needed for their intended operations. MCP also supports step-up authorization patterns where additional scopes can be requested when a later operation genuinely requires them.

That approach fits AI agents particularly well.

An assistant may begin with read-only access.

If the user later requests an operation requiring write access, the system can treat that as a separate security boundary rather than granting broad write permissions from the beginning.

This reduces the blast radius of prompt injection, model errors or compromised clients.

If the agent never receives write authority, manipulating the model should not magically create it.

Tool Discovery Should Reflect Authorization

MCP tools can be discovered dynamically.

The current tool specification allows the set of tools returned to a client to vary according to the authorization supplied with the request. In other words, a server can expose only the tools the current credentials permit.

This is a powerful security pattern.

A low-privilege user does not necessarily need to know about every administrative operation supported by the server.

More importantly, those capabilities do not need to enter the model’s available tool context at all.

Removing unavailable tools from the agent’s capability space helps reduce both accidental invocation and adversarial manipulation.

The agent cannot select a tool it never receives.

MCP Tool Security Should Follow Least Privilege

A common agent-security mistake is exposing one overly powerful tool because it simplifies integration.

For example, an MCP server could expose a generic operation capable of reading, modifying and deleting multiple types of objects.

That may be easy for developers to implement.

It creates a very large capability boundary.

A safer design separates operations according to impact.

A read-only function can have narrower authorization than a destructive function.

A user-scoped search tool can be separated from an administrative search function.

A draft operation can remain distinct from a publishing operation.

This structure allows security controls to match the actual risk of each action.

The MCP tool specification also emphasizes that tool invocation should remain visible to users and recommends human control, including clear interfaces showing available tools and confirmation for operations.

For AI products, that aligns closely with the least-privilege principles discussed in our article on AI Agent Security.

Tool Metadata Is Helpful, but It Is Not Authorization

Modern MCP tooling can expose metadata describing tools and their characteristics.

This information can improve agent behavior and user interfaces.

It should not become a security boundary by itself.

A description saying that a function is read-only does not protect the backend if the implementation actually performs state changes.

A tool marked as low-risk should still receive appropriate server-side validation.

Metadata informs behavior.

Authorization controls capability.

The two concepts should remain separate.

Never Let the Model Decide Whether an MCP Operation Is Authorized

An LLM may be very good at interpreting whether a user appears to want a particular action.

That is not the same as proving the user has permission.

Suppose a user asks an agent to retrieve an internal document.

The model decides the request is reasonable.

The MCP tool is called.

The server should still determine whether the user’s authorization permits access to that document.

The same principle applies to state-changing operations.

A model request is not a security credential.

It is an intent signal.

This distinction is one of the strongest defenses against prompt injection attacks. Even when an attacker manipulates model reasoning, the downstream security boundary can remain intact.

MCP and Prompt Injection

MCP dramatically increases the importance of prompt injection because model output may now select tools.

A manipulated model that only generates text has a limited capability surface.

A manipulated model that can reach multiple MCP servers can potentially interact with files, APIs, databases or other business systems.

The correct defense is not to assume prompt injection can always be prevented.

Instead, security teams should ensure that a successful manipulation encounters additional independent controls before becoming a sensitive action.

Authorization should still apply.

Tool scopes should still apply.

Input validation should still apply.

High-impact actions may still require confirmation.

The server should still validate the request according to the authenticated identity.

This is the same defense-in-depth principle used throughout LLM security testing.

MCP Servers Can Become Confused Deputies

The MCP Security Best Practices explicitly document the confused deputy problem as a relevant authorization threat.

This can occur when an MCP proxy server interacts with third-party APIs and security decisions across multiple client identities or authorization flows are handled incorrectly. The official guidance describes scenarios in which improper consent handling can allow an attacker to misuse the server’s legitimate authority.

The underlying lesson extends beyond one OAuth flow.

Whenever an MCP server has more authority than the caller, developers need to understand whether the server can be tricked into using that authority on the caller’s behalf.

This is especially relevant for proxy-style MCP servers connected to business platforms.

A server may have legitimate API credentials.

The attacker does not necessarily need to steal them.

If the attacker can convince the trusted server to perform an unauthorized action, the result can be functionally similar.

Remote MCP Servers Require Additional Trust Decisions

A remote MCP server introduces a trust relationship outside the local AI application.

The server may receive user information or gain permission to invoke external APIs.

This means connection decisions should not be based only on whether a server appears useful.

The operator matters.

The server’s permission requirements matter.

Its data-handling behavior matters.

Its exposed tools matter.

Anthropic’s remote MCP guidance advises users to connect only to remote servers they trust and to review security practices before establishing the connection.

Enterprise organizations may therefore benefit from centralized control over which MCP servers are approved rather than allowing every user or agent to establish arbitrary integrations.

Enterprise MCP Authorization Is Moving Toward Centralized Control

MCP’s authorization ecosystem has continued to evolve alongside enterprise adoption.

In June 2026, the MCP project announced the stable Enterprise-Managed Authorization extension, which allows organizations to use their existing identity provider as the authoritative policy layer for access to MCP servers.

The broader security idea is more important than any particular extension.

Enterprise AI access should fit existing identity governance rather than creating a parallel permission universe that administrators cannot see.

Security teams already manage users, groups, roles and access policy through organizational identity systems.

MCP integrations should preserve those governance structures wherever practical.

Local MCP Servers Are Not Automatically Safe

Remote servers attract obvious attention because traffic crosses network boundaries.

Local MCP servers can also be highly sensitive.

A local server may have access to files, development environments, command-line tools or credentials available on the user’s machine.

If the local server is malicious or compromised, those privileges can be abused.

The official MCP Security Best Practices include local server compromise as a dedicated threat area, which reflects the importance of evaluating what a local server can reach rather than assuming localhost equals trusted.

This is particularly important for developer agents.

A local AI tool may have access to valuable source code, repository credentials and deployment environments.

The deployment location is local.

The impact can still be production-level.

SSRF Matters in MCP Deployments

MCP clients and servers may need to discover authorization metadata or interact with URLs supplied through protocol flows.

That creates a potential Server-Side Request Forgery surface if implementations make requests to attacker-controlled or insufficiently validated destinations.

The official MCP Security Best Practices specifically document SSRF as an MCP implementation risk, including the possibility of requests reaching internal resources or protected network services.

The current MCP base specification also contains defensive requirements around network-based JSON Schema references: implementations must not automatically fetch network $ref values by default and are advised to restrict hosts, reject sensitive address ranges and apply limits when such fetching is explicitly enabled.

This illustrates a broader lesson.

Any feature that turns MCP-provided data into an outbound network request needs an explicit SSRF threat model.

Input Validation Still Matters

It may be tempting to assume that because the model generated the tool arguments, they are trustworthy.

They are not.

The LLM can produce malformed values.

A malicious user may influence the model.

Indirect prompt injection may affect tool selection.

Tool parameters may contain values originating from untrusted content.

MCP uses JSON Schema to describe and validate protocol structures, and the current specification provides explicit schema-validation requirements for implementations.

But schema validation is only the first layer.

A string can satisfy a schema and still represent an unauthorized record identifier.

A syntactically valid URL can still point at an internal network service.

A valid filename can still target a location the current user should not modify.

Security validation therefore needs both structural and business context.

MCP Security Requires Strong Downstream Authorization

Consider an MCP server that exposes access to a CRM.

The tool receives a customer identifier.

The identifier is correctly formatted.

The current token is valid.

That still does not establish that the user may access that customer.

The backend needs object-level authorization.

This is where MCP security meets traditional API security.

The transport can be correctly authenticated while the application remains vulnerable to broken access control.

An AI security assessment therefore needs to test both the MCP integration and the downstream business logic.

Human Confirmation Should Match Tool Impact

The MCP tool specification recommends preserving human control over tool invocation and providing interfaces that make tool use visible.

In production systems, the strength of confirmation should correspond to risk.

Reading public information may not need an approval step.

Changing a customer’s security settings probably should not happen silently.

A development agent reading repository files presents one level of risk.

An MCP tool capable of deleting production resources presents another.

The goal is not to interrupt users constantly.

It is to place meaningful friction at meaningful security boundaries.

MCP Connections Need Auditability

MCP integrations can make application workflows more dynamic, which increases the importance of understanding how an action occurred.

A useful audit trail may need to connect:

the original user,

the AI client,

the MCP server,

the tool,

the authorization context,

and the resulting downstream action.

The protocol’s security guidance highlights accountability and audit problems as one reason token passthrough is dangerous.

For security teams, that should be treated as a broader principle.

When an AI agent performs an important operation through MCP, incident responders should not be left with a backend log that says only “service account performed action.”

They need enough context to understand whose workflow created it.

The July 2026 MCP Specification Changes the Operational Model

The latest MCP specification was released on July 28, 2026 and introduced a stateless core. Requests now carry the protocol information and relevant capabilities needed for processing rather than relying on earlier connection state, and the release also strengthened authorization behavior and protocol interoperability.

This matters operationally because modern MCP infrastructure can be deployed more like ordinary stateless web infrastructure.

It also means security decisions should not rely on assumptions about connection identity or previous requests.

The current specification explicitly states that servers must not infer security-relevant context such as capabilities or client identity from prior requests on the same connection.

For pentesters, that introduces useful questions around whether application-level state handles and per-request authorization remain correctly bound to the intended user and workflow.

State Should Not Become an Authorization Shortcut

Even though the MCP protocol core is now stateless, applications can still maintain higher-level workflow state.

That is normal.

The risk appears when a state identifier itself becomes sufficient to resume a sensitive operation without verifying the caller’s authority.

Security teams should treat handles, task identifiers and workflow references like other sensitive application identifiers.

Possessing the identifier should not automatically imply permission.

This is another example of why protocol correctness and application authorization are separate concerns.

How to Security Test an MCP Integration

A useful MCP penetration test begins by understanding what the integration exposes.

Researchers should map the MCP servers available to the AI application, the resources and tools each server provides, the authorization mechanism in use and the downstream systems ultimately reached by those tools.

The most important question is not:

“Can we call the MCP tool?”

It is:

“Can the wrong user, wrong client or manipulated agent cause the tool to perform something outside the intended authority?”

Testing should then follow that action through the complete chain.

Test Authorization With Multiple Identities

If an MCP server supports different users or roles, security testing should compare them.

An ordinary user should not discover or invoke administrative tools merely because the AI knows their names.

A read-only token should not successfully reach write functionality.

A user from one tenant should not retrieve another tenant’s resources.

The MCP authorization specification explicitly supports least-privilege scopes and authorization-sensitive tool availability, giving implementations mechanisms for limiting capability according to permission.

Penetration testing verifies whether those mechanisms are actually enforced by the product.

Test Token Boundaries

Authorization testing should determine whether the MCP server accepts only tokens intended for that resource.

This is particularly important in environments where several APIs, MCP servers and authorization services coexist.

The current specification requires MCP servers to validate that access tokens were issued for the intended MCP resource and forbids accepting or transiting unrelated tokens.

Testing this boundary can uncover token confusion or passthrough designs before they become part of a larger agent attack chain.

Test Prompt Injection Against Tool Boundaries

MCP testing should also include adversarial model behavior.

A controlled assessment can evaluate whether prompt injection or untrusted external content influences the agent into requesting sensitive tools.

The important validation step happens afterward.

Does the tool execute because the model requested it?

Or does the MCP server and downstream application independently enforce the user’s authorization?

If the second answer is true, prompt injection may still alter model behavior while the critical application boundary survives.

That is exactly the security property we want.

Test Tool Combinations, Not Just Individual Tools

A server may expose several tools that appear safe individually.

Their combination can create greater impact.

A read tool plus a messaging tool may create a data-exfiltration path.

A search tool plus a modification tool may allow the agent to locate and change objects it should not control.

A configuration-reading tool combined with an execution capability may expose a more powerful attack chain.

This is why MCP security assessment overlaps strongly with the broader concept of excessive agency.

The attack surface is not just the number of tools.

It is the set of workflows those tools can form.

Test Remote Trust Boundaries

For external MCP servers, an assessment should examine what information the AI sends outward as well as what capability the remote server sends back.

A remote server can become both a data destination and a source of content entering model context.

That makes trust bidirectional.

What information leaves the organization?

What responses return?

Can those responses influence later agent decisions?

What permissions did the organization grant?

Does the server need all of them?

This becomes especially important when autonomous agents dynamically combine several external integrations.

An MCP Security Review Should Include the Architecture Around MCP

Testing the protocol in isolation is not enough.

A perfectly implemented OAuth flow does not protect a backend API with broken object-level authorization.

A correctly scoped MCP token does not fix an unnecessarily destructive tool.

Strong TLS does not prevent an agent from sending confidential information to an approved but inappropriate destination.

MCP security therefore needs to include:

identity architecture,

tool design,

application authorization,

data boundaries,

agent behavior,

and downstream impact.

This is why MCP belongs naturally inside modern LLM penetration testing rather than being treated as a standalone integration checklist.

Building a Secure MCP Architecture

A strong MCP design starts by assuming the AI model can make mistakes.

That assumption makes architectural decisions much easier.

The model may choose the wrong tool.

The server still checks authorization.

The user may supply a manipulative prompt.

The tool still operates under least privilege.

A remote resource may contain hostile content.

High-impact operations still require independent controls.

A token may exist for another service.

The MCP server rejects it because the audience is wrong.

A user needs a more sensitive operation.

The client requests additional authorization instead of receiving broad privileges from the beginning.

This is defense in depth.

No individual control needs to be perfect for the overall system to remain difficult to abuse.

MCP Security Is Ultimately Capability Security

MCP is valuable because it connects AI systems to things they could not previously reach.

That means the central security asset is capability.

Which data can the AI retrieve?

Which tools can it see?

Which actions can those tools perform?

Which identity controls them?

Which permissions are active?

Which external systems trust the MCP server?

What happens if the model chooses the wrong operation?

The answers to these questions matter more than whether the integration uses fashionable AI terminology.

A secure MCP deployment does not give the model unlimited authority and hope that prompts keep it under control.

It gives the model carefully bounded capabilities and assumes every important action must survive ordinary cybersecurity controls.

That is how MCP can make AI agents more capable without silently making them more privileged.

Frequently Asked Questions About MCP Security

What is MCP security?

MCP security is the protection of Model Context Protocol clients, servers, authorization flows, tools and connected resources against unauthorized access, credential misuse, excessive permissions and unsafe AI-driven actions. The official MCP documentation provides dedicated authorization and security best-practice guidance because MCP can expose sensitive data and powerful external capabilities.

What is the Model Context Protocol?

MCP is an open protocol for connecting LLM applications to external data sources and tools. Servers can expose resources and functions that AI applications can discover and use through standardized communication.

Does MCP support OAuth?

For HTTP-based deployments, MCP defines an authorization framework based on established OAuth standards. The July 28, 2026 specification uses Protected Resource Metadata, authorization-server discovery, Resource Indicators and access-token validation among its authorization mechanisms.

What is MCP token passthrough?

Token passthrough is an insecure pattern in which an MCP server accepts a token not properly issued for that server and forwards it to another service. Official MCP security guidance explicitly identifies this as an anti-pattern and requires servers to validate tokens intended for their own resource.

Can prompt injection abuse MCP tools?

Yes, model manipulation can influence which tools an AI agent attempts to use. The practical security impact depends on the permissions associated with those tools and whether the MCP server and downstream application independently enforce authorization.

Should every MCP tool require user confirmation?

Not necessarily. The current tool specification recommends maintaining human control and making tool invocation visible, but the appropriate confirmation model depends on the impact of the operation. Low-risk read operations and destructive production changes should not necessarily receive identical controls.

Are local MCP servers safe?

Local execution does not automatically mean low risk. A local server may have access to files, credentials or developer environments. The official MCP Security Best Practices specifically include local MCP server compromise among the threats implementations should consider.

How do you penetration test an MCP server?

Testing should examine authentication, token audience validation, scopes, tool visibility, per-user authorization, downstream object access, prompt-injection impact, tool combinations, third-party integrations and whether the server can be abused as a privileged intermediary.

What is the latest MCP specification?

As of August 19, 2026, the latest finalized MCP specification is 2026-07-28, released on July 28, 2026. It introduced a stateless protocol core along with substantial changes to capabilities, authorization and the broader MCP architecture.

Secure Model Context Protocol Servers, Tools and Authorization