Model Context Protocol (MCP) Security: Risks, Controls and Best Practices

The Model Context Protocol (MCP) is changing how AI applications connect with external tools, data sources and business systems. Instead of building separate integrations for every AI workflow, organisations can use MCP to connect AI applications with databases, files, APIs, search tools and other services.

That flexibility also creates a new security challenge.

MCP security risks can arise when AI systems are allowed to discover and invoke tools, access sensitive information or perform actions through connected services. Risks can include excessive permissions, tool poisoning, prompt injection, insecure MCP servers, token misuse, supply-chain vulnerabilities and data leakage.

The issue is becoming more important as MCP adoption moves into enterprise environments. The U.S. National Security Agency published security design guidance for MCP in May 2026, highlighting risks involving dynamic tool invocation, trust boundaries, context sharing, access control, validation and monitoring.

For businesses, the key question is not simply “Is MCP secure?”

It is:

“How should we secure the AI, tools, data, identities and connections that operate through MCP?”

This guide explains the main MCP security risks and the controls organisations should consider before deploying MCP in production.

What Is Model Context Protocol (MCP)?

Model Context Protocol, commonly called MCP, is an open protocol for connecting AI applications with external systems.

The official MCP documentation describes it as a standard way for AI applications to connect with data sources, tools and workflows. For example, an AI application can connect to files, databases, calendars, search services or business applications through MCP.

Read the official Model Context Protocol documentation

A simplified MCP architecture looks like this:

User → AI Application → MCP Client → MCP Server → Tool / Data / API

For example, imagine an employee asks an AI assistant:

“Find our latest sales report, compare it with last quarter and prepare a summary.”

The AI application may use an MCP server to connect to a document repository or database, retrieve information and return the results to the user.

The same architecture can become much more powerful when the connected tools can also write data, send messages, modify records or trigger workflows.

That is where security becomes critical.

Why Does MCP Create New Security Risks?

Traditional software integrations generally follow predefined application logic.

MCP changes the interaction model by allowing AI applications and agents to discover and use tools dynamically.

The AI may determine which available tool is relevant and what parameters should be supplied.

This creates several additional security considerations:

• What tools can the AI discover?
• Which tools can it use?
• What data can those tools access?
• What permissions does the MCP server have?
• Can the tool modify or delete information?
• Can one tool influence another?
• Can information returned by a tool change the AI’s subsequent behaviour?
• Can administrators trace exactly what happened?

The NSA has highlighted dynamic tool invocation, implicit trust relationships and context sharing as important security concerns in MCP environments.

Therefore, MCP security cannot be treated as only an API-security problem.

It requires consideration of the entire AI-to-tool workflow.

MCP Security Risks Businesses Should Understand

1. Excessive Permissions

One of the most important MCP security risks is giving an AI system more access than it actually needs.

Consider an AI assistant connected to a company’s document management system.

The assistant only needs to read approved sales reports.

However, its credentials allow it to:

• Read all company documents
• Modify files
• Delete files
• Access confidential HR records
• Share documents externally

The AI may not intentionally misuse these permissions.

However, if an attacker manipulates the AI workflow or compromises the connected tool, excessive permissions can increase the potential impact.

A better approach is least-privilege access.

If an agent only needs read access, do not provide write or delete permissions.

If it only needs access to one repository, do not provide access to the entire organisation.

OWASP’s MCP security guidance recommends minimum permissions, narrow credentials and scoped access for MCP servers and tools.

2. Tool Poisoning

AI systems do not only process the output of a tool.

They may also process the tool’s name, description, parameters and returned information.

This creates a new attack surface.

For example, suppose an organisation approves an MCP tool called:

“Customer Report Search”

The tool initially behaves as expected.

Later, its description or returned content changes and contains instructions designed to influence the AI, such as directing it to send retrieved information to another service.

The user may not notice the change.

This type of attack is often described as tool poisoning.

