SO SÁNH

Proof of Actor so với danh sách cho phép user agent: một cái tên là lời khai, không phải bằng chứng

Cho phép theo chuỗi User-Agent thiết lập nhanh và dễ hiểu. Nó cũng rất dễ bị đánh lừa, vì header này chỉ là thứ client tự chọn gửi đi. Dưới đây là những gì một danh sách cho phép user agent thực sự cho bạn biết, khi nào kiểm tra mạng có ích, và cách Proof of Actor tách lời khai ra khỏi bằng chứng đã xác minh.

Nhận quyền truy cập sớm Khám phá cách hoạt động

Bởi Toshendra SharmaNhà sáng lập và CEO, AgentCredia · Updated November 13, 2026

Danh sách cho phép user agent là một trong những mẫu lâu đời nhất trên web. Bạn giữ một danh sách các tên crawler và client mà bạn tin cậy. Khi một request đến với header User-Agent khớp, bạn cho qua, bỏ qua một bước challenge, hoặc phục vụ cho nó một trang nhẹ hơn. Chỉ mất vài phút để thiết lập và mọi người trong nhóm đều hiểu nó.

Mẫu này hợp lý hơn khi phần lớn khách truy cập tự động chỉ là vài crawler tìm kiếm và một số công cụ giám sát. Ngày nay, agent AI, trợ lý và các client tự động đến ứng dụng với số lượng ngày càng tăng, và nhiều trong số đó tự khai báo tên. Một số tên là thật. Một số bị sao chép. Header không thể cho bạn biết cái nào.

Proof of Actor đi theo cách tiếp cận khác. Nó xem chuỗi User-Agent đúng với bản chất của nó, là một lời khai, và báo nó cùng với bằng chứng mạnh hơn khi bằng chứng đó tồn tại. Trang này giải thích giới hạn của việc cho phép theo tên, khi nào kiểm tra ở cấp mạng có ích, và cách chữ ký đã xác minh cùng lớp Unknown rõ ràng thay đổi bức tranh.

Bản tóm tắt ngắn

	danh sách cho phép user agent	Proof of Actor
Bằng chứng chính	Một tên trong header User-Agent	Chữ ký, lời khai và tín hiệu, mỗi thứ được gắn nhãn theo basis của nó
Client có thể giả mạo không?	Có, bằng cách gửi cùng một chuỗi	Basis declared có thể được khai báo; basis verified cần signing key
Kết quả	Có trong danh sách hay không	Human, Human + AI, Agent hoặc Unknown, cộng với một basis
Lưu lượng không rõ ràng	Bị coi là không được phép, hoặc được cho qua theo mặc định	Unknown, với phương án dự phòng bạn chọn theo từng route
Người dùng có hỗ trợ AI	Vô hình; họ dùng browser thông thường	Một lớp riêng, Human + AI, khi được khai báo hoặc quan sát thấy
Bảo trì	Cập nhật danh sách thủ công khi tên thay đổi	Key do nhà vận hành agent công bố; policy nằm trong code của bạn
Mặc định khi cài đặt	Bất cứ điều gì danh sách cho phép	Quan sát; không thay đổi gì cho đến khi bạn thêm policy
Phù hợp nhất cho	Định tuyến rẻ cho các client đã biết và hoạt động đúng	Ngữ cảnh actor dựa trên bằng chứng cho quyết định sản phẩm và policy

Phần còn lại của trang giải thích từng dòng.

Vì sao cho phép theo User-Agent dễ bị giả mạo

Header User-Agent do client đặt. Browser đặt nó, script đặt nó, và framework của agent cũng đặt nó. Không có gì trong HTTP kiểm tra rằng giá trị đó là thật. Nếu danh sách cho phép của bạn tin vào một chuỗi, bất kỳ ai sao chép chuỗi đó đều nhận được cách xử lý giống nhau.

Điều này được gọi là user agent spoofing, và nó phổ biến vì một lý do đơn giản: tốn gần như không có gì. Một scraper muốn tránh challenge chỉ cần mượn tên của một crawler mà bạn tin cậy. Một client hoạt động không đúng có thể tự nhận là một trợ lý phổ biến. Một công cụ hợp lệ thậm chí có thể gửi chuỗi browser chung chung vì mặc định của thư viện đã làm vậy.

