MCP SECURITY

What is MCP security?

MCP security is the practice of protecting AI applications and agents that connect to external tools, data, and services through Model Context Protocol.

Security teams need to understand not only the MCP connection itself, but also the tools, credentials, permissions, systems, and actions behind it.

Explore MCP Security Explore MCP Security Risks

THE FULL MCP PATHThe connection is one hop of six.

AGENTMCP SERVERTOOLCREDENTIALENTERPRISE SYSTEMDATA / ACTION

THE DEFINITION

MCP security protects the path from agent to action.

MCP security is the practice of protecting AI systems that use Model Context Protocol to connect to tools, data sources, and external services. It includes securing MCP servers and clients, understanding tool permissions and credentials, limiting access, treating tool output as untrusted, controlling sensitive actions, and monitoring how agents use MCP.

MCP security commonly includes:

MCP server inventory
Tool inventory
Ownership
Authentication
Authorization
Credential management
Least privilege
Prompt injection defense
Tool-output validation
Runtime action control
Human approval
Data protection
Red teaming
Auditability

THE PROTOCOL

What is Model Context Protocol?

Model Context Protocol, or MCP, is a standard that allows AI applications to connect to external tools, data sources, and services through a common interface.

Without a shared protocol, every AI application needs its own integration for every system it uses. MCP gives those connections one shape, which makes it easier to expose capabilities to AI systems, and easier for those systems to reach more of the business.

ToolsResourcesDataApplication capabilities

For a security leader, the practical meaning is simple: an MCP connection is a new, standardized way for an AI system to read and act on enterprise systems.

ARCHITECTURE

How does MCP work?

An AI application uses an MCP client to connect to one or more MCP servers. Each server exposes tools and resources, and those tools reach the external systems where data lives and actions happen.

01AI APPLICATION / AGENTThe system that decides what to do next

02MCP CLIENTConnects the application to MCP servers

03MCP SERVERExposes tools, resources, and prompts

04TOOLS / RESOURCESCapabilities and data the agent can use

05EXTERNAL SYSTEMSDatabase · CRM · File storage · Source control · Cloud · Internal API · SaaS

THE CLIENT

What is an MCP client?

An MCP client is the component inside an AI application that connects to an MCP server and makes tools or resources available to the AI system.

The client sits on the path between the agent and the MCP server, so it decides much of what the agent is exposed to.

Security concerns include:

Which servers the client trusts
Which tools become available to the agent
How server metadata is handled
What information is sent to the server

THE SERVER

What is an MCP server?

An MCP server exposes tools, resources, or capabilities that an AI application can access through Model Context Protocol.

Because it can sit between the agent and sensitive systems, an MCP server is often an important security boundary.

An MCP server may be:

Internally developedLocally hostedRemotely hostedOpen sourceThird-party managedVendor operated

THE TOOL

What is an MCP tool?

An MCP tool is a capability exposed by an MCP server that an AI application or agent can invoke.

A tool turns model intent into an external action.

Search recordsQuery databaseCreate ticketSend messageModify resourceUpload fileTrigger workflow

WHY IT MATTERS

Why is MCP security important?

MCP can expand what an AI system knows — and what it can do.

Connecting an agent to an MCP server can add capability in several places at once. Each one moves the security boundary outward.

New toolsNew data accessNew identitiesNew credentialsNew third-party dependenciesNew external contentNew actions

THE TRUST MODEL

What does an MCP connection actually trust?

Approving an MCP connection extends trust down a chain. Each layer raises its own question, and an answer at one layer says nothing about the next.

01AGENT
Which agent is requesting access?
02MCP CLIENT
Which servers does it trust, and what does it send them?
03MCP SERVER
Who operates it?
04TOOL
What capability does it expose?
05CREDENTIAL
Which identity does it use?
06SYSTEM
What can it reach?
07DATA / ACTION
What can it change or move?

RISK TAXONOMY

What are the main MCP security risks?

The risks follow the trust path: what a server is, what its tools expose, what the credentials behind them can reach, and what content comes back.

UNTRUSTED MCP SERVERSUnknown or compromised server behavior.

TOOL POISONINGManipulated tool descriptions or metadata influence agent behavior.

INDIRECT PROMPT INJECTIONTool or resource content carries instructions the agent should not follow.EXCESSIVE TOOL PERMISSIONSTools expose more capability than an agent needs.OVERPRIVILEGED CREDENTIALSDownstream identities have broad access.TOOL MISUSEA legitimate tool is used outside its intended context.DATA EXPOSURESensitive data becomes reachable through MCP.

UNSAFE ACTIONSAgents invoke high-impact tools without sufficient review.

THIRD-PARTY RISKExternal servers create new trust dependencies.

SHADOW MCPSecurity teams do not know which MCP servers are connected.

Explore MCP Security Risks and Attacks

AUTHENTICATION

How does authentication fit into MCP security?

Authentication answers one question: who or what is connecting?

For remote servers, the MCP specification defines an optional authorization flow based on OAuth 2.1. Local servers that run over standard input and output take their credentials from the environment they run in instead.

