Web không cần gatekeeper: Đề xuất “Signed Agents” mới của Cloudflare

 (positiveblue.substack.com)
1 điểm bởi GN⁺ 2025-08-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • Chính sách Signed Agents của Cloudflare lấy an toàn làm danh nghĩa, nhưng trên thực tế là một nỗ lực khép kín nhằm biến việc truy cập web thành cơ chế phải xin phép
  • Web trong lịch sử đã phát triển nhờ tính mở và các tiêu chuẩn, còn những công nghệ đóng như Flash·Silverlight cuối cùng đều biến mất trước các tiêu chuẩn mở như HTML5
  • Trong tương lai, người dùng chính của web sẽ là các AI agent, và điều này đòi hỏi một hệ thống xác thực phân tán, có thể kiểm chứng và cơ chế cấp quyền theo từng tác vụ
  • Mô hình đúng đắn là kết hợp ủy quyền theo chuỗi + bằng chứng theo từng yêu cầu, để triển khai xác thực đáng tin cậy và kiểm soát quyền hạn ở mức chi tiết
  • Thay vì để một công ty cụ thể nắm chìa khóa, cần bảo vệ một web nơi mọi người đều có thể tham gia và đổi mới thông qua các giao thức và tiêu chuẩn mở

Phê phán Signed Agents của Cloudflare

  • Cloudflare đã đề xuất hệ thống Signed Agents mới, nhưng về thực chất đây là kiểm soát truy cập dựa trên danh sách cho phép
  • Việc một công ty cụ thể quyết định agent có được đăng ký hay không chỉ là cơ chế phê duyệt của nhà cung cấp, chứ không phải giao thức Internet
  • Điều này xung đột với bản chất mở của Internet, và việc “điền biểu mẫu để xin phép” không thể trở thành tiêu chuẩn

Web phải là mở

  • Chiến lược “embrace and extend” của Microsoft trong thập niên 90 đã thất bại, và điều đó có thể xảy ra vì web đã giữ được tính mở
  • Những runtime đóng như Flash và Silverlight cuối cùng đã bị thay thế bởi tiêu chuẩn mở HTML5
  • Lịch sử luôn chứng minh rằng các tiêu chuẩn mở thúc đẩy đổi mới

Sự xuất hiện của kỷ nguyên agent

  • AI agent sẽ trở thành người dùng cốt lõi của web trong tương lai, thực hiện tìm kiếm thông tin, tự động hóa, thanh toán, đàm phán hợp đồng
  • Ranh giới giữa hành vi của con người và agent sẽ trở nên mơ hồ, và điều này tất yếu đòi hỏi một hệ thống xác thực dựa trên ủy quyền
Quảng cáo

Authentication và Authorization

  • Authentication: Ai đang thực hiện hành động?
  • Authorization: Có thể làm gì?
  • Cloudflare nhầm lẫn hai khái niệm này và muốn giải quyết mọi vấn đề bằng một “hộ chiếu”, nhưng điều đó về căn bản là bất khả thi
  • Xác thực đúng đắn phải được triển khai thông qua chuỗi ủy quyền và chữ ký theo từng yêu cầu, đồng thời tận dụng các cơ chế kiểm chứng phân tán như phát hành khóa công khai dựa trên DNS

Quản lý quyền hạn

  • Phần mềm truyền thống hoạt động tốt với mô hình phạm vi OAuth nhờ phạm vi giới hạn
  • Nhưng agent có tính tổng quát, nên cần cấp quyền theo từng tác vụ (Task-Scoped)
  • Ví dụ: quyền “thanh toán bữa tối” và quyền “xem lịch sử chi tiêu 3 tháng” dù là cùng một agent cũng phải có các token khác nhau
  • Để làm điều này, có thể sử dụng token dựa trên ràng buộc như Macaroons, Biscuits, cùng các policy engine như OPA/AWS Cedar

Ưu tiên giao thức, loại bỏ gatekeeper

  • Xác thực, cấp quyền và kiếm tiền phải được xây dựng trên các tiêu chuẩn mở và có khả năng tương tác, thay vì phụ thuộc vào một công ty cụ thể
  • Nếu một số ít công ty phán định tính hợp lệ của agent, web sẽ sớm biến thành một Walled Garden khép kín
  • Vì vậy, cần đề xuất dưới dạng mã nguồn mở cho ủy quyền theo chuỗi, bằng chứng theo từng yêu cầu và cấp quyền theo phạm vi tác vụ để bất kỳ ai cũng có thể triển khai