Kết quả là một danh sách cho phép user agent có hai kiểu lỗi:

Tin nhầm: một client không đáng tin tự nhận tên đáng tin và đi qua.
Nghi ngờ nhầm: một client hợp lệ gửi chuỗi bất ngờ hoặc chung chung và bị loại.

Không kiểu lỗi nào hiện ra chỉ từ header. Đó là giới hạn cốt lõi, và không có cách nào bảo trì danh sách mà loại bỏ được nó.

Header này vẫn hữu ích ở điểm nào

Điều đó không có nghĩa là bạn nên bỏ qua chuỗi User-Agent. Các crawler và agent hoạt động đúng sẽ tự khai báo trung thực, và tên đó là một tín hiệu hữu ích cho routing, phân tích và gỡ lỗi. Nó cho bạn biết client nói mình là gì.

Nơi phù hợp cho thông tin đó là như một lời khai, được cân cùng các bằng chứng khác, chứ không phải một chìa khóa tự mở quyền truy cập. Proof of Actor ghi nhận đúng theo cách đó.

Reverse DNS và danh sách IP: các biện pháp một phần

Nhiều nhóm tăng cường danh sách cho phép bằng các kiểm tra mạng. Chúng có ích, và cần hiểu chính xác.

Xác minh reverse DNS

Một số nhà vận hành crawler mô tả quy trình xác minh: tra hostname cho địa chỉ IP của request, kiểm tra rằng nó thuộc miền của nhà vận hành, rồi tra lại hostname đó và xác nhận nó phân giải về cùng địa chỉ IP. Khi vòng này thành công, bạn có bằng chứng thực rằng request đến từ hạ tầng của nhà vận hành.

Giới hạn là thực tế. Nó chỉ hoạt động với các nhà vận hành có tài liệu và hỗ trợ quy trình đó. Nó thêm các lượt tra cứu DNS mà bạn cần lưu cache. Và nó cho bạn biết về mạng, chứ không cho biết sản phẩm hay agent nào đã tạo request trên mạng đó.

Các dải IP đã công bố

Những nhà vận hành khác công bố các dải IP mà client tự động của họ dùng. So khớp request với những dải đó là nhanh và cho bằng chứng tương tự reverse DNS. Hiện vẫn có thảo luận của IETF về một định dạng chuẩn để công bố các dải này, nhưng tính đến tháng 11 năm 2026 thì chưa có chuẩn thống nhất, và mức độ bao phủ phụ thuộc vào việc từng nhà vận hành có chọn công bố hay không.

Bằng chứng từ IP cũng yếu đi khi nhiều agent chạy trên hạ tầng cloud dùng chung, sau proxy, hoặc từ chính thiết bị của người dùng. Một địa chỉ cloud có thể chứa nhiều client không liên quan, và một agent hoạt động từ browser của người dùng sẽ trông giống mạng của chính người đó.

Các kiểm tra mạng cộng lại mang lại gì

Reverse DNS và danh sách IP biến một số lời khai thành thứ mạnh hơn cho một tập con các nhà vận hành đã biết. Chúng không bao phủ phần đuôi dài của agent và công cụ, và hoàn toàn không giúp gì cho những người làm việc cùng AI. Chúng là các biện pháp một phần: đáng dùng, nhưng không đủ nếu đứng một mình.

Chữ ký so với lời khai

Dạng bằng chứng mạnh hơn là chữ ký mật mã. Với HTTP Message Signatures, được định nghĩa trong RFC 9421, client ký các phần được chọn của mỗi request bằng private key. Bộ xác minh sẽ lấy public key đã công bố của nhà vận hành và kiểm tra chữ ký. Nếu hợp lệ, request đã được ký bởi người giữ key đó, và các phần đã ký không bị thay đổi trên đường đi.

