Mình từng viết về detection ở tầng protocol của Cloudflare cho MCP cách đây vài tuần — fingerprint traffic agent trên đường truyền và block bất cứ thứ gì không đi qua managed portal. Đó là một control ở tầng network: nó cho biết liệu một thứ có phải traffic MCP không và từ đâu nó tới. Nó không có ý kiến gì về việc liệu tool call cụ thể mà agent sắp thực hiện có phải là thứ nó được phép làm ngay lúc này, dựa trên việc nó đang hành động thay cho ai và nó vừa làm gì ba call trước đó. JetStream vừa ra mắt thứ gì đó tuần này nằm ở tầng cao hơn một bậc và trả lời chính xác câu hỏi đó: Clearance, một reasoning engine đánh giá từng hành động của agent theo một policy đã được approve và quyết định liệu nó có được chạy hay không — trước khi thực thi, không phải như một log entry ghi lại sau đó.

Sự khác biệt đó — detection so với authorization — là phần đáng để dừng lại suy nghĩ, vì phần lớn công cụ “AI agent security” mình đánh giá trong năm nay thực ra là cái trước đội lốt marketing của cái sau.

Detection cho biết chuyện gì đã xảy ra. Authorization quyết định chuyện gì sẽ xảy ra.

Một gateway fingerprint traffic MCP và log lại nó đang làm công việc giống một WAF tốt làm cho traffic HTTP: visibility, cờ báo bất thường, có thể là allow/deny thô ở tầng transport. Điều đó cần thiết. Nhưng nó không đủ cho agent, vì rủi ro thú vị với agent không phải là “đây có phải traffic MCP không” — mà là “agent cụ thể này, hành động thay cho user cụ thể này, sắp gọi delete_record trên một tool mà nó chỉ được phép read.” Không lượng fingerprint protocol nào bắt được điều đó; packet trông hoàn toàn hợp lệ. Bạn cần thứ hiểu được ngữ nghĩa của call, không chỉ hình dạng của nó trên đường truyền.

Model của Clearance được xây quanh cái JetStream gọi là “blueprint” — một mô tả đã version hóa, được check-in, về cách một hệ thống agentic cụ thể được lắp ráp: agent được nối với những tool nào, agent được phép gọi những action riêng lẻ nào trong số các action của những tool đó (không chỉ toàn bộ tool), và dưới identity nào. Khi một call đi qua AI gateway, Clearance map nó với blueprint trước khi cho phép call tiếp tục:

request:
  agent: invoice-processing-agent
  identity: svc-invoice-bot
  tool: postgres-mcp
  action: execute_query
  params:
    query: "DELETE FROM invoices WHERE ..."

blueprint check:
  agent "invoice-processing-agent" → tool "postgres-mcp"
    allowed_actions: [read_query]     # execute_query (write) không được cấp
  → DENY, reason: action not in blueprint

Độ chi tiết quan trọng ở đây là theo từng parameter, không phải theo từng tool. Bạn có thể gắn một Postgres MCP server vào agent và cấp read_query trong khi rõ ràng không cấp execute_query hay drop_table — cùng một kết nối tool, nhưng grant ở tầng action khác nhau. Đó là khác biệt giữa “agent này có credential database” và “agent này có credential database được scope giống như quyền truy cập read-replica của một kỹ sư junior.” Phần lớn setup MCP mình thấy ngoài thực tế cấp cái đầu theo mặc định vì đó là thứ SDK example hiển thị, và không ai quay lại thu hẹp nó sau khi demo chạy được.

Sequence quan trọng hơn bất kỳ call đơn lẻ nào

Phần khác mình nghĩ bị đánh giá thấp: Clearance đánh giá chuỗi call, không chỉ request riêng lẻ. Một call read_customer_record đơn lẻ thì bình thường. Một nghìn call read_customer_record liên tiếp trên toàn bộ bảng customer, theo sau bởi một call tới tool webhook bên ngoài, là một pattern exfiltration — và đó là pattern chỉ lộ ra nếu có thứ gì đang theo dõi chuỗi, không phải gating từng call độc lập. Đây là hình dạng vấn đề giống mình từng nêu trong bài về MCP zero-trust: một agent lặp vòng do điều kiện retry sai và một con người cố tình exfiltrate dữ liệu có thể trông giống hệt nhau ở cấp độ request đơn lẻ. Policy nhận biết sequence mới là thứ thực sự bắt được nó, và đó là một thứ khó xây hơn đáng kể so với allowlist theo từng call — nó cần state, một cửa sổ thời gian, và một định nghĩa “pattern” không chỉ trở thành một regex dễ vỡ khác.

Vị trí của nó trong một stack thực tế

Mình không chạy ở quy mô của JetStream, nhưng pattern này áp dụng trực tiếp cho các setup nhỏ hơn, kể cả của chính mình. Ba tầng mình giờ sẽ tách bạch rõ ràng:

1. Transport/network — đây có thực sự là traffic agent hợp lệ, đi qua gateway mình kiểm soát không? (Fingerprint kiểu Cloudflare, hoặc đơn giản là “proxy của mình có thấy nó không.”)
2. Action authorization — dựa trên identity của agent và bề mặt action đã khai báo của tool, action cụ thể này có phải là thứ nó được phép làm không? Đây là tầng Clearance, và là tầng phần lớn người ta bỏ qua vì nó đòi hỏi duy trì một blueprint thay vì một credential tĩnh.
3. Sequence/behavioral — pattern các action được phép có còn nhất quán với việc agent này được cho là đang làm gì không, hay nó trông giống một vòng lặp, một escalation, hay một exfiltration đang diễn ra?

Phần lớn stack agent mình review trong năm nay, kể cả phiên bản cũ hơn của chính mình, dừng ở tầng 1 và coi là xong. Credential được scope một lần lúc setup, sau đó bất kỳ action nào credential đó về mặt kỹ thuật cho phép đều được coi là đã authorize chỉ vì kết nối tới từ đúng nơi. Đó là khoảng trống Clearance đang nhắm tới, và đó là khoảng trống đúng để nhắm tới — một credential bị leak hoặc scope quá rộng đứng sau một kết nối MCP “đáng tin” là failure mode phổ biến hơn nhiều trong thực tế so với việc ai đó giả mạo tầng transport.

Mình đang thay đổi gì

Cụ thể, trên gateway agent của chính mình, điều này đẩy mình tới hai thay đổi mình chưa từng ưu tiên trước đây: viết ra một action allowlist rõ ràng theo từng tool theo từng agent — không chỉ “agent này có MCP server của Cloudflare,” mà “agent này được gọi list_dns_records và get_tunnel_config, và không gì mutate cả” — và coi danh sách đó là một artifact được review, thay đổi qua PR, không phải một toggle runtime không ai nhớ quay lại xem. Khái niệm blueprint thực ra chỉ là “least privilege, nhưng được viết ra và version hóa thay vì ngầm hiểu qua bất cứ thứ gì credential tình cờ cho phép.” Đó không phải ý tưởng mới trong security. Nó chỉ là ý tưởng mà công cụ AI agent đã chậm bắt kịp, vì ship một demo hoạt động với một API key scope tối đa dễ hơn nhiều so với việc ngồi liệt kê xem trong hai mươi action của một tool, agent cụ thể này thực sự cần bao nhiêu.

Nguồn: JetStream Announces Clearance, JetStream Security — Clearance platform