Cloudflare tăng cường bảo mật cho giao thức MCP: Cách phát hiện và kiểm soát lưu lượng

Hầu hết các công ty thiết kế quyền truy cập tài nguyên của họ với giả định người dùng là con người. Một kỹ sư cấp cao có thể triển khai mã nguồn lên môi trường production, truy vấn cơ sở dữ liệu nhạy cảm hoặc thu hồi quyền truy cập của người dùng khác. Những đặc quyền đó đi kèm với rủi ro, nhưng rủi ro này theo truyền thống thường bị giới hạn bởi hai giả định: kỹ sư sẽ sử dụng khả năng phán đoán của con người và kỹ sư chỉ có thể hành động ở tốc độ của con người.

Một kỹ sư khi thấy kết quả bất ngờ thường sẽ dừng lại và xem xét lại hành động của mình. Bất kỳ con người nào cũng chỉ có thể nhấp chuột, gõ phím và xem xét một lượng công việc nhất định trong một ngày. Sự xuất hiện của các AI agent làm thay đổi cả hai ngưỡng này. Các quyết định của chúng là không xác định (nondeterministic) và chúng có thể thực hiện cùng một hành động (hoặc gọi cùng một công cụ) vô thời hạn mà không biết mệt mỏi hay dừng lại để nghỉ trưa. Một quyết định hợp lý — nhưng không chính xác — có thể biến thành hàng ngàn hành động sai lầm trước khi con người kịp nhận ra.

Hôm nay, chúng tôi công bố các khả năng mới của Cloudflare One nhằm xác định lưu lượng truy cập MCP đã được kiểm tra, hiển thị người dùng và máy chủ nào đang tạo ra lưu lượng đó, đồng thời kiểm soát các kết nối trực tiếp trên các đường dẫn mạng được quản lý. Kết hợp với MCP Server Portals, các biện pháp kiểm soát này giúp quản trị viên biết được liệu các agent đang sử dụng đường dẫn đã được phê duyệt hay đang tìm cách vượt qua nó.

Các máy chủ Model Context Protocol (MCP) cung cấp cho các agent một cách thức chung để khám phá và gọi các công cụ được hỗ trợ bởi các sản phẩm SaaS của bên thứ ba, các ứng dụng nội bộ và API. Các quyền truy cập cơ bản có lẽ đã quen thuộc; điều thay đổi ở đây là ai đưa ra từng quyết định và một quyết định sai lầm có thể lan rộng nhanh đến mức nào.

Việc kết nối một agent với một trong những công cụ này chỉ mất một dòng cấu hình. Một nhân viên có thể trỏ Claude Code, Codex, Cursor, OpenCode, VS Code hoặc bất kỳ công cụ AI nào vào một máy chủ MCP mà không cần kiểm tra xem nó có được phê duyệt hay không. Lưu lượng truy cập tạo ra không có hình thái rõ ràng. Model Context Protocol không sử dụng tên máy chủ (hostname) được đảm bảo hay yêu cầu đường dẫn /mcp, vì vậy một kết nối trực tiếp có thể trông giống như bất kỳ lệnh gọi HTTPS API nào khác.

Để giải thích cách các biện pháp kiểm soát này kết hợp với nhau, chúng ta sẽ bắt đầu với cấu trúc của một lệnh gọi công cụ (tool call) và thông tin mà nó tiết lộ. Sau đó, chúng ta sẽ so sánh ba nơi mà đội ngũ bảo mật có thể can thiệp: bên trong client, trên mạng và tại máy chủ MCP. Từ đó, chúng tôi sẽ chỉ ra cách Cloudflare Gateway sử dụng các tín hiệu giao thức để tìm lưu lượng MCP ẩn (shadow MCP traffic) và thực thi quyền truy cập chỉ qua MCP Portal đối với các máy chủ MCP đáng tin cậy.

Cấu trúc của một lệnh gọi công cụ MCP