Either way, a valid authenticated connection does not mean every available action should be allowed.

Identities can exist at several layers:

AI applicationUserAgentMCP clientMCP serverDownstream service

ACCESS DECISIONS

Authentication and authorization are not the same

Authenticated does not mean authorized for every tool or action.

Explore Runtime Security

AUTHENTICATIONWho is making the request?

AUTHORIZATIONWhat is that identity allowed to do?

RUNTIME POLICYShould this particular action happen now?

CREDENTIALS

What credentials sit behind MCP tools?

An MCP tool usually authenticates to its downstream system with a credential of its own. The agent may never receive that credential directly. If it can invoke the tool, it can still exercise the permissions behind it.

The MCP security guidance forbids one shortcut outright: a server passing a client’s token straight through to a downstream API, which hides who is really acting.

Effective agent access includes permissions exercised indirectly through MCP tools.

Explore Agent Identity & Permissions

Service accountAPI keyOAuth tokenCloud roleWorkload identityUser-delegated token

LEAST PRIVILEGE

Apply least privilege to MCP tools

TASKLook up invoice status.

TOOLS AVAILABLE

Read invoiceNeeded
Modify invoiceNot needed
Issue refundNot needed
Export customerNot needed
Delete invoiceNot needed

Security teams should minimize exposed tools, downstream permissions, writable resources, accessible datasets, and external actions. Limit the tools an agent can see and the permissions each tool runs with.

Explore Overprivileged Agents

TOOL OUTPUT

Should MCP tool output be trusted?

Not automatically. A tool can be approved and still return content that nobody approved. Tool responses carry whatever the downstream system holds, and that content may be untrusted.

Trust the connection selectively; validate the content separately.

Tool output may include content from:

DatabasesWeb servicesExternal APIsUsersThird-party systemsDocuments

PROMPT INJECTION

How can prompt injection happen through MCP?

Instructions can arrive inside the content an MCP tool returns. This is an indirect prompt injection pattern: the malicious instructions come through external content rather than a direct user prompt.

The defense is not only to filter content. It is to limit what the agent can do next if manipulated content gets through.

Explore Indirect Prompt Injection Prompt Injection

MCP TOOLRETURNS UNTRUSTED CONTENTAGENT PROCESSES CONTENTCONTENT INFLUENCES DECISIONAGENT INVOKES ANOTHER TOOLSENSITIVE ACTION

TOOL POISONING

What is MCP tool poisoning?

Tool poisoning is manipulation of the information associated with a tool in a way that causes an AI agent to misunderstand the tool or use it unsafely.

Agents decide which tool to use, and how, from what the tool says about itself. That makes the tool’s self-description part of the attack surface. Review it as you would code, and watch for changes after approval.

DescriptionMetadataParametersOutput

THIRD-PARTY SERVERS

How should organizations evaluate third-party MCP servers?

Third-party does not automatically mean unsafe. It means the trust boundary should be explicit.

Who operates the server?
Where is it hosted?
What data does it receive or process?
Which tools does it expose?
What credentials does it use?
What systems can it reach?
How is the server updated?
What dependencies does it use?
Who owns the relationship internally?
How is access revoked?

VISIBILITY

What is shadow MCP?

Shadow MCP refers to MCP servers or connections used inside an organization without full visibility, inventory, ownership, or security review.

You cannot assess MCP risk if you do not know the connection exists.

Explore Agent Discovery

Common sources:

Developer experimentationLocal toolsOpen-source serversSaaS integrationsAutomation workflowsProductivity tools

DATA SECURITY

How can MCP expose sensitive data?

Data can move in two directions through MCP: from internal systems into the agent’s context, and from the agent out to wherever a tool can send it.

MCP TOOL→INTERNAL SYSTEM→SENSITIVE DATA→AGENT

AGENT→MCP TOOL→EXTERNAL DESTINATION

Explore Data Exfiltration

Security questions:

What can the tool read?
What can it write?
What can it export?
Where can it send data?
Which identity enables access?

TOOL MISUSE

A trusted MCP tool can still be used unsafely

The server is legitimate. The tool is legitimate. The action is still inappropriate for the task. Approving a tool is not the same as approving every way it can be used.

Explore Tool Misuse

TASKCheck order status

TOOL USEDExport all orders

PROBLEMLegitimate tool, wrong action for the task

EXCESSIVE AGENCY

MCP can expand agent autonomy

Adding a powerful MCP tool can turn an advisory agent into one that acts. That changes the security model, so permissions, autonomy, approval, and runtime policy should be reconsidered whenever a tool is added.

Explore Excessive Agency

BEFORE MCPThe agent recommends a refund.

A person reads the recommendation and decides.

AFTER MCPThe agent can issue the refund.

The decision and the action now sit with the agent.

TOOL CHAINS

MCP security should consider tool chains

1Query internal records

2Generate document

3Upload document

4Send external message

Risk can emerge from the sequence rather than the individual tool.

Each tool may be legitimate on its own. Combined, the workflow can become a data-exfiltration path.

