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) – อ้างอิงถึง image หรือ hash ของเซิร์ฟเวอร์ที่เฉพาะเจาะจงและไม่สามารถเปลี่ยนแปลงได้ แทนที่จะใช้ tag ที่มีการเปลี่ยนแปลงตลอดเวลา วิธีนี้จะช่วยป้องกันไม่ให้ผู้โจมตีสลับ registry ที่สะอาดเป็น registry ที่ถูกวางยา (poisoned) หลังจากที่มีการปรับใช้ (deployment) ไปแล้ว
- เริ่มต้นด้วย allowlist ที่ว่างเปล่า – เปิดใช้งานเฉพาะเครื่องมือที่ผ่านการตรวจสอบอย่างละเอียดแล้วเท่านั้น สิ่งใดก็ตามที่ไม่อยู่ในรายการจะถูกบล็อกโดยค่าเริ่มต้น
- ควบคุมเครื่องมือที่เปลี่ยนสถานะ (Gate state-changing tools) – กำหนดให้ต้องมีการอนุมัติเพิ่มเติมสำหรับเครื่องมือใดก็ตามที่มีการเขียน ส่ง หรือลบข้อมูล โดยแยกความสามารถแบบ "อ่านอย่างเดียว" (read-only) ออกจากความสามารถแบบ "เขียนได้" (write-capable) ใน schema
- เพิ่มการอนุมัติโดยมนุษย์สำหรับการเรียกใช้งานที่มีผลกระทบสูง – สำหรับการดำเนินการที่อาจส่งผลกระทบต่อระบบภายนอก (เช่น การส่งอีเมล, การรันคำสั่ง, การแก้ไขไฟล์) ให้มีการแจ้งเตือนผู้ตรวจสอบที่เป็นมนุษย์ก่อนที่จะมีการส่งคำสั่งนั้น
- บันทึกการเรียกใช้เครื่องมือทุกครั้ง (Log every tool invocation) – บันทึกชื่อเครื่องมือ, อาร์กิวเมนต์ (arguments), เวลา (timestamp) และเอเจนต์ต้นทาง การมีร่องรอยการตรวจสอบ (audit trail) ที่ไม่สามารถแก้ไขได้จะช่วยให้การวิเคราะห์หลังเกิดเหตุ (post-mortem analysis) ทำได้จริง และสามารถยับยั้งผู้โจมตีที่รู้ว่าการกระทำของตนจะถูกตรวจพบได้
ปฏิบัติต่อคำอธิบายเครื่องมือแต่ละอย่างเหมือนกับซอร์สโค้ด โดยต้องผ่านการทำ linting, การรีวิวโค้ด (code review) และการควบคุมเวอร์ชัน (version control) เพื่อให้ห่วงโซ่อุปทาน (supply chain) ของ MCP สอดคล้องกับแนวทางปฏิบัติมาตรฐานในการพัฒนาซอฟต์แวร์
ข้อโต้แย้งและคำถามที่ยังไม่มีคำตอบ
อย่างไรก็ตาม ผลการทดสอบ (benchmark) แสดงให้เห็นว่าแม้แต่โมเดลที่ล้ำสมัยที่สุดในการศึกษานี้ก็ปฏิเสธการเรียกใช้งานที่ถูกวางยา (poisoned calls) ไม่ถึงร้อยละสาม การทำ Fine-tuning อาจช่วยปรับปรุงการตรวจจับได้ แต่ไม่สามารถรับประกันความปลอดภัยจาก payload รูปแบบใหม่ที่ฝังอยู่ในฟิลด์ของ schema ซึ่งโมเดลไม่เคยเห็นมาก่อนได้
สิ่งที่ควรจับตามองต่อไป
- มาตรฐานที่กำลังเกิดขึ้น (Emerging standards) – จับตามองข้อเสนอจากชุมชนความปลอดภัยของ LLM ที่กำหนดให้ต้องมีการลงลายมือชื่อทางคริปโทกราฟิก (cryptographic signatures) ใน tool schemas
- การเสริมความแข็งแกร่งให้กับ Tool-registry – ผู้ให้บริการอาจเริ่มนำเสนอ registry แบบอ่านอย่างเดียวที่ไม่สามารถแก้ไขได้ในรูปแบบบริการ (as a service) เพื่อลดพื้นที่การโจมตี (attack surface)
- การป้องกันในระดับโมเดล – การวิจัยเกี่ยวกับเทคนิคการเขียน prompt หรือโมเดลเสริม (auxiliary models) ที่ช่วยแจ้งเตือน metadata ของเครื่องมือที่น่าสงสัย อาจช่วยเสริมการป้องกันในฝั่งโฮสต์ (host-side safeguards) ได้
บทสรุปในทางปฏิบัติมีความชัดเจนคือ: การปรับใช้ใดๆ ที่อิงตาม MCP ควรตรวจสอบคำอธิบายเครื่องมือด้วยความเข้มงวดในระดับเดียวกับการตรวจสอบไลบรารีจากภายนอก (third-party libraries) การละเลยความเสี่ยงด้านห่วงโซ่อุปทาน (supply-chain risk) จะเปลี่ยนการทำงานแบบนามธรรม (abstraction) ที่สะดวกสบายให้กลายเป็นประตูหลัง (backdoor) ที่เงียบเชียบ การกำหนดเวอร์ชันเซิร์ฟเวอร์ให้คงที่, การบังคับใช้ allowlist ตามหลักสิทธิ์ขั้นต่ำ (least-privilege), การควบคุมการดำเนินการที่เปลี่ยนสถานะ, การให้มนุษย์เข้ามามีส่วนร่วมเมื่อจำเป็น และการเก็บบันทึกที่ไม่สามารถแก้ไขได้ จะช่วยให้นักพัฒนาสามารถป้องกันไม่ให้ LLM agent กลายเป็นผู้สมรู้ร่วมคิดโดยไม่ตั้งใจ