Cùng một lệnh gọi công cụ MCP có ba hình thái khi nó di chuyển qua một hệ thống. Bên trong client, đó là một quyết định gọi một công cụ với một tập hợp các đối số. Trên mạng, đó là một giao dịch HTTP mang theo thông điệp JSON-RPC. Tại máy chủ, nó trở thành một lệnh gọi đến trình xử lý công cụ (tool handler) có thể đọc dữ liệu, thay đổi trạng thái hoặc hoàn thành một hành động nào đó.

Hãy xem xét một agent muốn biết thời tiết ở Austin. Một yêu cầu MCP từ xa có thể trông như thế này:

Có một vài tín hiệu hữu ích được đóng gói trong yêu cầu này. Hostname và đường dẫn xác định đích đến. Tiêu đề xác thực (authorization header) mang thông tin xác thực được sử dụng để xác thực người gọi khi máy chủ yêu cầu. Tiêu đề MCP-Protocol-Version xác định phiên bản giao thức, trong khi Mcp-Method và Mcp-Name tiết lộ thao tác và công cụ trong giao thức không trạng thái (stateless) mới này. Gói tin JSON-RPC lặp lại phương thức, cung cấp cho yêu cầu một id để client có thể khớp với phản hồi và mang các đối số của công cụ trong phần params.

Các đối số là phần nhạy cảm nhất. Chúng có thể chứa truy vấn tìm kiếm, mã nguồn, dữ liệu khách hàng hoặc hướng dẫn cho một hành động như tạo ticket hoặc thay đổi cơ sở hạ tầng. Tên công cụ cho biết agent dự định gọi cái gì; các đối số cho biết dữ liệu nào nó sẽ gửi và hành động nào nó muốn máy chủ thực hiện.

Nếu lệnh gọi thành công, máy chủ sẽ trả về một phản hồi JSON-RPC với cùng id đó và kết quả của công cụ. Phản hồi đó cũng có thể chứa dữ liệu nhạy cảm. Việc kiểm tra yêu cầu có thể ngăn chặn một hành động không an toàn trước khi thực thi, trong khi việc kiểm tra và ghi nhật ký phản hồi cho thấy những gì công cụ đã trả về cho agent.

Ba nơi để kiểm soát một yêu cầu MCP

Yêu cầu này cung cấp cho các đội ngũ bảo mật ba nơi để quan sát hoặc kiểm soát lệnh gọi.

Bên trong MCP client

Một hook của client có thể chạy sau khi mô hình chọn một công cụ nhưng trước khi client tuần tự hóa (serialize) yêu cầu. Từ đó, nó có thể thấy máy chủ đích, tên công cụ và các đối số mà không cần giải mã lưu lượng mạng.

Đây là giai đoạn sớm nhất trong chuỗi yêu cầu để thực hiện kiểm soát. Client có thể từ chối một máy chủ không nằm trong danh sách cho phép (allowlist), yêu cầu người dùng xác nhận một thao tác nhạy cảm hoặc xóa dữ liệu khỏi các đối số trước khi nó rời khỏi thiết bị. Nó cũng có thể bao phủ các máy chủ MCP stdio cục bộ (còn gọi là local), vốn không bao giờ tạo ra lưu lượng mạng.

Điều này đặt ra một thách thức về tiêu chuẩn hóa. Để đội ngũ bảo mật được hưởng lợi từ điều này, họ sẽ cần tái tạo các biện pháp kiểm soát của mình trên mọi client mà nhân viên sử dụng. Các biện pháp kiểm soát phía client hoạt động tốt nhất khi tổ chức quản lý cả client và thiết bị, nhưng dữ liệu từ một client không bao giờ là danh mục đầy đủ về việc sử dụng MCP.

Tại ranh giới mạng của thiết bị