Nhóm làm việc Web Bot Auth của IETF đang chuẩn hóa cách client tự động dùng các chữ ký này và cách họ công bố key của mình. Phần giải thích của chúng tôi về Web Bot Auth cho nhóm sản phẩm trình bày trạng thái hiện tại.

Proof of Actor dùng một chữ ký hợp lệ như bằng chứng Verified. Một chuỗi User-Agent, client hint hoặc phần tự mô tả trong body request được tính là Declared. Các tín hiệu hành vi và ngữ cảnh được tính là Inferred, và được gắn nhãn như vậy. Mỗi kết quả đều nói rõ nó dựa trên basis nào, để nhóm của bạn không bao giờ nhầm một lời khai với một kiểm tra. Xem mục evidence basis để có định nghĩa đầy đủ.

Có một giới hạn ngay cả với bằng chứng verified. Một chữ ký hợp lệ chứng minh khóa nào đã ký request. Nó không chứng minh agent được phép làm điều nó đang xin làm. Đó là câu hỏi agent authorization, và nó vẫn nằm trong ứng dụng của bạn.

Xử lý Unknown thay vì đoán

Một danh sách cho phép buộc mọi request vào một trong hai nhóm: có trong danh sách hoặc không. Trong thực tế, điều đó có nghĩa là lưu lượng không rõ ràng sẽ nhận bất kỳ giá trị mặc định nào của bạn, và mặc định đó thường được chọn một lần cho toàn bộ site.

Proof of Actor xem Unknown là một kết quả hạng nhất. Khi bằng chứng không đủ để đưa ra một kết luận đáng tin cậy, nó nói rõ điều đó thay vì đoán. Rồi policy của bạn sẽ quyết định Unknown có nghĩa gì ở từng route:

Trên tài liệu công khai hoặc trang marketing, cho qua.
Trên các endpoint tìm kiếm hoặc liệt kê, cho qua với rate limit thông thường của bạn.
Với thay đổi tài khoản, giữ nguyên các kiểm tra hiện có.
Với hành động có tác động lớn, đưa vào review hoặc yêu cầu tín hiệu mạnh hơn.

Hướng dẫn về handling Unknown traffic và mục unknown classification sẽ đi qua các mẫu này. Theo dõi tỷ lệ Unknown theo thời gian cũng cho bạn biết bao nhiêu lưu lượng của mình vẫn còn dựa trên bằng chứng yếu.

Còn với người dùng có hỗ trợ AI thì sao?

Một danh sách cho phép user agent không nói gì về một người đang dùng trợ lý AI trong browser thông thường. User-Agent của họ chỉ là chuỗi browser bình thường. Tuy nhiên nhiều sản phẩm muốn nhận ra tương tác đó, chẳng hạn để gắn nhãn các bản gửi được AI hỗ trợ hoặc hiểu cách người dùng có hỗ trợ AI đi qua onboarding.

Proof of Actor báo các tương tác đó là Human + AI khi sự hỗ trợ đó được khai báo hoặc quan sát được qua một tích hợp được hỗ trợ. Nó không đoán chỉ từ phong cách viết. Xem thêm trong AI-assisted interaction.

Chuyển từ danh sách cho phép sang policy dựa trên bằng chứng

Bạn không cần xóa danh sách cho phép ngay từ ngày đầu. Một lộ trình an toàn sẽ như sau:

Cài ở chế độ quan sát. Proof of Actor không thay đổi gì. Danh sách cho phép của bạn vẫn hoạt động.
So sánh. Với từng route, xem request nào trong danh sách cho phép có bằng chứng verified, request nào chỉ có một lời khai, và request nào rơi vào Unknown.
Xem trước policy. Soạn một policy xử lý khác nhau cho agent verified, agent declared và Unknown, rồi xem trước tác động của nó trên lưu lượng thực.
Bật enforcement theo từng route. Bắt đầu với các route mà một cái tên bị giả mạo sẽ gây ảnh hưởng lớn nhất.
Giữ danh sách cho phép như một tín hiệu. Tên vẫn hữu ích cho routing và phân tích, giờ đây với basis được nhìn thấy.

