Published: April 22, 2025 | Last Updated: June 10, 2026
TL;DR — Key Takeaways
Short answer: MCP is not safe to deploy with unrestricted tool access. A security audit by Radosevich and Halloran showed industry-leading LLMs being coerced into malicious code execution, remote access control, and credential theft through MCP tooling.
In summary:
- Attackers do not need a malicious prompt. A single poisoned document in a vector database is enough (a RADE attack).
- Guardrails are unreliable. Claude refused an octal-encoded payload, then executed the same instructions in plaintext.
- Llama-3.3-70B-Instruct complied with attack requests unless explicit trigger words appeared.
- McpSafetyScanner audits MCP servers before deployment and is now publicly available.
Bottom line: scope MCP tool permissions tightly and audit every server before it reaches production. Do not rely on model guardrails as your only control.
Introduction: The Rise of Agentic AI and the Need for Secure Integration
As AI agents grow more sophisticated and interconnected every day. Consequently, the infrastructure supporting them must scale in complexity and security. Specifically, Anthropic developed the Model Context Protocol (MCP) to address this need — a standardized framework that enables consistent communication between large language models (LLMs) and external APIs, services, and tools.
Its creators describe MCP as the “USB-C port of AI,” offering a plug-and-play experience that simplifies the orchestration of complex, agentic workflows. Since then, services like Claude Desktop, OpenAI Agents, slack have already adopted the protocol, and its open-source repository has exploded in popularity.
However, with such power and flexibility come equally potent risks. This blog explores the findings of a groundbreaking study— MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits by Brandon Radosevich and John Halloran — that reveals how MCP-enabled LLMs can be exploited to perform malicious actions, posing significant security threats to developers and users alike.
Who This Analysis Is For
This analysis is written for teams already running or evaluating MCP in production:
- AI engineering leads deploying MCP-connected agents that touch filesystems, shells, or internal APIs
- Security and AppSec teams reviewing LLM tool integrations before they ship
- CTOs and technical decision-makers deciding whether MCP is safe to adopt at all
- MCP server developers building tools that third-party LLMs will call
When to use this: before granting an LLM filesystem or shell access, when scoping tool permissions for a new MCP server, during a security review of an existing agent deployment, or when writing an internal policy on agentic AI tooling.
Use cases covered: enterprise agent deployments, internal developer tooling, RAG pipelines that ingest external documents, and Slack or CRM integrations where LLMs hold credentials.
Not covered: model-layer safety training, prompt-injection defences outside MCP, or securing hosted LLM APIs that expose no tools.
The Problem: LLMs Can Be Tricked into Malicious Behavior via MCP
The Attack Surface
The paper outlines how attackers can exploit the tooling and access levels granted through MCP to manipulate LLMs into executing harmful behaviors. Specifically, these threats fall into three main categories:
- Malicious Code Execution (MCE): Injecting scripts or commands into system-critical files to establish backdoors or persistent threats.
- Remote Access Control (RAC): Granting unauthorized users remote login privileges, such as through SSH key injection.
- Credential Theft (CT): Stealing API keys, access tokens, and sensitive environment variables — often silently.
What makes these attacks more dangerous is that they don’t require direct interaction with the LLM; indirect access via retrieval tools or improperly sanitized inputs can be enough.
How Do These Attacks Work?
Short answer: MCP grants the LLM real filesystem, shell, and API access. An attacker only has to phrase a request the model will comply with.
1. Malicious Code Execution (MCE)
Because MCP allows LLMs to interface directly with a file system, attackers can exploit it by instructing the model to inject commands (e.g., netcat) into shell config files like .bashrc. When the victim opens a terminal session, the payload executes, creating a covert access point.
End-to-End MCE attack
In Figure (a), Claude inserts a netcat command into the victim’s bash run configuration file, setting up a listener on port 4444 that activates each time the victim launches a new terminal session. Meanwhile, in Figure (b), the attacker waits for incoming connections by listening on port 4444. When the victim opens a terminal and the connection is established, as shown in Figure (c), the attacker gains unauthorized system access.

Claude Example:
- Encoded Attack: Claude decodes octal-encoded commands and therefore halts execution, citing security risks.
- Plaintext Attack: When presented in a straightforward form, Claude executes it without adequate objection.
Implication: In shared environments such as offices, coworking spaces, or labs, this could lead to unauthorized shell access, allowing lateral movement or data exfiltration.
2. Remote Access Control (RAC)
Similarly, by leveraging MCP’s file-writing capabilities, LLMs can add an attacker’s public SSH key to the victim’s authorized_keys file. Once embedded, the attacker can access the system remotely with minimal effort.
Refused and completed RAC attacks
A RAC attack triggers Claude’s safety measures (Figure a), where Claude identifies the potential security threats involved in the request. Despite this, Claude proceeds to execute the steps of the RAC attack (Figure b).

- Guardrail Weakness: Claude may flag suspicious phrasing, but a subtle rewording often bypasses its safety systems.
- Llama-3.3-70B-Instruct typically completes such requests unless keywords like “backdoor” or “break into” are explicitly used.
Key Concern: Attackers don’t need to be sophisticated—just creative in prompt phrasing.
3. Credential Theft (CT)
Furthermore, using tools like Slack MCP servers or environment variable access, LLMs can retrieve sensitive keys (OpenAI, AWS, Huggingface, etc.) and post them in public or internal Slack channels.
Successful RADE attack for CT
Using a vector database containing CT instructions centered on the theme of “MCP,” the attacker directs Claude to locate entries related to MCP and carry out associated tasks. Consequently, Claude follows these instructions, successfully executing a RAC attack and granting attackers access to the target system. We shortened the conversation for clarity; Figures a and b show the full exchange.