OWASP identifies tool poisoning, tool shadowing and changes to previously trusted tool definitions as important MCP security concerns.

Organisations should therefore avoid treating a tool as permanently trusted simply because it was approved once.

3. Prompt Injection Through Tool Results

Prompt injection is not limited to a user typing a malicious prompt.

An instruction can also appear inside content retrieved by an AI system.

For example:

Employee asks:
“Summarise this customer document.”

The document contains hidden or malicious instructions.

The AI retrieves the document through an MCP-connected tool and processes those instructions as part of its context.

If the AI then has access to email, databases or external services, the injected instructions could influence subsequent actions.

This creates a dangerous chain:

External content → MCP tool → AI context → another tool → business action

OWASP recommends treating tool outputs as untrusted input rather than automatically trusting them.

4. Confused Deputy Problems

Another important MCP security risk occurs when an MCP server has broader privileges than the user or application requesting an action.

Imagine an employee has permission to view selected customer information.

The MCP server, however, has access to the entire customer database.

If the server performs actions using its own broad privileges rather than enforcing the user’s actual permissions, the AI workflow can become a path to unauthorised access.

This is known as a confused deputy problem.

The current MCP security documentation specifically discusses confused-deputy risks and the need for proper authorisation and consent controls.

5. Insecure MCP Servers

An MCP server can introduce traditional application-security vulnerabilities as well.

Poor authentication, weak input validation, insecure configuration, exposed endpoints or vulnerable dependencies can turn an MCP server into an entry point into the wider environment.

Microsoft reported cases of remotely exposed MCP servers being deployed without authentication and highlighted the risk of insecure MCP configurations.

This is an important distinction:

MCP does not automatically make an application secure.

The security of an MCP deployment still depends on how clients, servers, authentication, authorisation, tools, infrastructure and data are implemented.

6. Token and Authorisation Risks

MCP deployments may use OAuth-based authorisation and other authentication mechanisms.

However, organisations still need to validate:

• Who issued the token?
• Which MCP server was the token issued for?
• What permissions does it provide?
• How long is it valid?
• Can it be reused?
• How is it revoked?
• Is the token being passed to another service?

The current MCP security guidance specifically addresses token passthrough and requires MCP servers not to accept tokens that were not explicitly issued for the MCP server.

The July 2026 MCP specification also introduced additional authorisation hardening, including issuer validation and changes to client registration.

7. Supply Chain Risks

Many organisations may obtain MCP servers from open-source repositories, registries or third-party vendors.

That creates a familiar software supply-chain question:

Can the organisation trust the component it is installing?

Risks can include:

• Malicious packages
• Compromised dependencies
• Typosquatting
• Abandoned projects
• Vulnerable libraries
• Unexpected changes to tool behaviour
• Unverified third-party code

The NSA recommends choosing supported MCP projects where possible and applying code-audit processes when evaluating MCP server projects.

MCP should therefore be included in the organisation’s existing third-party and software supply-chain security processes.

8. Data Leakage Between Tools

An AI application may connect to multiple MCP servers.

For example:

MCP Server A: Customer database
MCP Server B: Email
MCP Server C: Public web search
MCP Server D: Cloud storage

The security risk increases if information from one trusted system can unexpectedly flow into another.

Sensitive customer information could potentially become part of a request to an external service.

This is why organisations should establish clear trust boundaries and data-flow controls between MCP servers.

The NSA recommends treating different components and trust zones separately and aligning tools with appropriate data-classification zones.

A Practical Example of an MCP Security Failure

Consider an organisation that deploys an AI assistant for its sales team.

The assistant can:

1. Search the CRM.
2. Read customer records.
3. Draft emails.
4. Send emails.
5. Search public websites.

The organisation approves the assistant because it improves productivity.

However, the configuration gives the assistant broad access to customer records and unrestricted email permissions.

Now imagine that a malicious instruction appears inside a webpage retrieved during a research task.

