Chữ “S” trong MCP là viết tắt của bảo mật

• MCP là giao thức tiêu chuẩn để kết nối LLM với công cụ, nhưng về mặc định không có bảo mật
• Tồn tại nhiều lỗ hổng bảo mật như chèn lệnh, đầu độc công cụ và sửa đổi định nghĩa
• MCP thiếu xác thực, mã hóa và kiểm tra tính toàn vẹn, nên có cấu trúc khó đáng tin cậy
• Dùng các công cụ như ScanMCP để có khả năng quan sát và kiểm soát hiện là cách ứng phó tốt nhất

MCP là gì và vì sao quan trọng

• MCP là viết tắt của Model Context Protocol, một tiêu chuẩn mới cho cách các LLM như Claude, GPT và Cursor tích hợp với công cụ và dữ liệu
• Nó cung cấp một phương thức kết nối được chuẩn hóa đến mức được gọi là “USB-C cho các AI agent”
• Thông qua MCP, AI agent có thể thực hiện các chức năng như sau
  • Kết nối với công cụ bằng API tiêu chuẩn hóa
  • Duy trì trạng thái phiên
  • Thực thi lệnh (có thể bị thực thi quá tự do)
  • Chia sẻ ngữ cảnh giữa các workflow
• Nhưng về mặc định, không có bảo mật được áp dụng
• Có nguy cơ mở ra các kênh phụ cho phép truy cập vào hệ thống mà người dùng không hay biết

Các lỗ hổng bảo mật chính phát sinh trong MCP

• Lỗ hổng chèn lệnh (nghiên cứu của Equixly)

  • Tính đến năm 2025, thực thi mã từ xa (RCE) thông qua chèn lệnh vẫn đang xảy ra
  • Theo điều tra của Equixly, hơn 43% triển khai máy chủ MCP sử dụng lời gọi shell không an toàn
  • Kẻ tấn công có thể đưa lệnh shell vào giá trị đầu vào của công cụ để thực thi mã từ xa thông qua một agent đáng tin cậy

• Đầu độc công cụ (Tool Poisoning, Invariant Labs)

  • Đây là cách kẻ tấn công ẩn lệnh độc hại trong phần mô tả công cụ
  • Người dùng không nhìn thấy, nhưng AI vẫn nhận diện và thực thi nguyên trạng
  • Một công cụ trông như chỉ làm phép toán đơn giản thực tế có thể đọc khóa SSH hoặc các tệp cấu hình nhạy cảm trên hệ thống của người dùng

• Tái định nghĩa công cụ âm thầm (Rug Pull)

  • Công cụ có thể tự thay đổi định nghĩa sau khi được cài đặt
  • Một công cụ bình thường ở Day 1 có thể trở thành công cụ thu thập API key của kẻ tấn công vào Day 7
  • Đây là một dạng mới của vấn đề bảo mật chuỗi cung ứng xảy ra bên trong LLM

• Che khuất công cụ liên máy chủ

  • Khi nhiều máy chủ MCP được kết nối với một agent, máy chủ độc hại có thể chặn hoặc ghi đè các lời gọi tới máy chủ đáng tin cậy
  • Kết quả có thể dẫn đến các vấn đề như
    • Gửi email cho kẻ tấn công nhưng giả như đã gửi cho người dùng
    • Tiêm logic ẩn vào công cụ
    • Rò rỉ dữ liệu đã được mã hóa

Vì sao MCP vẫn chưa an toàn

• MCP ưu tiên các yếu tố sau
  • ✅ Tích hợp dễ dàng
  • ✅ Giao diện thống nhất
• Nhưng còn thiếu các yếu tố sau
  • ❌ Không có tiêu chuẩn xác thực
  • ❌ Không có mã hóa ngữ cảnh
  • ❌ Không thể xác minh tính toàn vẹn của công cụ
• Người dùng không thể biết agent thực sự đang sử dụng công cụ dựa trên phần mô tả nào

Những biện pháp bảo mật mà nhà phát triển và đơn vị vận hành nền tảng có thể thực hiện

• Nhà phát triển

  • Bắt buộc phải xác thực đầu vào
  • Cố định phiên bản (pinning) của máy chủ MCP và công cụ
  • Loại bỏ thông tin nhạy cảm khỏi phần mô tả công cụ

