Hầu hết team đang chạy hơn một AI agent hôm nay đều làm theo cùng một anti-pattern: một API key dùng chung nằm trong biến môi trường, dùng bởi mọi agent, mọi subagent, mọi scheduled task, không có cách nào biết sau này agent nào thực sự đã gọi một request cụ thể. Đó là phiên bản thời AI của việc mọi service trong hạ tầng chia sẻ một credential database root — chạy tốt cho đến khi có gì đó sai, và khi đó bạn không có cách nào trả lời câu hỏi đầu tiên ai cũng hỏi trong incident: process nào đã làm điều này? Cloudflare ra mắt Identity-Aware AI Gateway tháng này chính để đóng khoảng trống đó, cùng một sản phẩm đồng hành lạ hơn — Cloudflare Wallets, cho phép agent giữ một danh tính có thể chi tiêu với giới hạn con người đặt ra. Cùng nhau, chúng là canh bạc về thứ thực sự đang thiếu trong hạ tầng agent hiện nay, và đáng để đi qua cả hai trong bối cảnh một fleet agent thật.

Attribution bằng key dùng chung thực sự tốn kém thế nào

Đi qua ý nghĩa vận hành của key dùng chung. Giới hạn chi tiêu là tất-cả-hoặc-không-gì xuyên suốt mọi agent dùng key — bạn không thể giới hạn ngân sách một subagent thử nghiệm mà không giới hạn cả production. Access log chỉ cho thấy “API key” đã gọi, không phải agent nào, session nào, hay task nào kích hoạt. Nếu key rò rỉ, mọi agent dùng nó bị xâm phạm đồng thời, và xoay vòng key nghĩa là cập nhật config của mọi agent cùng lúc, thường trong lúc incident, thường tệ. Không có gì mới ở đây — đó chính xác là tập vấn đề mà auth service-to-service đã giải một thập kỷ trước bằng mutual TLS và service account có scope. Điều mới là hầu hết team chưa áp dụng bài học đó vào traffic AI agent của mình, vì cho đến gần đây chưa có cách đơn giản để cắm một identity provider có sẵn vào tầng API AI mà không phải luồn user ID qua từng client call bằng tay.

Identity-aware gating thay đổi điều gì

Cách tiếp cận Cloudflare Gateway gắn mỗi AI API call ra ngoài vào một danh tính đã xác thực — con người, service account, hay agent tự động — lấy từ identity provider có sẵn và chính sách Zero Trust của bạn, thay vì yêu cầu ứng dụng gọi phải truyền user ID trên mỗi request. Khác biệt đó quan trọng hơn nghe có vẻ: truyền identity như một tham số tầng ứng dụng nghĩa là mọi client phải nhớ làm đúng, mỗi lần, và một bug hay default lười biếng âm thầm hạ attribution về lại “key dùng chung đã gọi call này.” Lấy identity từ tầng auth thay vào đó khiến nó mang tính cấu trúc chứ không tùy chọn — một call không có identity hợp lệ đơn giản không qua được gateway, giống cách một service không có cert mTLS hợp lệ không nhận được kết nối.

Thực tế, điều này mở khóa giới hạn chi tiêu theo từng agent (giới hạn agent nghiên cứu thử nghiệm ở $50/ngày bất kể production đang làm gì), access log lọc được theo identity thay vì “key nào, hy vọng thế là đủ,” và dashboard “User Insights” gắn cờ spike usage bất thường theo từng identity — đó chính là câu trả lời thực sự cho “mình có nhận ra không nếu một agent bắt đầu loop và đốt ngân sách lúc 2 giờ sáng,” một câu hỏi mình đã tự hỏi về scheduled task của chính mình nhiều hơn một lần.

Một policy sketch đáng học hỏi bất kể vendor

Pattern hữu ích ở đây tổng quát hóa vượt ra ngoài riêng Cloudflare. Nếu bạn đang đánh giá liệu gateway agent của chính mình (chạy trên bất cứ đâu) có tính chất này không, policy bạn muốn biểu diễn được đại khái là:

identity.type == "agent"
  and identity.scope in (allowed_scopes_for(identity.owner))
  and spend.daily < budget_for(identity.id)
  and not identity.flagged_anomalous

