New research shows the Model Context Protocol (MCP)—the interface that lets large-language-model (LLM) agents call external tools—can be hijacked through “tool-poisoning” attacks that succeed more than one-third of the time. Across 20 popular agents the average success rate was 36.5 %; the o1-mini model fell in 72.8 % of attempts, while Claude-3.7-Sonnet refused malicious calls under 3 % of the time. For anyone deploying LLM agents that rely on MCP, the findings turn a convenience feature into a supply-chain risk that can be exploited before any code ever runs.
Why MCP matters to developers today
MCP standardises how agents discover, register, and invoke tools such as file readers, web APIs, or email senders. By publishing a tool’s name, input schema and a short description, a server makes the capability available to any client that understands the protocol. The promise is simple: an agent can look up a tool, send a request, and receive a response without hard-coding each integration.
That flexibility also creates an implicit trust relationship. The specification tells clients to treat tool descriptions as trustworthy only if they come from a server the client already trusts. The new study shows that this trust can be abused.
How tool-poisoning differs from ordinary prompt injection
Traditional prompt injection inserts malicious instructions into the text that the model generates or receives at runtime. The model then follows those instructions because they appear in the same token stream as the user’s request.
Tool-poisoning, by contrast, hides the payload in the tool’s metadata—the name, description, or parameter schema that registers before any agent call. When an agent later selects the tool, it treats the description as part of the “trusted context” and may follow the hidden instruction without any runtime check. Because the injection occurs during registration, there is no point in the execution flow where a model can flag the payload as suspicious.
Scale of the problem – the MCPTox benchmark
The researchers behind MCPTox (arXiv:2508.14925) evaluated 45 MCP servers offering a total of 353 distinct tools. They scripted attacks against 20 widely used LLM agents, measuring how often the agents executed the poisoned tool call.
- Average success rate: 36.5 %
- Peak success: o1-mini at 72.8 %
- Best refusal: Claude-3.7-Sonnet, still under 3 %
The numbers reveal a stark reality: most agents do not refuse a poisoned call because the request looks like a legitimate tool invocation. The agents assume the tool description is a benign piece of documentation, not a vector for code execution.
Why agents rarely refuse poisoned calls
OWASP’s LLM01 guideline explains that LLMs do not differentiate between instructions and data—both are just tokens in a sequence. When a tool description says “send an email to admin@example.com with the subject ‘Update’”, the model cannot tell whether that line is a harmless comment or an instruction it should obey later. Consequently, the model treats the description as part of the trusted environment and follows any embedded command when the tool is invoked.
Existing guidance and its gaps
The MCP specification already advises clients to treat tool descriptions as untrusted unless they originate from a trusted server, and to keep a human in the loop for high-impact calls. The benchmark shows that many real-world deployments ignore or loosely interpret these recommendations.
Concrete steps developers can take today
- सर्व्हर आवृत्त्या पिन करा (Pin server versions) – बदलत्या टॅगऐवजी एका विशिष्ट, अपरिवर्तनीय (immutable) सर्व्हर इमेज किंवा हॅशचा संदर्भ द्या. यामुळे डिप्लॉयमेंटनंतर एखादा अटॅकर स्वच्छ रजिस्ट्री बदलून ती दूषित (poisoned) रजिस्ट्री करू शकत नाही.
- रिकाम्या अलाऊलिस्टपासून (allowlist) सुरुवात करा – केवळ स्पष्टपणे तपासलेले (vetted) टूल्सच सक्षम करा. यादीत नसलेले सर्व काही डीफॉल्टनुसार ब्लॉक केले जाते.
- स्टेट-बदलणाऱ्या (state-changing) टूल्सवर नियंत्रण ठेवा – डेटा लिहिणारे, पाठवणारे किंवा हटवणारे कोणत्याही टूलसाठी अतिरिक्त मंजुरीची आवश्यकता ठेवा. स्कीमामध्ये (schema) “read-only” आणि “write-capable” क्षमता वेगळ्या करा.
- उच्च-प्रभाव असलेल्या कॉल्ससाठी मानवी मंजुरी जोडा – बाह्य प्रणालींवर परिणाम करू शकणाऱ्या कृतींसाठी (उदा. ईमेल पाठवणे, कमांड्स कार्यान्वित करणे, फाइल्समध्ये बदल करणे), कॉल पाठवण्यापूर्वी मानवी रिव्ह्यूअरला विचारणा करा.
- प्रत्येक टूल इन्व्होकेशनचा (tool invocation) लॉग ठेवा – टूलचे नाव, आर्ग्युमेंट्स, टाइमस्टॅम्प आणि मूळ एजंटची नोंद करा. एक अपरिवर्तनीय ऑडिट ट्रेल (audit trail) पोस्ट-मॉर्टम विश्लेषण शक्य करते आणि ज्या अटॅकर्सना माहित आहे की त्यांच्या कृती दृश्यमान होतील, त्यांना रोखू शकते.
MCP सप्लाय चेनला मानक सॉफ्टवेअर-डेव्हलपमेंट पद्धतींशी सुसंगत करण्यासाठी, प्रत्येक टूलचे वर्णन सोर्स कोडप्रमाणे हाताळा—ज्याला लिंटिंग (linting), कोड रिव्ह्यू आणि व्हर्जन कंट्रोल लागू असेल.
प्रतिवाद आणि उघडे प्रश्न
तथापि, बेंचमार्क असे दर्शवते की अभ्यासातील सर्वात प्रगत मॉडेलने देखील तीन टक्क्यांपेक्षा कमी दूषित (poisoned) कॉल्स नाकारले. फाईन-ट्यूनिंगमुळे (Fine-tuning) शोधण्याची क्षमता सुधारू शकते, परंतु मॉडेलने कधीही न पाहिलेल्या स्कीमा फील्ड्समध्ये (schema fields) समाविष्ट केलेल्या नवीन पेलोड्सपासून (payloads) ते सुरक्षिततेची खात्री देऊ शकत नाही.
पुढे काय पाहावे
- उदयोन्मुख मानके (Emerging standards) – टूल स्कीमावर क्रिप्टोग्राफिक स्वाक्षरी (cryptographic signatures) अनिवार्य करण्यासाठी LLM सुरक्षा समुदायाकडून येणाऱ्या प्रस्तावांकडे लक्ष द्या.
- टूल-रजिस्ट्री हार्डनिंग (Tool-registry hardening) – विक्रेते सेवा म्हणून अपरिवर्तनीय, रीड-ओन्ली (read-only) रजिस्ट्र्या प्रदान करण्यास सुरुवात करू शकतात, ज्यामुळे अटॅक सरफेस (attack surface) कमी होईल.
- मॉडेल-स्तरीय संरक्षण (Model-level defenses) – संशयास्पद टूल मेटाडेटा फ्लॅग करणाऱ्या प्रॉम्प्टिंग तंत्रांवर किंवा सहाय्यक मॉडेल्सवरील संशोधन होस्ट-साइड संरक्षकाला पूरक ठरू शकते.
व्यावहारिक निष्कर्ष स्पष्ट आहे: कोणत्याही MCP-आधारित डिप्लॉयमेंटमध्ये थर्ड-पार्टी लायब्ररींना लागू केल्याप्रमाणेच टूल वर्णनांचे ऑडिट केले पाहिजे. सप्लाय-चेन जोखमीकडे दुर्लक्ष केल्यास एक सोयीस्कर ॲब्स्ट्रॅक्शन (abstraction) शांत बॅकडोअरमध्ये (backdoor) रूपांतरित होऊ शकते. सर्व्हर पिन करून, कमीत कमी विशेषाधिकार असलेल्या अलाऊलिस्टला (least-privilege allowlists) लागू करून, स्टेट-बदलणाऱ्या कृतींवर नियंत्रण ठेवून, आवश्यक तिथे मानवांना सामील करून घेऊन आणि एक अपरिवर्तनीय लॉग ठेवून, डेव्हलपर्स त्यांचे LLM एजंट्स नकळत गुन्हेगार (unwilling accomplices) बनण्यापासून वाचवू शकतात.