Một cổng web bảo mật (secure web gateway) có thể quan sát yêu cầu HTTP sau khi nó rời khỏi client. Với việc giải mã TLS, nó có thể liên kết yêu cầu với một người dùng và thiết bị, kiểm tra đích đến và các tiêu đề giao thức, đồng thời áp dụng chính sách mà không phụ thuộc vào một MCP client cụ thể nào.

Lớp mạng có tầm nhìn rộng nhất để phát hiện lưu lượng MCP từ xa trên các đường dẫn được quản lý. Nó có thể xác định các kết nối trực tiếp đến các máy chủ bên ngoài Portal đã được phê duyệt và chặn chúng trước khi yêu cầu đến đích. Nơi hỗ trợ quét ngăn chặn mất dữ liệu (DLP), proxy cũng có thể kiểm tra phương thức JSON-RPC và các đối số để tìm dữ liệu nhạy cảm. Tuy nhiên, proxy không thể thấy các lệnh gọi stdio cục bộ hoặc lưu lượng ngoài mạng.

Trước khi máy chủ MCP gọi công cụ

Máy chủ có ngữ cảnh thực thi phong phú nhất. Nó đã xác thực người gọi, phân tích thông điệp MCP, phân giải get_weather thành một trình xử lý và xác thực các đối số được cung cấp dựa trên lược đồ đầu vào của công cụ. Đây là điểm cuối cùng mà yêu cầu có thể bị từ chối trước khi công cụ chạy.

Một trình xử lý Agents SDK hoặc middleware máy chủ tương tự có thể ủy quyền cho người gọi đối với công cụ cụ thể, áp dụng giới hạn tốc độ (rate limits), kiểm tra các đối số và ghi lại kết quả. Máy chủ nên thực hiện các kiểm tra này trước khi gọi trình xử lý, đặc biệt đối với các công cụ ghi dữ liệu hoặc kích hoạt các hành động bên ngoài. Việc ghi nhật ký chỉ sau khi thực thi có thể giải thích những gì đã xảy ra, nhưng nó không thể ngăn chặn điều đó.

WriteGuard của Cloudflare sử dụng mô hình này trên các máy chủ MCP nội bộ của chúng tôi. Mỗi công cụ có một cấp độ rủi ro và trạng thái bật hoặc tắt. WriteGuard có thể cho phép lệnh đọc đi qua mà không thay đổi, thêm thông tin xác thực agent và sự kiện kiểm toán vào một lệnh ghi được cho phép, hoặc chặn một hành động quan trọng trước khi trình xử lý của nó chạy. Vì quyền kiểm soát nằm tại máy chủ, người dùng cuối không thể vượt qua nó bằng cách chuyển đổi client hoặc vô hiệu hóa một hook cục bộ.

Mặc dù các biện pháp kiểm soát phía máy chủ chỉ bảo vệ các máy chủ triển khai chúng, nhưng client và máy chủ có độ sâu yêu cầu tốt nhất. Mạng lưới nhìn thấy tập hợp các kết nối từ xa rộng nhất. Khi được sử dụng cùng nhau, các biện pháp kiểm soát này có thể ngăn chặn dữ liệu nhạy cảm trước khi nó rời khỏi thiết bị, tìm lưu lượng MCP không được quản lý và từ chối một thao tác trái phép trước khi công cụ thực thi.

Điểm kiểm soát mạng có phạm vi bao phủ rộng nhất, nhưng trước tiên nó phải phân biệt được MCP với lưu lượng HTTPS thông thường, người dùng phải đang chạy proxy và máy chủ MCP (hoặc Portal) phải xác minh rằng proxy đã được sử dụng trong kết nối.

Cloudflare One cung cấp các thành phần mạng của chuỗi đó. Cloudflare One Client gửi lưu lượng từ các thiết bị được quản lý thông qua Gateway. Gateway có thể phân loại các yêu cầu MCP ở lớp giao thức và phân biệt xem lưu lượng được khởi tạo từ một MCP Portal hay đang đi ra ngoài các biện pháp kiểm soát đã được phê duyệt. Quản trị viên sau đó có thể báo cáo hoặc chặn các kết nối không tuân theo đường dẫn đã được phê duyệt. Quá trình đó bắt đầu bằng việc xác định yêu cầu một cách đáng tin cậy.