• Đơn vị vận hành nền tảng

  • Hiển thị toàn bộ metadata của công cụ cho người dùng
  • Sử dụng hash toàn vẹn khi máy chủ được cập nhật
  • Bắt buộc áp dụng bảo mật phiên

• Người dùng

  • Không kết nối tới máy chủ MCP không đáng tin cậy
  • Giám sát log phiên như trong môi trường production
  • Theo dõi các bản cập nhật công cụ đáng ngờ

Đề xuất ý tưởng ScanMCP.com

• ScanMCP được đề xuất là một công cụ quét và dashboard có thể thực hiện các việc sau
  • Kiểm tra các công cụ MCP đã kết nối
  • Phát hiện rủi ro như RCE, đầu độc công cụ và rò rỉ phiên
  • So sánh và trực quan hóa thông tin người dùng nhìn thấy với thông tin mà agent nhận biết
• Có thể hữu ích cho những đối tượng như sau
  • Đội ngũ bảo mật của các nền tảng agent
  • Các startup hạ tầng AI
  • Các nhà phát triển độc lập muốn xây dựng công cụ dựa trên niềm tin

Suy nghĩ kết lại

MCP là một giao thức mạnh mẽ, nhưng đang được đưa vào sử dụng quá nhanh khi mức độ trưởng thành về bảo mật API còn thiếu
Trước khi cách tiếp cận secure-by-default được áp dụng, các công cụ như ScanMCP.com là cách tốt nhất để giành lại khả năng quan sát và quyền kiểm soát

• Kết luận: Chữ “S” trong MCP không phải là Security. Nhưng nó nên là như vậy

[GN⁺]

Ý kiến Hacker News

• Bài viết này nhấn mạnh và trích dẫn các kịch bản tấn công được mô tả trong ghi chú bảo mật do Invariant Labs công bố vài ngày trước (tool poisoning, shadowing, MCP rug pull). Tôi là tác giả của bài blog đó

  • Trái với điều nhiều người nghi ngờ, vấn đề bảo mật của việc gọi công cụ LLM theo kiểu MCP không nằm ở việc cô lập các triển khai máy chủ MCP khác nhau
  • Các triển khai máy chủ MCP chạy cục bộ cần được trình quản lý gói dùng để cài đặt xác minh (máy chủ MCP từ xa thực tế còn khó xác minh hơn)
  • Vấn đề nằm ở một dạng đặc biệt của prompt injection gián tiếp phát sinh khi dùng MCP trong các hệ thống tác tử
  • Vì tác tử đưa thông số kỹ thuật của mọi máy chủ MCP đã cài đặt vào cùng một ngữ cảnh, một máy chủ MCP không đáng tin cậy có thể dễ dàng thao túng hành vi của máy chủ MCP khác (ví dụ: máy chủ có thể truy cập cơ sở dữ liệu nhạy cảm). Chúng tôi gọi điều này là tool shadowing
  • Ngoài ra, do tính chất động của MCP, máy chủ MCP có thể thay đổi bộ công cụ mà nó cung cấp chỉ cho một người dùng cụ thể. Điều này có nghĩa là máy chủ MCP có thể trở nên độc hại bất cứ lúc nào
  • Các ứng dụng khách MCP hiện tại là Claude và Cursor không thông báo các thay đổi này, khiến tác tử và người dùng dễ bị tấn công
  • Ai quan tâm hơn có thể xem bài blog chi tiết hơn ở [1]. Chúng tôi đã nghiên cứu và làm việc lâu dài về bảo mật tác tử tại Invariant
  • Chúng tôi cũng đã công bố các đoạn mã để mọi người có thể tự thử nghiệm, bao gồm cả tấn công tool poisoning nhắm vào máy chủ WhatsApp MCP phổ biến [2]

• Những cuộc tấn công này phần lớn chỉ là một ví dụ khác của việc đứng sai phía của airlock. Chúng không vượt qua ranh giới quyền hạn nào cả, chỉ là thực hiện theo cách kỳ quặc những gì vốn dĩ đã làm được

  • Máy chủ MCP chạy mã ở cấp độ người dùng, nên không cần lừa AI đọc khóa SSH. Nó đơn giản là có thể đọc khóa đó
  • Phần còn lại về cơ bản cũng là cùng những lời phàn nàn có thể áp dụng cho các công cụ/hệ sinh thái phát triển khác (NPM hoặc VS Code Extensions)