The AI processes the content and attempts to follow the instruction.

If the organisation has not implemented appropriate controls, the agent could potentially combine:

Web content + CRM access + email access

into a single workflow.

The individual components may appear legitimate.

The security problem comes from the combination of capabilities.

This is why MCP security requires organisations to examine not only individual tools but also how connected tools can interact.

How to Secure MCP in Business Environments

1. Create an MCP Inventory

Before deploying MCP at scale, organisations should know where it is being used.

Record:

This connects MCP security with the broader AI inventory and governance process already recommended for responsible AI management.

2. Apply Least Privilege

Give every MCP server and tool only the access it requires.

For example:

Better:

Sales-report MCP → Read-only access → Sales reporting database

Riskier:

Sales-report MCP → Full database access → Read/write/delete permissions

Where possible, organisations should use narrow scopes, separate credentials and short-lived access mechanisms.

Least privilege should apply at several levels:

User → AI application → MCP server → Tool → Data

3. Verify Tool Definitions

Do not approve a tool only because its name looks safe.

Security teams should review:

• Tool descriptions
• Input parameters
• Output formats
• Permissions
• External connections
• Dependencies
• Changes after approval

Tool definitions should be treated as part of the security boundary.

OWASP specifically recommends inspecting tool descriptions and schemas and monitoring changes to previously trusted definitions.

4. Authenticate and Authorise Every Sensitive Connection

Remote MCP endpoints should not be exposed without appropriate authentication and authorisation.

Security teams should verify:

• Client identity
• Server identity
• Token audience
• Token validity
• Requested scopes
• User permissions
• Consent
• Access duration

The current MCP security documentation includes specific controls around token validation, OAuth flows, consent and authorisation.

5. Validate Inputs and Outputs

Every tool call should be treated as potentially untrusted.

Validate:

• Parameters
• Data types
• File paths
• URLs
• Query values
• Payload sizes
• Returned data

For high-risk operations, organisations should also consider whether the requested action matches the user’s authorised purpose.

The NSA recommends validating MCP tool parameters against defined schemas, expected ranges and the execution context.

6. Require Human Approval for High-Risk Actions

Not every MCP action needs human approval.

However, organisations should consider approval before actions such as:

• Sending external emails
• Deleting records
• Changing production systems
• Publishing information
• Making financial transactions
• Accessing highly sensitive information
• Changing security configurations

A useful approach is:

Low risk → Automated

Medium risk → Monitored

High risk → Human approval

The exact thresholds should depend on the organisation’s risk assessment.

7. Sandbox MCP Servers

Local MCP servers can have direct access to the host system.

Therefore, organisations should consider:

• Containers
• Application sandboxing
• Restricted file-system access
• Network restrictions
• Process isolation
• Limited operating-system privileges

The MCP security guidance recommends restricting local server capabilities and using sandboxing where appropriate.

8. Monitor and Audit MCP Activity

Security monitoring should capture enough information to reconstruct significant actions.

Depending on the environment, logs can include:

• User identity
• AI application
• MCP server
• Tool invoked
• Parameters
• Timestamp
• Authentication result
• Approval status
• Result
• Destination
• Errors

This creates an audit trail for incident response and compliance investigations.

The NSA specifically highlights robust audit logging and monitoring as important for MCP environments.

MCP Security Checklist for Businesses

Use this checklist before moving an MCP deployment into production:

How MCP Security Fits Into AI Governance

MCP security should not sit outside an organisation’s broader AI governance programme.

Instead, it should connect with existing governance processes covering:

• AI risk assessment
• Information security
• Data protection
• Third-party risk
• Access management
• Software security
• Incident management
• Business continuity
• Human oversight

This is where an organisation’s broader AI governance framework becomes important.

Your AI governance programme can establish who owns AI systems, how risks are assessed and how controls are monitored. MCP security then provides a more specific control layer for AI-to-tool and AI-to-data interactions.