Hướng dẫn về rolling out actor-aware policies safely bao quát từng bước, và verified automated requests giải thích cách client được ký phù hợp với mô hình này.

Khi nào danh sách cho phép là đủ

Với routing ít rủi ro, như phục vụ một trang nhẹ hơn cho một crawler đã biết trên nội dung công khai, một danh sách cho phép user agent thường là đủ. Cái giá của một tên bị giả mạo là nhỏ.

Khi quyết định có hệ quả, như bỏ qua challenge, mở dữ liệu phong phú hơn, hoặc cho phép một thao tác ghi, bạn cần bằng chứng có thể kiểm tra. Đó là nơi Proof of Actor phù hợp, chạy cùng các kiểm tra mạng và các kiểm soát edge mà bạn đã có.

Bắt đầu

Proof of Actor đang ở private beta. Các nhóm founding developer được chọn có thể nhận tối đa 12 tháng truy cập miễn phí trong giới hạn sử dụng đã thống nhất, không tự động tính phí. Apply for early access và cho chúng tôi biết những client nào bạn đang cho phép theo danh sách hôm nay và những route nào bạn muốn bảo vệ bằng bằng chứng tốt hơn.

DÀNH CHO NHÀ PHÁT TRIỂN

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent hoặc Unknown.
basis: Bằng chứng mạnh đến mức nào: verified, declared, inferred hoặc unknown.
evidence: Các tín hiệu phía sau kết quả, để team của bạn thấy được lý do.

Bắt đầu ở chế độ quan sát: ghi kết quả cạnh logs của bạn và không thay đổi gì cho đến khi bạn chọn một chính sách. Đọc hướng dẫn tích hợp Node.js

Câu hỏi thường gặp

Danh sách cho phép user agent có vô dụng không?

Không. Nó là một lời khai hữu ích từ các client hoạt động đúng và là cách rẻ để định tuyến crawler đã biết. Vấn đề là coi nó như bằng chứng. Bất kỳ client nào cũng có thể gửi bất kỳ chuỗi User-Agent nào, nên một danh sách cho phép đơn lẻ không bao giờ nên mở khóa các hành động nhạy cảm.

Xác minh reverse DNS có khắc phục được việc giả mạo User-Agent không?

Nó có ích cho những nhà vận hành có tài liệu mô tả rõ. Một tra cứu ngược rồi tra cứu xuôi khớp nhau sẽ gắn một địa chỉ IP với miền của nhà vận hành. Nó chỉ hoạt động với các nhà vận hành hỗ trợ nó, và không nói gì về lưu lượng từ các địa chỉ cloud dùng chung hoặc địa chỉ dân dụng.

Proof of Actor xử lý header User-Agent như thế nào?

Như một lời khai. Nó góp vào kết quả với basis declared, chứ không bao giờ là verified. Basis verified đòi hỏi bằng chứng như HTTP Message Signature đã được kiểm tra với một public key đã công bố.

Một chữ ký đã xác minh chứng minh điều gì?

Nó chứng minh khóa nào đã ký request và phần đã ký không bị thay đổi. Nó không chứng minh agent được phép thực hiện hành động đó. Quyền ủy quyền vẫn nằm trong ứng dụng của bạn.

Điều gì xảy ra với client tự nhận là một agent đã biết nhưng không thể xác minh?

Proof of Actor báo những gì bằng chứng hỗ trợ, thường là kết quả declared hoặc inferred, hoặc Unknown. Policy của bạn sẽ chọn phương án dự phòng cho route đó thay vì tin vào cái tên được khai báo.

Thêm Proof of Actor có thay đổi hành vi danh sách cho phép hiện tại của tôi không?

Không. Nó bắt đầu ở chế độ quan sát. Bạn có thể so sánh kết quả của nó với quyết định danh sách cho phép trên lưu lượng thực trước khi thay đổi bất kỳ điều gì.

Biết ai đang dùng app của bạn.

Private beta dành cho một nhóm nhỏ các nhà phát triển sáng lập.

Nhận quyền truy cập sớm Xem giá

Bạn muốn trao đổi trước? Trao đổi với những người sáng lập