Mình đang chạy một stack agent giao tiếp với khá nhiều dịch vụ bên ngoài qua một gateway kiểu MCP — email, calendar, deploy pipeline, một host Proxmox, một tài khoản Cloudflare có quyền chỉnh DNS và tunnel. Mỗi thứ trong số đó là một tool call mà agent có thể tự thực hiện, ở tốc độ máy, không cần con người bấm “approve” trước. Đó chính là toàn bộ giá trị. Nhưng đó cũng chính xác là điểm mù mà phần lớn công cụ bảo mật mạng chưa được xây để xử lý, vì access control truyền thống giả định rằng con người là người quyết định khi nào và bao nhiêu lần gọi tới một endpoint. Cloudflare vừa đưa detection ở tầng protocol cho MCP vào Gateway, và đọc qua cách nó hoạt động là một cú hích hữu ích để bất kỳ ai đang chạy hạ tầng agent của riêng mình thực sự nghĩ về việc cái gì đang gọi ra ngoài trên mạng của mình.

Vì sao đây thực sự là một mô hình đe dọa khác

Vấn đề cốt lõi: AI agent thay đổi ngưỡng khiến một hành động đáng được review. Một người bấm qua UI để xóa 500 record sẽ nhận ra có gì đó sai giữa chừng. Một agent thực thi cùng một tool call 500 lần trong vòng lặp, vì điều kiện retry không bao giờ được resolve hoặc vì nó nhận một instruction hơi sai, thì không nhận ra gì cả — nó cứ tiếp tục gọi. Rate limiting thiết kế dựa trên hành vi con người không bắt được cái này, vì pattern request trông hoàn toàn hợp lý ở từng request; chính khối lượng và tính tự động mới là bất thường, không phải bất kỳ call đơn lẻ nào.

Traffic MCP thực sự được nhận diện như thế nào

Cách tiếp cận detection là fingerprinting ở tầng protocol, không phải đoán ở tầng app. Mọi MCP client, sau khi handshake, bắt buộc phải gửi header MCP-Protocol-Version trên mọi HTTP request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Content-Type: application/json

Chỉ riêng sự hiện diện của header đó đã được coi là tín hiệu tích cực mạnh — nó được xây dựng từ các pattern quan sát được trên một khối lượng lớn traffic thật, không phải một signature hardcode. Với các MCP server chạy phiên bản spec cũ hơn không có header đó, có một fallback: pattern hostname chứa “mcp”, URL path như /mcp hoặc /sse, và tên method JSON-RPC như initialize, tools/call, resources/read trong body request. Spec 2026-07-28 mới hoàn toàn stateless — không có phiên handshake bền vững — nên mỗi request đơn lẻ đều mang đủ metadata để được phân loại độc lập, đây thực ra là một tính chất tốt xét từ góc độ công cụ bảo mật: không có gì bị mất dấu giữa phiên.

Bạn thực sự làm gì được với tín hiệu đó

Một khi traffic được phân loại, một policy Gateway trở thành một dòng:

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")

Đọc như thế này: bất kỳ traffic MCP nào không đi qua portal được quản lý của mình sẽ bị chặn. Đó chính là pattern đáng áp dụng kể cả ngoài phạm vi Cloudflare — điểm mấu chốt không phải là sản phẩm, mà là hình dạng của policy. Kết nối MCP trực tiếp, không qua trung gian, từ agent tới một upstream server bất kỳ là trường hợp rủi ro; kết nối đi qua một lớp proxy được quản lý, enforce identity, log mọi call, và curate tool nào có thể tiếp cận được là trường hợp an toàn. Cái proxy — Cloudflare gọi là “portal”, nhưng khái niệm này áp dụng chung cho bất kỳ gateway nào nằm giữa agent và thế giới bên ngoài — cho bạn ba thứ mà kết nối trực tiếp không có: kiểm tra identity trước khi call đi ra, một log bền vững về những gì thực sự đã được gọi, và một allowlist được curate thay vì để agent tiếp cận bất kỳ MCP endpoint nào nó được bảo.

Checklist mình thực sự chạy bây giờ

Trước khi gắn một MCP server mới vào stack của mình, đây là trình tự:

1. Nó có đi qua gateway, hay đi trực tiếp? Nếu agent có thể tiếp cận nó mà không qua lớp proxy, đó là thứ đầu tiên cần sửa — không phải một config “có thì tốt”.
2. Cái gì thực sự được log? Không chỉ “có một call xảy ra” — mà là tool nào, argument nào, phiên agent nào. Bạn không thể điều tra một sự cố từ một giá trị boolean.
3. Bán kính ảnh hưởng của credential đứng sau nó là gì? Một token chỉ có quyền “đọc calendar” và một token có quyền “admin toàn bộ tài khoản Cloudflare” không bao giờ nên được coi là rủi ro tương đương chỉ vì cả hai đều “chỉ là một MCP server”.
4. Một vòng lặp có hiện lên không? Nếu agent gọi tool này 500 lần trong mười phút, có gì cảnh báo không — hay nó chỉ trông giống 500 request bình thường, từng cái đều hợp lệ?

Giới hạn thật đáng nói ra: kiểu detection này cần TLS inspection mới hoạt động được, nên nó không bao phủ các server chạy stdio cục bộ, kết nối off-network, hay traffic đánh dấu rõ “không inspect”. Đây không phải lỗi của công cụ — đó là lời nhắc rằng detection ở tầng mạng chỉ là một lớp trong hệ phòng thủ, còn cần identity scoping và logging ở tầng ứng dụng, vì mạng không thể thấy được cái nó không được phép giải mã.

Kết luận thực tế

MCP khiến việc gắn một agent với hàng chục dịch vụ thật trong một buổi chiều trở nên tầm thường dễ dàng. Mô hình bảo mật cho việc đó chưa theo kịp sự tiện lợi, và khoảng cách đó gần như vô hình cho tới khi một agent làm gì đó tự động và sai lúc 2 giờ sáng mà không ai theo dõi. Coi mỗi kết nối MCP là “chỉ là một API call mình đã tin tưởng” là sai lầm; coi nó là một lớp traffic mới cần identity, logging, và allowlist riêng — giống hệt cách bạn không bao giờ để một service account bỏ qua review IAM hiện có — mới là cách sửa, và nó không cần chờ một tính năng từ vendor mới bắt đầu làm được.