Đó cùng hình dạng với bất kỳ policy least-privilege nào — điểm mới cụ thể chỉ là identity.type == "agent" cần là một giá trị hạng nhất mà hệ thống auth của bạn hiểu, không phải một thứ gắn thêm vào sau lên identity người dùng con người. Nếu setup hiện tại của bạn không trả lời được “liệt kê mọi identity agent riêng biệt đã gọi API này trong 24 giờ qua, và mỗi cái chi tiêu bao nhiêu,” bạn thực ra chưa có attribution, bạn có một key dùng chung với log thêm vào.

Cloudflare Wallets: danh tính cho agent biết chi tiêu

Nửa lạ hơn của thông báo là Cloudflare Wallets — một wallet lập trình được cho phép agent tự động giữ một danh tính xác thực được và chi tiêu trong giới hạn con người đặt ra, mà agent không cần “đăng ký bằng Google” hay tự mở tài khoản ngân hàng. Đây là phiên bản nhỏ hơn, hẹp hơn của cùng bài toán nền tảng như tính năng Gateway: hiện tại, một agent cần trả tiền cho bất cứ thứ gì — nạp thêm credit API, gia hạn subscription SaaS, mua dữ liệu — hoặc không thể tự làm được, hoặc làm qua credential thanh toán thật của con người mà không có scope nào ngoài “hy vọng giới hạn chi tiêu trên thẻ là đủ.” Một wallet với danh tính lập trình được và giới hạn thực thi là tương đương ở tầng thanh toán của bài toán attribution API: cho agent một danh tính có giới hạn, có thể thu hồi, có thể quy trách nhiệm thay vì mượn danh tính không giới hạn của con người.

Còn sớm — đây là loại tính năng thú vị hơn như một tín hiệu về hướng đi của hạ tầng agent hơn là thứ hầu hết team cần hôm nay. Nhưng nó vang vọng một pattern đã xuất hiện ở nơi khác trong năm nay: chuỗi identity agent lan truyền qua JWT trong hệ thống auth doanh nghiệp, traffic MCP được fingerprint ở tầng protocol, và giờ là danh tính thanh toán agent-native. Ngành đang hội tụ, từng mảnh một, về ý tưởng rằng “một agent” cần là một principal thật trong hệ thống identity của bạn — không phải credential của con người khoác áo trenchcoat.

Những gì đáng kiểm tra trước khi áp dụng bất kỳ điều nào ở trên

1. Bạn có thể liệt kê mọi identity agent riêng biệt đang gọi API trong stack của mình hôm nay, không cần tính năng này không? Nếu câu trả lời thành thật là “không, tất cả dùng một key,” đó mới là vấn đề thực sự cần sửa, bất kể sản phẩm vendor nào bạn dùng để sửa nó.
2. Giới hạn chi tiêu của bạn thực thi theo từng identity hay theo từng key? Nếu theo key và nhiều agent chia sẻ một key, bạn không có cô lập ngân sách thật bất kể dashboard trông thế nào.
3. Anomaly detection của bạn biết “bình thường” trông như thế nào theo từng agent, hay chỉ ở mức tổng hợp? Một agent nghiên cứu gọi 200 call/giờ có thể hoàn toàn bình thường; một agent deploy-automation làm điều tương tự là báo động đỏ. Baseline theo từng identity mới là toàn bộ vấn đề.
4. Nếu credential của một agent cụ thể rò rỉ hôm nay, bạn có thể thu hồi riêng nó mà không đụng vào quyền truy cập của mọi agent khác không? Nếu câu trả lời cần xoay vòng một secret dùng chung, bạn đã tìm ra ưu tiên hạ tầng tiếp theo của mình.

Sản phẩm cụ thể sẽ tiếp tục thay đổi — đây là không gian di chuyển nhanh và Cloudflare sẽ không phải vendor duy nhất ra mắt hình dạng tính năng này trước cuối năm. Yêu cầu nền tảng thì không: mọi thứ tự động hành động thay mặt bạn cần danh tính riêng, ngân sách giới hạn riêng, và credential có thể thu hồi riêng, y hệt cách mọi nhân viên con người và mọi service account đã có.