Một URL không cho bạn biết rằng một yêu cầu sử dụng MCP

Cách tiếp cận đầu tiên của chúng tôi để tìm lưu lượng MCP là sử dụng GraphQL Analytics API để tìm kiếm trong nhật ký HTTP của Gateway các hostname chứa mcp và các đường dẫn phổ biến như /mcp hoặc /sse. Hướng dẫn phát hiện lưu lượng MCP của chúng tôi bao gồm truy vấn này. Nó cũng giải thích cách tạo các mẫu ngăn chặn mất dữ liệu cho các phương thức JSON-RPC của MCP như initialize, tools/call và resources/read trong phần thân yêu cầu.

Những tín hiệu đó vẫn hữu ích để tìm lưu lượng từ các client cũ và cung cấp khả năng hiển thị lịch sử, nhưng chúng rất cơ bản. Chúng bỏ lỡ một máy chủ MCP tại một URL thông thường như https://tools.example.com/api, điều không hiếm gặp.

Và chúng có thể khớp với một dịch vụ không liên quan tình cờ sử dụng mcp trong hostname hoặc đường dẫn (ít khả năng xảy ra, nhưng chúng tôi đã thấy). Đối với các client HTTP có thể truyền phát (Streamable), tiêu đề giao thức là một tín hiệu cụ thể hơn. Đặc tả MCP 2025-11-25 nói rằng các client PHẢI bao gồm MCP-Protocol-Version trên mọi yêu cầu HTTP sau khi khởi tạo. Đặc tả MCP 2026-07-28 còn đi xa hơn và yêu cầu nó trên mọi yêu cầu POST.

Điều đó không làm cho tiêu đề trở thành một trình phát hiện hoàn chỉnh. Yêu cầu ban đầu từ một client cũ có thể không chứa nó, các phiên bản giao thức trước 2025-06-18 không định nghĩa nó, và stdio cục bộ, phương thức truyền tải tùy chỉnh hoặc lưu lượng không tuân thủ có thể không bao giờ mang nó. Sự hiện diện của nó là một chỉ báo tích cực mạnh mẽ về MCP; sự vắng mặt của nó không chứng minh rằng một yêu cầu không phải là MCP.

Giao thức đang trở nên dễ nhận diện hơn trên đường truyền

Luồng MCP cũ bắt đầu bằng một yêu cầu initialize không chứa tiêu đề HTTP MCP-Protocol-Version, vì vậy một biện pháp kiểm soát mạng có thể không phân loại yêu cầu đầu tiên đến một điểm cuối chưa biết trước đó chỉ từ tiêu đề. Tín hiệu xuất hiện sau khi client và máy chủ hoàn tất khởi tạo.

Một lệnh gọi công cụ sau đó trông như thế này:

Đặc tả MCP 2026-07-28 thay đổi mô hình này đáng kể. Giao thức cốt lõi là không trạng thái; nó loại bỏ hoàn toàn quá trình bắt tay initialize và đặt phiên bản giao thức cũng như thao tác trên mỗi yêu cầu:

Các tiêu đề Mcp-Method và Mcp-Name cho phép cơ sở hạ tầng HTTP thông thường xác định thao tác mà không cần phân tích phần thân. Các bộ cân bằng tải (load balancer) có thể định tuyến yêu cầu, các bộ giới hạn tốc độ có thể tách biệt tools/list khỏi tools/call và các sản phẩm bảo mật nhận được nhiều thông tin hơn trên mỗi yêu cầu.

Những tín hiệu giao thức này cung cấp cho Cloudflare Gateway thứ gì đó cụ thể để đánh giá mà không cần dựa vào danh sách các URL trông giống MCP.