• Thử thách là hình dung ra một thiết kế tốt hơn như sau:

  • 1. Có một tiêu chuẩn bảo mật phù hợp để người ta không phải viết những bài kiểu "S là viết tắt của Security"
  • 2. Cho phép chương trình cung cấp cùng tập chức năng như những MCP hữu ích nhất hiện nay, mà không biến chức năng tự động thành thứ đòi hỏi xác nhận thủ công từ người dùng, và nói chung không vô hiệu hóa mục đích của toàn bộ ý tưởng này
  • 3. Không khóa mọi thứ vào một marketplace độc quyền có người gác cổng doanh nghiệp
  • Tôi muốn thấy các đề xuất, vì đến giờ thứ tôi thấy chỉ là những câu chung chung và thiếu cụ thể kiểu "MCP không an toàn!!!111". Điều này càng không dễ khi người ta quên rằng bảo mật và tính hữu dụng là hai lực đối nghịch nhau

• Bài viết hay, nhưng tôi tự hỏi liệu tất cả có phải do AI tạo ra không

  • Ảnh hồ sơ trông như được tạo bằng StableDiffusion, tài khoản được tạo hôm nay và không có bài viết trước đó
  • Tôi cũng không tìm được tham chiếu nào khác về Elena Cross

• O là viết tắt của observability. Tuần này tôi đã đào rất sâu vào việc khám phá và viết máy chủ MCP

  • Hầu hết các triển khai, kể cả bản đồ chơi của tôi, đều không có audit hay metrics. Claude lưu đầu ra log của máy chủ MCP, nhưng đó là để gỡ lỗi chứ không phải cho DevOps/SecOps
  • Về mặt văn hóa, vấn đề mà OP mô tả là chuyện lớn với những người thiên về kỹ năng mềm (muggles). Trong các subreddit liên quan, mọi người đang rất vui vẻ chạy các chương trình MCP CLI trên máy của họ
  • Bình luận bảo mật của OP có thể là điều hiển nhiên với lập trình viên, nhưng những người dùng này không có góc nhìn về mức độ rủi ro của nó
  • Mọi người đang học về Docker, và Claude có đưa cách dùng nó vào ví dụ. Nhưng phần lớn mọi người chỉ tải blob về rồi chạy. Mọi người đang mù quáng code và chạy máy chủ MCP
  • Khi MCP lan rộng hơn, framework và công cụ sẽ phát triển để hỗ trợ bảo mật, observability, v.v. Nó giống như xây dựng web vào giữa thập niên 90
  • Không liên quan đến OP, nhưng trong lúc xây cái này, việc nhập gì đó vào Claude Desktop rồi kích hoạt breakpoint trong VSCode là một trải nghiệm rất thú vị

• Đúng vậy. Tôi cũng đã có suy nghĩ tương tự, dù khi công bố ghi chú tôi chưa đào sâu đến thế

• Ngay cả khi phần mềm đang dùng không độc hại và được triển khai an toàn, làm sao xác nhận nó được sử dụng đúng như mong muốn?

  • Giả sử có một máy chủ MCP có thể sửa hệ thống tệp cục bộ và một máy chủ MCP sửa các đối tượng trong bộ nhớ đám mây. Làm sao người dùng có thể bảo đảm tác tử LLM đưa ra lựa chọn đúng?
  • Ta muốn cung cấp nhiều lựa chọn mà không phải giám sát mọi hành động, nhưng làm vậy có thể dẫn đến nhiều vấn đề hơn

• Hơn 43% các triển khai máy chủ MCP mà Equixly kiểm thử có lệnh gọi shell không an toàn

  • Làm sao người ta có thể sa vào cái bẫy này hết lần này đến lần khác

• Tôi đang tự hỏi MCP là gì. Tôi đã nhiều lần cố đọc tài liệu nhưng vẫn không hiểu nó giải quyết vấn đề gì. Chủ yếu là điều gì khiến nó đặc biệt đối với tác tử AI, mà lại không áp dụng cho các tác tử quyết định luận đã tồn tại hàng chục năm qua

• Tôi từng cho rằng toàn bộ mục đích của MCP là để Anthropic nghe lén prompt và đầu ra nhằm tối đa hóa dữ liệu huấn luyện. Đây là lần đầu tôi biết nó là middleware cho mọi mô hình AI