Read more about AI Governance: A Practical Guide to Responsible AI and the AI Governance Framework in India.

How ISO/IEC 42001 Can Support MCP Governance

ISO/IEC 42001 provides a management-system framework for organisations that develop, provide or use AI systems.

It can help organisations establish structured processes for AI governance, risk management, responsibilities, monitoring and continual improvement.

For an organisation using MCP, ISO/IEC 42001 can support the governance layer around questions such as:

• Which AI applications use MCP?
• What are their intended purposes?
• What risks do their connected tools create?
• Who owns the AI system?
• How are controls documented?
• How are incidents handled?
• How are risks reviewed over time?

ISO/IEC 42001 should not be presented as a technical MCP security standard. Instead, it can provide a broader AI management framework within which MCP-related risks and controls can be identified and managed.

For organisations developing a formal Artificial Intelligence Management System, see ISOQAR India’s ISO 42001 Certification in India guide.

MCP Security and Zero Trust

MCP also connects naturally with Zero Trust security.

The basic Zero Trust principle is to avoid granting trust simply because a user, application or system is already inside an environment.

That principle is relevant to MCP because an AI application may interact with:

• External tools
• APIs
• Databases
• Cloud services
• Enterprise applications
• Third-party MCP servers

Instead of asking:

“Is this MCP server trusted?”

organisations should ask:

“What is this MCP server allowed to access, under what conditions and for how long?”

This approach supports least privilege, continuous verification and controlled access.

You can explore the broader security model in ISOQAR India’s Zero Trust Security guide.

MCP Security, ISO/IEC 27001 and Digital Trust

MCP security also intersects with information-security management.

ISO/IEC 27001 can support the broader security environment around:

• Access control
• Information classification
• Supplier security
• Risk assessment
• Incident management
• Asset management
• Secure development
• Monitoring

For organisations connecting AI systems to sensitive information, MCP should therefore be considered as part of the wider digital trust and security architecture, rather than as an isolated AI feature.

Organisations can also review their wider Digital Trust & Security services when assessing information-security, AI governance, privacy and cybersecurity requirements.

What Should Businesses Do Before Deploying MCP?

A practical implementation sequence can be:

Step 1: Discover

Identify existing and planned MCP clients, servers, tools and connections.

Step 2: Classify

Determine what data and systems each MCP connection can access.

Step 3: Assess

Evaluate authentication, authorisation, permissions, dependencies and potential attack paths.

Step 4: Restrict

Apply least privilege, allowlists, sandboxing and appropriate network controls.

Step 5: Approve

Define which actions require user consent or human approval.

Step 6: Monitor

Log tool calls, access events, errors and unusual behaviour.

Step 7: Test

Test for prompt injection, tool poisoning, excessive permissions, data leakage and insecure configurations.

Step 8: Review

Reassess the MCP environment when tools, permissions, vendors or business purposes change.

This lifecycle approach is important because MCP environments can evolve quickly. The MCP project released its 2026-07-28 specification with changes including a stateless protocol core and additional authorisation hardening.

Conclusion

MCP can make AI applications significantly more useful by connecting them with the tools and data they need to perform real tasks.

However, greater connectivity also creates greater responsibility.

The most important MCP security risks are not limited to one vulnerability or configuration setting. They can emerge from the interaction between AI models, tool definitions, permissions, identities, data, external services and human approvals.

Businesses should therefore avoid treating MCP as simply another integration technology.

Instead, secure MCP deployments should be designed around:

Least privilege.

Strong authentication and authorisation.

Trusted and monitored tools.

Input and output validation.

Human approval for high-risk actions.

Sandboxing and isolation.

Supply-chain security.

Continuous monitoring and auditability.

As AI agents become more connected to enterprise systems, the security boundary is expanding from the model to the entire workflow.

The organisations that prepare for that change can adopt AI capabilities while maintaining stronger control over data, access, accountability and digital trust.