Nghiên cứu mới cho thấy Model Context Protocol (MCP)—giao diện cho phép các tác nhân mô hình ngôn ngữ lớn (LLM) gọi các công cụ bên ngoài—có thể bị chiếm quyền điều khiển thông qua các cuộc tấn công “đầu độc công cụ” (tool-poisoning) với tỷ lệ thành công hơn một phần ba số lần. Trên 20 tác nhân phổ biến, tỷ lệ thành công trung bình là 36,5%; mô hình o1-mini bị tấn công thành công trong 72,8% số lần thử, trong khi Claude-3.7-Sonnet từ chối các lệnh gọi độc hại trong chưa đầy 3% số lần. Đối với bất kỳ ai đang triển khai các tác nhân LLM dựa trên MCP, những phát hiện này đã biến một tính năng tiện lợi thành một rủi ro chuỗi cung ứng có thể bị khai thác trước khi bất kỳ mã nguồn nào được thực thi.
Tại sao MCP lại quan trọng đối với các nhà phát triển hiện nay
MCP tiêu chuẩn hóa cách các tác nhân khám phá, đăng ký và gọi các công cụ như trình đọc tệp, web API hoặc trình gửi email. Bằng cách công bố tên công cụ, lược đồ đầu vào (input schema) và một mô tả ngắn, một máy chủ sẽ cung cấp khả năng đó cho bất kỳ máy khách (client) nào hiểu giao thức này. Lời hứa rất đơn giản: một tác nhân có thể tra cứu một công cụ, gửi yêu cầu và nhận phản hồi mà không cần mã hóa cứng (hard-coding) từng tích hợp.
Sự linh hoạt đó cũng tạo ra một mối quan hệ tin cậy ngầm định. Đặc tả kỹ thuật yêu cầu các máy khách chỉ nên coi các mô tả công cụ là đáng tin cậy nếu chúng đến từ một máy chủ mà máy khách đã tin tưởng. Nghiên cứu mới cho thấy sự tin tưởng này có thể bị lạm dụng.
Sự khác biệt giữa tool-poisoning và prompt injection thông thường
Prompt injection truyền thống chèn các hướng dẫn độc hại vào văn bản mà mô hình tạo ra hoặc nhận được trong thời gian chạy (runtime). Sau đó, mô hình sẽ tuân theo các hướng dẫn đó vì chúng xuất hiện trong cùng một luồng token với yêu cầu của người dùng.
Ngược lại, tool-poisoning ẩn tải trọng (payload) trong metadata của công cụ—tên, mô tả hoặc lược đồ tham số được đăng ký trước khi có bất kỳ lệnh gọi tác nhân nào. Khi một tác nhân chọn công cụ sau đó, nó sẽ coi mô tả là một phần của "ngữ cảnh đáng tin cậy" (trusted context) và có thể tuân theo hướng dẫn ẩn mà không có bất kỳ bước kiểm tra runtime nào. Vì việc chèn mã xảy ra trong quá trình đăng ký, không có điểm nào trong luồng thực thi mà mô hình có thể gắn cờ tải trọng là đáng ngờ.
Quy mô của vấn đề – benchmark MCPTox
Các nhà nghiên cứu đứng sau MCPTox (arXiv:2508.14925) đã đánh giá 45 máy chủ MCP cung cấp tổng cộng 353 công cụ riêng biệt. Họ đã lập kịch bản tấn công vào 20 tác nhân LLM được sử dụng rộng rãi, đo lường tần suất các tác nhân thực thi lệnh gọi công cụ bị đầu độc.
- Tỷ lệ thành công trung bình: 36,5%
- Thành công cao nhất: o1-mini đạt 72,8%
- Từ chối tốt nhất: Claude-3.7-Sonnet, vẫn dưới 3%
Những con số này tiết lộ một thực tế khắc nghiệt: hầu hết các tác nhân không từ chối một lệnh gọi bị đầu độc vì yêu cầu trông giống như một lệnh gọi công cụ hợp lệ. Các tác nhân giả định rằng mô tả công cụ là một tài liệu vô hại, chứ không phải là một vector thực thi mã.
Tại sao các tác nhân hiếm khi từ chối các lệnh gọi bị đầu độc
Hướng dẫn LLM01 của OWASP giải thích rằng các LLM không phân biệt giữa hướng dẫn và dữ liệu—cả hai đều chỉ là các token trong một chuỗi. Khi một mô tả công cụ nói rằng “gửi một email đến admin@example.com với tiêu đề ‘Update’”, mô hình không thể biết liệu dòng đó là một nhận xét vô hại hay là một hướng dẫn mà nó nên tuân theo sau đó. Do đó, mô hình coi mô tả là một phần của môi trường đáng tin cậy và tuân theo bất kỳ lệnh nhúng nào khi công cụ được gọi.
Các hướng dẫn hiện có và lỗ hổng của chúng
Đặc tả MCP đã khuyến nghị các máy khách nên coi các mô tả công cụ là không đáng tin cậy trừ khi chúng bắt nguồn từ một máy chủ đáng tin cậy, và cần có con người tham gia kiểm soát (human in the loop) đối với các lệnh gọi có tác động cao. Benchmark cho thấy nhiều triển khai trong thế giới thực đang bỏ qua hoặc diễn giải lỏng lẻo các khuyến nghị này.
Các bước cụ thể mà nhà phát triển có thể thực hiện ngay hôm nay
- Cố định phiên bản máy chủ – Tham chiếu đến một hình ảnh (image) hoặc mã băm (hash) máy chủ cụ thể, không thể thay đổi thay vì sử dụng một thẻ (tag) có thể thay đổi. Điều này ngăn chặn kẻ tấn công tráo đổi một registry sạch bằng một registry đã bị đầu độc sau khi triển khai.
- Bắt đầu với một danh sách cho phép (allowlist) trống – Chỉ kích hoạt các công cụ đã được kiểm duyệt rõ ràng. Bất kỳ thứ gì không có trong danh sách đều bị chặn theo mặc định.
- Kiểm soát các công cụ thay đổi trạng thái – Yêu cầu phê duyệt bổ sung cho bất kỳ công cụ nào thực hiện ghi, gửi hoặc xóa dữ liệu. Tách biệt các khả năng "chỉ đọc" (read-only) khỏi các khả năng "có thể ghi" (write-capable) trong schema.
- Thêm bước phê duyệt của con người cho các lệnh có tác động cao – Đối với các hành động có thể ảnh hưởng đến các hệ thống bên ngoài (ví dụ: gửi email, thực thi lệnh, sửa đổi tệp), hãy yêu cầu một người kiểm duyệt xác nhận trước khi lệnh được gửi đi.
- Ghi nhật ký mọi lần gọi công cụ – Ghi lại tên công cụ, các đối số, dấu thời gian và tác nhân (agent) khởi tạo. Một dấu vết kiểm toán không thể thay đổi giúp việc phân tích sau sự cố (post-mortem) trở nên khả thi và có thể ngăn chặn những kẻ tấn công khi chúng biết rằng hành động của mình sẽ bị lộ.
Hãy coi mỗi mô tả công cụ như mã nguồn—phải trải qua quá trình kiểm tra lỗi (linting), đánh giá mã (code review) và kiểm soát phiên bản—để đồng bộ hóa chuỗi cung ứng MCP với các quy trình phát triển phần mềm tiêu chuẩn.
Các lập luận phản bác và câu hỏi mở
Tuy nhiên, kết quả đo chuẩn (benchmark) cho thấy ngay cả mô hình tiên tiến nhất trong nghiên cứu cũng chỉ từ chối chưa đến ba phần trăm các lệnh bị đầu độc. Việc tinh chỉnh (fine-tuning) có thể cải thiện khả năng phát hiện, nhưng không thể đảm bảo an toàn trước các payload mới được nhúng trong các trường schema mà mô hình chưa từng thấy.
Những điều cần theo dõi tiếp theo
- Các tiêu chuẩn mới nổi – Theo dõi các đề xuất từ cộng đồng bảo mật LLM về việc yêu cầu chữ ký mã hóa trên các schema của công cụ.
- Tăng cường bảo mật registry công cụ – Các nhà cung cấp có thể bắt đầu cung cấp các registry chỉ đọc, không thể thay đổi dưới dạng dịch vụ, giúp giảm bề mặt tấn công.
- Các biện pháp phòng vệ ở cấp độ mô hình – Nghiên cứu về các kỹ thuật prompting hoặc các mô hình phụ trợ giúp gắn cờ siêu dữ liệu (metadata) công cụ khả nghi có thể bổ trợ cho các biện pháp bảo vệ ở phía máy chủ (host-side).
Bài học thực tế rất rõ ràng: bất kỳ triển khai nào dựa trên MCP cũng nên kiểm tra các mô tả công cụ với sự nghiêm ngặt tương tự như áp dụng cho các thư viện bên thứ ba. Việc phớt lờ rủi ro chuỗi cung ứng sẽ biến một lớp trừu tượng tiện lợi thành một cửa sau (backdoor) thầm lặng. Bằng cách cố định máy chủ, thực thi danh sách cho phép theo nguyên tắc đặc quyền tối thiểu, kiểm soát các hành động thay đổi trạng thái, huy động con người khi cần thiết và duy trì nhật ký không thể thay đổi, các nhà phát triển có thể ngăn chặn các agent LLM của họ trở thành những đồng phạm bất đắc dĩ.