RUNTIME SECURITY

Some MCP actions should be evaluated at runtime

A static permission says the finance service may issue payments. It cannot say whether this payment, of this size, requested by this agent, should go through now. Runtime policy can.

Context can include the agent, identity, tool, parameters, resource, data sensitivity, environment, destination, and autonomy level.

Explore Runtime Security

CONCEPTUAL EXAMPLE

AGENTFinance Agent

MCP TOOLIssue Payment

IDENTITYfinance-service

AMOUNT$75,000

POLICYApproval required above threshold

DECISIONREVIEW

HUMAN CONTROL

Which MCP actions should require human review?

Most MCP actions do not need a person in the loop. Review earns its cost where an action is hard to undo, moves data outside the organization, or carries legal, financial, or customer impact.

LARGE FINANCIAL TRANSACTIONSREVIEW

EXTERNAL DATA TRANSFERREVIEW

DESTRUCTIVE ACTIONSREVIEW

PRODUCTION CHANGESREVIEW

PRIVILEGED ADMINISTRATIONREVIEW

BULK DATA MODIFICATIONREVIEW

LEGAL OR CUSTOMER-IMPACTING ACTIONSREVIEW

ADVERSARIAL TESTING

How do you red team MCP?

MCP red teaming tests the whole path, not just the model. For each scenario, it asks which server was involved, which tool was invoked, which identity authorized it, what the action affected, and whether runtime controls worked.

Explore AI Red Teaming

Manipulated tool outputMalicious tool descriptionsExcessive downstream permissionsUntrusted server behaviorPrompt injectionTool misuseApproval bypassMulti-tool action chainsData exposure

PRACTICAL GUIDANCE

MCP security best practices

01INVENTORY MCP SERVERSKnow which servers are connected.

02ASSIGN OWNERSHIPKnow who owns each connection.

03REVIEW TOOLSUnderstand every exposed capability.

04MAP CREDENTIALSKnow which identities sit behind tools.

05APPLY LEAST PRIVILEGELimit both tools and downstream permissions.

06TREAT TOOL OUTPUT AS UNTRUSTEDReturned text should not automatically become instruction authority.

07LIMIT HIGH-IMPACT TOOLSDo not expose destructive capabilities unless necessary.

08APPLY RUNTIME POLICYEvaluate sensitive actions before execution.

09REQUIRE APPROVAL WHERE APPROPRIATEKeep humans involved in high-impact actions.

10SEGMENT ENVIRONMENTSSeparate development and production access.

11PROTECT SENSITIVE DATAUnderstand data sources and destinations.

12RED TEAM MCP PATHSTest adversarial scenarios.

13LOG TOOL USEMaintain attribution and auditability.

14REVIEW THIRD-PARTY SERVERSMake external trust explicit.

CHECKLIST

MCP security checklist

Run this for every MCP server an agent can reach, before production and whenever its tools change.

Server owner known
Server purpose documented
Connected agents known
Tools inventoried
Tool permissions reviewed
Credentials mapped
Sensitive data identified
External destinations understood
Production access justified
Tool output treated as untrusted
High-impact actions controlled
Human approval defined
Logging enabled
Red-team scenarios tested
Decommissioning process defined

REFERENCE ARCHITECTURE

A practical MCP security architecture

Controls follow the path from the agent through the client, server, tools, and credentials to the systems, data, and actions at the end of it.

AI AGENT

MCP CLIENT

MCP SERVER

TOOLS

IDENTITIES / CREDENTIALS

ENTERPRISE SYSTEMS

DATA / ACTIONS

DISCOVERYOWNERSHIPLEAST PRIVILEGEOUTPUT TRUSTRUNTIME POLICYAPPROVALMONITORINGAUDITRED TEAMING

AUTHORITATIVE GUIDANCE

MCP security guidance and related frameworks

These resources provide shared language for MCP threat modeling, authorization, testing, and risk management. They do not imply endorsement of Eyrane.

MCP SECURITY BEST PRACTICESThe protocol’s own guidance on attacks and mitigations, including confused deputy, token passthrough, server-side request forgery, local server compromise, and scope minimization.MCP AUTHORIZATION SPECIFICATIONThe optional OAuth 2.1-based authorization flow for HTTP-based MCP servers, with token audience and privilege guidance.OWASP AGENTIC AIThreats and mitigations for agentic AI systems, including tool misuse and excessive agency.OWASP TOP 10 FOR LLM APPLICATIONSCommon generative AI application risks, including prompt injection and excessive agency.MITRE ATLASA knowledge base of adversarial tactics and techniques against AI systems.NIST AI RMFA framework for managing AI risk across governance, mapping, measurement, and management.

EYRANE’S POINT OF VIEW

Secure the full MCP path

MCP security should not stop at whether a server connection is authenticated.

Security teams need visibility into the agent, tool, credential, downstream system, data, and action behind that connection.

Eyrane is focused on securing that complete path.

DISCOVERUNDERSTANDCONTROL

Explore MCP Security