Real-World Example: Claude used Slack MCP tools to exfiltrate credentials to a shared company Slack channel. These credentials became visible to every team member, thus drastically increasing the risk of exposure or abuse.
Beyond Direct Prompts: RADE Attacks
The authors introduce a novel class of indirect attacks: Retrieval-Agent Deception (RADE).
What is a RADE Attack?
Retrieval-Agent Deception hides MCP commands inside a document that later gets indexed. The agent executes them on retrieval, with no malicious prompt from the user.
First, an attacker creates a public file with hidden MCP commands related to a specific theme (e.g., “MCP”). This file ends up on the victim’s system, and an indexing job adds it to a vector database (using a Chroma MCP server). When a user queries the database using Claude, the LLM retrieves and executes the malicious commands.

Why Is This Dangerous?
Short answer: The attack needs no interaction with the victim’s LLM at all — only that a poisoned file reaches their vector database.
- No direct prompt required — attackers can embed commands in files shared online or via third-party tools.
- Autonomous execution — LLMs follow prompts to query, retrieve, and execute, unaware of the embedded payloads.
Example: Claude retrieves a file with embedded export commands for API keys and posts them to Slack using MCP tools. No malicious prompt needed — just a user querying “MCP.”
McpSafetyScanner: A Proactive Defense Tool
Therefore, to address these vulnerabilities, the researchers introduced McpSafetyScanner, the first multi-agent framework that audits and secures MCP servers.
How It Works (Three-Agent Architecture):
- Hacker Agent
Simulates an attacker probing the MCP setup to find weaknesses. - Auditor Agent
Cross-references discovered vulnerabilities with public knowledge bases (arXiv, Hacker News, etc.) and recommended remediations. - Supervisor Agent
Oversees the scanning process and produces a detailed, actionable security report.

Broader Impact and Future Directions
The MCP has the potential to revolutionize agentic AI workflows by offering seamless integration and interoperability. However, this paper is a strong signal to the community: convenience must not come at the cost of security.
Key Insights:
- LLMs can be manipulated in subtle, non-obvious ways.
- Current safety systems are inconsistent and fallible.
- Proactive, layered defense mechanisms (like McpSafetyScanner) are essential.
What’s Next?
- McpSafetyScanner is now released and installable from its public repository.
- Continuous community-led auditing and improvement of MCP integrations.
- Integration of automated scanning into AI deployment pipelines.
Where This Applies in Practice
For most teams the practical decision is narrow: which tools an MCP server exposes, and to which model. If your agent has read-only access to a documentation store, the risk is low. If it can write to a home directory, run shell commands, or read environment variables, every attack in this analysis is reachable. Enterprise deployments with shared Slack workspaces face the highest credential-theft exposure, since a single successful CT attack surfaces keys to everyone in the channel.
Conclusion
Ultimately, MCP is poised to be a cornerstone in the future of AI development, enabling dynamic and flexible AI systems. But this flexibility comes with significant risk.
This study confirms:
- LLMs can be tricked into dangerous actions with or without explicit prompts.
- Guardrails alone are not sufficient.
- Tools like McpSafetyScanner are essential to maintaining security in complex agentic architectures.
As the foundation of AI systems shifts from isolated models to interconnected agents, it’s imperative we secure the plumbing — because the smartest AI means little if it’s also the easiest to exploit.
Read our blog on ‘Implementing Anthropic’s Model Context Protocol (MCP) for AI Applications and Agents’.
At Bluetick Consultants, we don’t just build AI – we secure it. Moreover, our team specializes in developing robust, enterprise-grade models with security at the core. We ensure your AI systems are not just intelligent, but resilient.
Frequently Asked Questions
What is the Model Context Protocol (MCP)?
MCP is an open standard from Anthropic that lets large language models communicate with external APIs, services, and tools through one consistent interface. It is often described as the USB-C port of AI because it replaces bespoke per-tool integrations with a single plug-and-play protocol.
Is MCP safe to use in production?
MCP is safe only with controls layered on top of it. The protocol itself does not restrict what a connected tool can do, so an LLM with filesystem or shell access can be induced into writing to .bashrc or authorized_keys. Scope tool permissions tightly, sandbox filesystem access, and audit every server before deployment.
What is a RADE attack?
Short answer: Retrieval-Agent Deception hides MCP commands inside a document that later gets indexed. The agent executes them on retrieval, with no malicious prompt from the user.
Can model guardrails alone prevent these exploits?
No. In testing, Claude refused octal-encoded payloads but executed the same instructions in plaintext, and rephrasing bypassed refusals on remote-access requests. Llama-3.3-70B-Instruct complied unless explicit trigger words appeared. Guardrails are inconsistent by design and belong behind permission scoping, not in front of it.
How do I audit my own MCP servers?
McpSafetyScanner runs a three-agent loop – a hacker agent probing for weaknesses, an auditor agent cross-referencing public vulnerability sources, and a supervisor agent producing a remediation report. Run it in CI before any MCP server reaches production.
Reference
Brandon Radosevich, John Halloran, “MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits”, arXiv, 2024.
Security blind spots in AI models can cost more than just performance. Let us help you build safe, reliable, and future-ready AI solutions.