Kết luận

  • Tương lai của web không phụ thuộc vào “ai kiểm soát cánh cổng”, mà vào các giao thức để mọi người cùng xây dựng và đổi mới

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-30
Ý kiến Hacker News

  • Mọi người đều mơ về một web hoàn toàn tự do và mở, nhưng thực tế lại thấy thất vọng vì người có blog nhỏ hay nội dung riêng gần như không có cách nào tự bảo vệ trước các bot huấn luyện AI; việc phân biệt Agent với bot training rồi tin rằng chúng sẽ thật sự tôn trọng robots.txt là không thực tế. Ngay cả nếu robots.txt được tuân thủ thì khái niệm mua dữ liệu gián tiếp dưới danh nghĩa “licensed data” vẫn sẽ tiếp diễn. Trừ khi là những công ty như Reddit, X, Google, Meta với nguồn lực pháp lý gần như vô hạn, cá nhân không có quyền lực gì. Cũng gợi ý một video khá thú vị về chuyện này.

    • Cảm giác mong muốn về một web tự do, mở cho mọi người và mong muốn chặn bot huấn luyện AI là mâu thuẫn với nhau; nếu là web mở cho tất cả thì bot huấn luyện AI về lý cũng phải được truy cập như mọi đối tượng khác.

    • (Về giấc mơ open web) Giấc mơ về nội dung mở trên internet là có thật; blog của tôi cho phép bất kỳ ai—con người hay máy móc—truy cập tự do. Máy chủ của tôi cũng do tôi tự host tại nhà nên tôi không thấy cần phải phân biệt giữa người và AI. Nếu lo ngại website có quá nhiều lượt truy cập, thì vấn đề thật ra là lưu lượng quá mức, bất kể từ người hay AI. Tôi chỉ đặt robots.txt như hướng dẫn tối thiểu để bot không bị kẹt vào vòng lặp, còn lại thì mở cho crawl tự do. Amazonbot cũng thường xuyên ghé site của tôi và luôn được chào đón.

    • Tôi nghĩ cần phát triển phần mềm tự do để chống lại phần mềm thù địch. Các tập đoàn lớn đang phát triển AI agent mang tính thù địch, và để đối phó thì các hacker giỏi cũng nên phát triển anti-AI-agent. Tôi không đồng ý với chủ nghĩa đầu hàng kiểu “chúng ta không có sức mạnh”.

    • Chỉ ra thực tế rằng trên Hacker News có rất nhiều kỹ sư từ các công ty IT lớn, nhưng trong chính công việc của họ lại không đụng tới quyền riêng tư và quản trị dữ liệu, trong khi lúc nào cũng chỉ hô hào về các vấn đề khác. Nếu cần một tấm gương để tự soi lại thì tôi sẵn sàng mua.

    • Tôi không hiểu vì sao lại nảy sinh câu hỏi rằng phải bảo vệ blog nhỏ hay nội dung nhỏ khỏi bot huấn luyện AI. Nếu đến cả việc tạo HTML cơ bản cũng khó nên phải dùng framework nặng và phức tạp, kéo theo tiêu tốn quá nhiều CPU, thì đó mới là vấn đề thực sự. Hoặc nếu ai đó nghĩ những bài viết online của mình là con đường dẫn đến tiền tài và danh tiếng của một content creator thì còn có lý do để lo, chứ nếu không thì tôi nghĩ chẳng có vấn đề gì cả.

  • Thực tế thì “web” từ lâu đã không còn mở nữa. Phần lớn tương tác, đăng bài, phân phối thông tin đều diễn ra sau lớp xác thực đăng nhập. Hầu hết mạng xã hội lớn, báo chí và các nền tảng tương tự đều hạn chế hoặc chặn truy cập không xác thực. Blog chỉ chiếm một tỷ lệ cực nhỏ trong tổng lượng thông tin mà người bình thường tiêu thụ.

    • Tôi không đồng ý với nhận định rằng “web không còn mở nữa”. Web không cần thêm gatekeeper, và nếu đã có quá nhiều rồi thì càng nên giảm bớt.

  • Bản thân tôi không quá bận tâm tới AI Agent; nếu phía sau có người dùng thật thì tôi thấy ổn. Nhưng việc Meta, Perplexity, OpenAI crawl site của tôi một cách quá mức là điều khiến tôi rất khó chịu. Việc crawl của AI còn ngốn tài nguyên hơn cả người dùng thật hay tìm kiếm Google. Hiện tượng các core CPU bị trói vào việc crawl của AI thực sự rất bực mình.

    • Tôi cũng có vài ứng dụng cá nhân đang chạy online, và tháng trước có một bot AI cào đi 1.6TB dữ liệu nên tôi buộc phải bật tính năng Cloudflare AI bot protection. Mỗi ngày có hơn 1,3 triệu request liên tục đổ vào, hoàn toàn không chịu nổi.

    • Ở một số site marketing của tôi, request vào ở mức 200–300 lần mỗi giây. Thậm chí chúng còn tự bịa ra các URL không tồn tại để gọi vào, đến mức gần như không thể kiểm soát.

    • Tôi tò mò không biết các công ty AI đang tạo ra bao nhiêu CPU cycle tiêu tốn chỉ vì crawl web. Thông thường khi nói về tác động môi trường của AI, người ta chỉ tính phần training hay inference khi phục vụ người dùng, nhưng rõ ràng cần tính thêm tải do web crawling gây ra. Để so sánh chính xác thì nên đặt cạnh trường hợp người dùng thật tự thực hiện cùng hành vi đó; nếu bot được thiết kế để tạo traffic hiệu quả hơn, chỉ gọi tối thiểu tracker, hình ảnh và các yếu tố phụ, chỉ lấy đúng thứ cần cho truy vấn mục tiêu, thì tổng tải CPU có khi còn thấp hơn việc toàn nhân loại trực tiếp mở trình duyệt để truy cập.

    • Tôi cũng vậy: nếu có người dùng thật đứng sau việc dùng AI agent, và nó không truy cập quá mức một cách bất thường, thì tôi không quá bận tâm. (Dù bản thân tôi không hề chủ đích để AI agent dùng site của mình, nhưng ai dùng thế nào tôi cũng không quá để ý.) Chỉ là tôi ghét crawl quá mức. Mặt khác, điều quan trọng hơn là có người chỉ đơn giản tải một file bằng curl hoặc dùng trình duyệt văn bản như Lynx; tôi nghĩ các kịch bản như vậy cũng phải tiếp tục được hỗ trợ.

    • Cloudflare đang phân biệt giữa agent do “người dùng khởi phát” thì cho phép và các agent khác thì chặn, nhằm tách biệt việc crawl bừa bãi để thu thập dữ liệu huấn luyện khỏi truy cập do người dùng thật tạo ra. Phần lớn request mà Meta, Perplexity, OpenAI gửi đi thực chất là chức năng web search hoạt động theo prompt của người dùng thật, và những request đó không được dùng để huấn luyện mô hình LLM tiếp theo. Cloudflare đang cố tình làm mờ ranh giới giữa hai loại này; bề ngoài họ nói là để “bảo vệ creator”, nhưng thực chất là xây một hệ thống để thu “phí qua đường” từ các nhà cung cấp LLM và kiếm lợi cho mình. Cuối cùng thì động cơ không phải là công bằng mà là tiền bạc.

  • Tôi dùng một trình duyệt hiếm, ít làm lộ thông tin cá nhân, nhưng từ góc nhìn của Cloudflare thì tôi cũng chẳng khác gì bot. Tôi cho rằng trong môi trường nơi host (chủ sở hữu website) quyết định quyền truy cập thì không thể có quyền riêng tư thực sự. Tôi đồng ý với rate limiting để ngăn tải máy chủ, nhưng việc chặn truy cập tự động về mặt thực tế là bất khả thi, và càng chặn như vậy thì cuối cùng người dùng thật cũng sẽ khó truy cập hơn.

    • Không biết hiện tại bạn có thường xuyên bị chặn bởi Cloudflare hay turnstile không? Trên kia bạn đã ám chỉ rồi nhưng tôi muốn xác nhận rõ hơn.

    • Nếu nhìn từ góc độ những người sống ở các nước độc tài, nơi họ phải dùng VPN để bảo vệ quyền riêng tư và tự do, thì internet sẽ biến thành địa ngục captcha do 2–3 công ty vận hành. Khi tôi dùng bot tự viết để truy cập website được Cloudflare bảo vệ thì còn ít vấn đề hơn so với lúc tôi dùng VPN và trình duyệt riêng tư để lướt web như người bình thường. Nhân tiện, nếu Microsoft mà là bên phụ trách gatekeeping của web thì còn tệ hơn nữa; đặc biệt nếu dùng VPN rồi phải vượt captcha của Microsoft thì phải tập trung hơn 5 phút như đang viết hẳn một bài luận mới qua nổi.

    • Chủ website dĩ nhiên cũng có quyền. Bảo họ không được chọn gatekeeping để đảm bảo tính bền vững tài chính cho việc vận hành là một đòi hỏi quá đáng.

    • Tôi cũng dùng trình duyệt hiếm nên thường bị bot blocker chặn. Dù vậy, tôi cũng nghĩ host có quyền xử lý request của tôi theo ý họ. Đặc biệt với website chính phủ thì trách nhiệm phục vụ công bằng cho mọi người còn lớn hơn nhiều.

  • Nếu có phương án thay thế tốt hơn và cởi mở hơn thì tôi rất muốn nghe, nhưng cách Cloudflare đang làm hiện nay giải quyết khá tốt vấn đề thực tế của AI bot. Trước giờ người ta cũng đã thử chặn bằng IP hay user agent nhưng đều có giới hạn. Và trên thực tế, các vấn đề bảo mật khác cũng thường được giải quyết bằng những cách hơi tập trung như vậy. Certificate authority cũng không phải là hệ thống mở, các nhà cung cấp attestation cũng không phải hệ thống mở, nhưng chúng vẫn hoạt động được.

    • Nếu muốn một giải pháp cởi mở hơn thì quy định pháp lý có thể là câu trả lời. Có thể cấm về mặt pháp luật mọi request từ crawler mà chủ website không cho phép rõ ràng trong robots.txt, rồi để cơ quan thực thi trực tiếp xử lý. Nếu chủ website chứng minh được lưu lượng bot, họ có thể báo chính phủ để phạt thật nặng. Nhà cung cấp dịch vụ cloud cũng có thể bị buộc phải lưu log về việc ai đã dùng IP nào. Đây không phải giải pháp 100%, nhưng nếu triển khai tốt thì đủ sức tạo hiệu ứng răn đe mạnh.

    • Có thể đây không phải giải pháp tốt nhất, nhưng trên thực tế là một giải pháp hoạt động được ở mức nào đó. Có nhiều chỉ trích về tính tập trung, nhưng nếu Cloudflare thành công trong việc kéo cả các công ty AI lớn lẫn các CDN cùng tham gia thì nó có thể gần như trở thành tiêu chuẩn trên thực tế.

    • Chứng chỉ không chặn con người chỉ vì bị nhầm là bot.

    • Tôi thậm chí nghĩ AI poisoning còn là cách bảo vệ hiệu quả hơn — tức cố tình trộn thông tin sai vào dữ liệu để gây nhiễu AI. Cloudflare bản thân họ cũng có thể cung cấp dịch vụ cố tình trả dữ liệu sai cho AI bot.

    • Thực ra CA trước khi có Let's Encrypt thường chỉ được dùng cho website doanh nghiệp thông thường, và thậm chí chỉ cho một số trang đăng nhập. Nếu không có chính sách mở của Let's Encrypt thì dữ liệu riêng tư của chúng ta vẫn sẽ bị lộ nguyên cho ISP hay kẻ trung gian. Các nhà cung cấp attestation cũng bất lực: ngay cả khi lỗ hổng thiết bị bị công khai rộng rãi, họ vẫn từ chối thu hồi chứng thực vì quyết định kinh doanh. Tóm lại, trong phần lớn các cuộc thảo luận, người ta dường như chưa tìm ra được giải pháp thay thế thực sự. Việc Cloudflare trở thành gatekeeper của internet là một lời giải tồi, nhưng bản thân vấn đề còn nghiêm trọng hơn nhiều. Những giải pháp hoàn toàn phân tán thật ra đã tồn tại rồi (ví dụ: remote attestation, mô hình trả phí theo lượt truy cập/đăng ký, firewall tự host, v.v.). Thái độ phớt lờ tác hại của AI rồi chỉ bảo mọi người hãy trả tiền chi phí đã góp phần làm Cloudflare ngày càng lớn. Nếu ISP và các bên khác trước đây không phớt lờ các vấn đề như spoofing, DDoS, botnet thì có lẽ Cloudflare chỉ dừng ở mức một đối thủ kiểu Akamai mà thôi.

  • Thế giới này đã có quá nhiều gatekeeper rồi. Mọi nỗ lực bổ sung thêm bất kỳ gatekeeper nào cũng nên bị xem là hành vi mang tính tấn công. Cloudflare lẫn Google đều đang cố đẩy mạnh hơn nữa vị thế gatekeeper của mình. Nếu xu hướng này tiếp diễn thì tôi muốn thấy cả hai sụp đổ hoàn toàn.

    • Nhiều công ty đang cố đưa ra giải pháp cho vấn đề AI bot, và nếu Cloudflare được chọn thì họ sẽ kiếm bộn tiền. Nhưng kể cả Cloudflare có lùi lại thì vấn đề cũng không biến mất; chỉ là một phương án tệ khác của công ty khác sẽ được áp dụng. Gatekeeping thực chất là một lựa chọn mà chủ website tự quyết (ví dụ: paywall, hệ thống tự phát hiện bot, xác minh ID, v.v.). Cloudflare vốn đã cung cấp các dịch vụ như vậy, và nếu điều đó còn được chuẩn hóa thì lựa chọn sẽ nhiều hơn và thị trường cũng rộng hơn nữa (cùng với tác dụng phụ của nó). Tự do của một open web đích thực không chỉ áp dụng cho người truy cập mà còn phải áp dụng ngang nhau cho chủ website.

    • “Ham muốn” của Google muốn làm gatekeeper tương lai thì hơi quá lời, vì thực ra Google đã đóng vai gatekeeper suốt nhiều năm nhờ thị phần Chrome rồi. Firefox cũng gần như mờ nhạt dần. Quan điểm ở đây là Google đã và đang lèo lái toàn bộ www theo hướng họ muốn (uBlock bị cấm, ép dùng định dạng .webp, v.v.).

  • Trước khi chỉ trích allowlist do một công ty vận hành, cũng cần nhớ rằng chính chủ site là người đã tự chọn dịch vụ đó. Điều thú vị là trong khi tranh luận về công bằng như một lập trường ý thức hệ, người ta lại đăng truyện tranh làm bằng công cụ AI lên blog của mình — một thực tế mâu thuẫn cho thấy AI đã ăn sâu vào đời sống hằng ngày.

    • Cloudflare đang triển khai tiêu chuẩn Web Bot Auth mới nổi, và bên Stytch của chúng tôi cũng áp dụng cùng tiêu chuẩn đó tại IsAgent.dev. Tôi nói điều này khá thận trọng vì thảo luận hiện tại đang hơi quá nóng, nhưng rốt cuộc allowlist chỉ là một tùy chọn Cloudflare cung cấp cho khách hàng của họ; còn phần lõi như HTTP Message Signature thì được thiết kế theo hướng mở/phân tán để bất kỳ ai cũng có thể dùng.

    • Việc dùng allowlist của một công ty như một lựa chọn riêng thì không có gì quá nghiêm trọng, nhưng chỉ thế thôi chưa thể biến nó thành giao thức. Và cuộc tranh luận về công bằng cũng không có liên hệ logic gì với việc dùng truyện tranh AI.

    • Trong tình huống kiểu giữa chảo nóng và lửa, có rủi ro giải pháp của một công ty cụ thể sẽ bị cố định như một tiêu chuẩn công khai trên thực tế. Lẽ ra đây có thể là dịp để tạo ra một giải pháp đúng nghĩa dựa trên giao thức/tiêu chuẩn, nhưng Cloudflare lại đang cố tạo ra một “đại dương xanh” cho riêng mình. Và việc họ nói về “công bằng” trong khi trên thực tế AI đã được dùng ở khắp nơi trong đời sống cũng là điểm bị mỉa khá khéo.

  • Tôi thấy nó giống với cấu trúc email. Email dựa trên tiêu chuẩn internet, nhưng phần lớn người dùng lại tập trung vào chỉ một số rất ít nhà cung cấp dịch vụ như Gmail. Cloudflare cũng đang thúc đẩy bản thân tiêu chuẩn mở, nhưng quyền lực thực sự của họ đến từ số lượng khách hàng khổng lồ. (Cũng đặt câu hỏi rằng có phương án thay thế tốt hơn nào không.) Và cũng giống như email gặp vấn đề độ tin cậy chuyển phát thấp, khó triển khai do lọc spam, web cũng có thể đi theo con đường tương tự.

    • Trên thực tế hầu như không có lựa chọn nào thay thế được Cloudflare như một CDN miễn phí. Họ đặt máy chủ trên toàn thế giới và phát miễn phí, rồi kiếm tiền từ các dịch vụ serverless cao cấp. Trong khi đó, các nhà cung cấp cloud lớn lại tính phí egress traffic cao một cách bất thường.

  • Web không cần attestation, signed agent, hay Cloudflare quyết định ai là agent “thật”. Mọi người nên nhận thức lại ý nghĩa của “public”, và nếu xử lý traffic khó khăn thì tốt nhất chỉ cần rate limiting cơ bản. Web không cần phân biệt là người, bot hay chó; chỉ cần trong giới hạn tài nguyên hợp lý, cung cấp byte cho mọi bên gửi request là đủ. Nếu bản chất này của “open web” biến mất, tất cả chúng ta sẽ đều thấy đáng tiếc.

    • Ngay cả rate limiting cơ bản cũng dễ bị tấn công. Không thể phớt lờ botnet, và khi chuyển sang IPv6 thì rate limiting hữu ích trên thực tế gần như bất khả thi. Nếu chia buckets sai, có nhà mạng sẽ cấp /48 quá dễ dãi khiến limit bị vô hiệu hóa, hoặc người dùng di động thì hàng trăm nghìn người lại bị gom vào cùng một rate limit.

    • Cách này rốt cuộc chẳng khác nào bảo vô số website nhỏ hãy đóng cửa vì không chịu nổi lưu lượng, điều đó mâu thuẫn với khẩu hiệu “internet mở”.

    • Crawler AI hiện đại giờ gần như không thể phân biệt được với botnet độc hại. Rate limiting thông thường không còn nhiều ý nghĩa nữa, và đó chính là điểm Cloudflare bước vào để cố giải quyết vấn đề.

    • Lập luận “public nghĩa là PUBLIC” nghe thì hay nếu chỉ cần rate limiting cơ bản là đủ để vận hành, nhưng trên thực tế cần phải công khai cả tốc độ truy cập nào là chấp nhận được. Tuy vậy, rất nhiều trường hợp chỉ vì user-agent khác lạ mà mới request một lần cũng đã bị chặn. Cuối cùng, operator thường có xu hướng chặn mọi request chỉ dựa trên danh tính chứ không dựa trên hành vi bot. Tiêu chí phán đoán quá thô, tạo ra rất nhiều false positive; và ngay cả trong trường hợp như vậy, chẳng có nỗ lực hay ngữ cảnh nào được xem xét, chỉ nhìn danh tính là quyết định chặn.

    • Ngay cả rate limiting cơ bản trong nhiều trường hợp cũng không dễ triển khai. Trừ khi cần một dạng xác thực/ủy quyền cụ thể nào đó, còn với truy cập file công khai thì tôi nghĩ không cần thêm xác thực hay ủy quyền gì cả. Kể cả khi có các vấn đề ủy quyền như vậy thì ngoài chính bên ủy quyền ra, cũng không cần Cloudflare hay bất kỳ bên thứ ba nào can dự.

  • Tôi đồng ý với phần lớn quan điểm của tác giả. Trong môi trường enterprise, điều khiến tôi băn khoăn là làm sao kiểm soát hành vi của agent trong các mạng riêng phức tạp. Gần đây tôi tự làm một hệ thống “identity token” dựa trên biscuit; với token này, bản thân một agent có thể tự xác thực, rồi tiếp đó tạo delegation token để trao cho các agent cấp dưới. Trong hệ thống của tôi, nếu không có authorization token thì không làm được gì cả (kiểu single scope, single use). Nếu áp dụng trên internet, tôi hình dung có thể trao đổi identity token + micropayment (ví dụ một giao dịch crypto cực nhỏ) để nhận authorization token. Khi đó người dùng là con người gần như không tốn chi phí nên không thành vấn đề, còn chỉ các AI crawler mới phải trả nhiều tiền.