While adoption of MCP as a standard protocol connecting AI with business systems is expanding, new attack techniques such as prompt injection, excessive permissions, and supply chain tampering have also been confirmed. In 2025, remote code execution (RCE) vulnerabilities were reported in MCP-related tools, making vigilance essential during implementation and operations.
This article organizes points necessary for implementation decisions and safe operations, based on the latest specifications and actual possible attack scenarios.
You may also want to read
What is MCP? A Guide to the Standard Protocol Connecting AI and Business Systems
Table of Contents
- Basic Understanding of MCP Implementation and Security
- Realistic Security Scenarios
- Key Points in Authentication and Authorization Design
- Server Selection and Implementation Checkpoints
- Operations Management Requirements and Avoiding Misconceptions
- Summary
Basic Understanding of MCP Implementation and Security
MCP is a mechanism that enables AI to connect with external services in a standardized way, but giving operational authority to AI increases risks alongside convenience. The specification is designed with OAuth 2.1 and Resource Indicators (RFC 8707) as premises, and operational rules such as minimum privileges, audit logs, and rate limiting are essential.
Realistic Security Scenarios
The following risks are anticipated for MCP servers and related tools. It’s important to understand these as examples directly connected to daily usage scenarios.
- External Transmission of Conversation History
LLM reads instructions hidden in MCP server tool descriptions and sends user conversation history to attackers.
Countermeasures: Use trusted servers, verify description text, always include confirmation UI for critical operations.
- Server Update Substitution
Initially harmless MCP server gets deletion commands or external transmission embedded in updates.
Countermeasures: Version pinning, change detection, thorough re-consent on updates.
- Impersonation Due to OAuth Design Flaws
OAuth tokens issued without specified audience, allowing attackers to use them for other services.
Countermeasures: Mandatory resource specification with RFC 8707, introduce short-lived tokens.
- Command Injection
Local MCP server passes input directly to OS commands, allowing arbitrary code execution.
Countermeasures: Input sanitization, safe API usage, sandbox execution.
- RCE (Remote Code Execution) Exploitation
Old version MCP Inspector has vulnerabilities, allowing command execution just by opening malicious sites.
Countermeasures: Update to latest version, don’t expose local tools externally.
Recognizing these risks and implementing appropriate countermeasures in daily operations leads to improved safety.
Key Points in Authentication and Authorization Design
When implementing MCP, the most critical attention is needed for OAuth and token handling. Design errors here can enable unauthorized operations disguised as legitimate users. Below are representative scenarios.
- Fix Token Destination with Resource Indicators (RFC 8707)
When tokens are issued with ambiguous “destinations,” attackers may be able to use the token for different services. For example, a token issued for file viewing might mistakenly work for another API (like a customer management system).
Countermeasures: Make the “resource” parameter defined in RFC 8707 mandatory to explicitly fix which services can use the token.
- Prevent Authority Abuse with PKCE Use and Re-consent
After obtaining OAuth consent once, if an attacker hijacks that session (session fixation or replay attack), additional operations can run without the person’s approval.
Countermeasures: Using PKCE (Proof Key for Code Exchange) means even if an attacker hijacks, they cannot generate the correct code and token issuance fails. Also, require “re-consent” for sensitive operations so users approve understanding the operation’s meaning.
- Prohibit Token Pass-through and Verify Audience
If an MCP server “relays tokens as-is to downstream services,” operations not originally permitted can be executed. For example, a token received by AI for email viewing might be used directly for cloud storage deletion operations.
Countermeasures: MCP servers must always verify “Is this token for me?” and “Does the audience (usage target) match?”, designed not to accept tokens for other services.
Server Selection and Implementation Checkpoints
When implementing MCP servers, it’s important to establish evaluation criteria at the connection destination selection stage rather than “connecting because it’s convenient.”
| Item | Confirmation Content |
|---|---|
| Provider | Official or proven developer, legitimate signature/distribution channel |
| Update Management | Version pinning and differential review, tampering detection mechanism |
| Communication | TLS required, certificate verification |
| Permissions | Minimum necessary scope, read-only priority |
| Execution | Local in sandbox, egress control |
| Logs | Detailed recording of who, what, when, where |
By documenting these criteria as operational rules and conducting periodic inventory and reviews even after implementation, you can nip the seeds of attacks and accidents early.
Operations Management Requirements and Avoiding Misconceptions
To safely utilize MCP, control in daily operations and avoiding common misconceptions are essential.
First, basic mechanisms to incorporate in operations design:
-
Pre-execution confirmation UI for humans to approve dangerous operations
-
Sanitize inputs and outputs to block suspicious arguments or outputs
-
Prevent runaway and cost increases with rate limiting and timeouts
-
Make logs auditable and set up anomaly detection alerts
-
Continue periodic updates and dependency library vulnerability monitoring
On the other hand, risks arising from misconceptions are not uncommon in implementation sites.
Assuming “safe because it uses OAuth” can leave room for unauthorized use if audience remains unspecified when tokens are issued. Overconfidence in “official tools are safe” can overlook actually reported remote code execution (RCE) vulnerabilities, making environments that neglect updates attack targets. Furthermore, thinking “prompt injection countermeasures are already done” can underestimate attacks via description text or user interfaces, leading to omission of final human confirmation.
By consciously pairing these technical measures with avoiding misconceptions, a foundation is established for confidently incorporating MCP into business operations.
Summary
MCP significantly advances business efficiency but simultaneously expands attack surface, making security design and operations essential. By thoroughly implementing basics such as specification compliance for authentication/authorization, minimum privileges, logs and human confirmation, and periodic updates, safe implementation is possible.
As a next step, we recommend inventorying currently connected servers and re-evaluating them based on the checklist shown here.