GIẢI THÍCH

Web Bot Auth cho nhóm sản phẩm: các yêu cầu tác tử đã ký có ý nghĩa gì đối với lộ trình của bạn

Tác tử AI và trình thu thập dữ liệu ngày càng cần một cách để chứng minh danh tính mà không phải dựa vào chuỗi User-Agent mà bất kỳ ai cũng có thể sao chép. Công việc IETF Web Bot Auth là nỗ lực hàng đầu để chuẩn hóa điều đó. Đây là phần giải thích ngắn gọn cho quản lý sản phẩm và lãnh đạo kỹ thuật: cách nó hoạt động, nó chứng minh điều gì, trạng thái của nó tính đến tháng 11 năm 2026, và cách lập kế hoạch cho nó.

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

Trong nhiều năm, cách duy nhất để một máy khách tự động có thể nói với một trang web biết mình là ai là dựa vào một tên trong header User-Agent và, với một vài nhà vận hành lớn, một danh sách địa chỉ IP đã công bố hoặc kiểm tra reverse DNS. Tên thì dễ sao chép. Danh sách mạng chỉ bao phủ những nhà vận hành tự duy trì chúng. Khi các tác tử AI bắt đầu hành động cho người thật trên web, khoảng trống này đã trở thành vấn đề sản phẩm, không chỉ là vấn đề bảo mật.

Web Bot Auth là nỗ lực hàng đầu để khép lại khoảng trống đó. Nó cung cấp cho các máy khách tự động một cách để ký yêu cầu của họ bằng một khóa do họ kiểm soát và công bố, để một trang web có thể kiểm tra chữ ký thay vì tin vào một cái tên. Phần giải thích này dành cho quản lý sản phẩm và lãnh đạo kỹ thuật cần hiểu nó là gì, nó thay đổi điều gì, và điều gì nó không thay đổi, mà không cần đọc đặc tả từ đầu đến cuối.

Tóm tắt ngắn

Nó là gì: một nhóm làm việc IETF, webbotauth, và cách tiếp cận mà nhóm này đang chuẩn hóa để xác thực các máy khách HTTP tự động.
Nó hoạt động thế nào: máy khách ký các phần của mỗi yêu cầu bằng HTTP Message Signatures (RFC 9421) và chỉ tới một thư mục khóa công khai của nó. Trang web lấy khóa và xác minh chữ ký.
Nó chứng minh điều gì: khóa nào đã ký yêu cầu, và các phần đã ký không bị thay đổi trong quá trình truyền.
Nó không chứng minh điều gì: rằng tác tử được ủy quyền để thực hiện hành động đang yêu cầu, rằng nó hành động thay cho một người dùng cụ thể, hoặc rằng nó sẽ cư xử tốt.
Trạng thái tính đến tháng 11 năm 2026: RFC 9421 là một Proposed Standard đã được công bố. Tài liệu giao thức Web Bot Auth vẫn là một Internet-Draft của nhóm làm việc, chưa phải RFC.
Cần làm gì: lên kế hoạch coi các chữ ký hợp lệ là bằng chứng mạnh, tiếp tục xử lý lưu lượng không có chữ ký, và giữ các quyết định ủy quyền trong code của bạn.

Công việc Web Bot Auth của IETF là gì

IETF đã lập ra nhóm làm việc Web Bot Auth để chuẩn hóa các phương pháp xác thực bằng mật mã cho các máy khách tự động và để cung cấp cho các trang web thêm thông tin về các operator đứng sau chúng. Điều khoản của nhóm tập trung vào các trang web chủ yếu phục vụ con người, và nêu một phạm vi rộng các máy khách: trình thu thập dữ liệu, kho lưu trữ web, trình kiểm tra liên kết, trình thu thập dữ liệu huấn luyện AI và các tác tử AI hành động thay cho người dùng cuối.

Điều khoản của nhóm có hai điểm loại trừ đáng chú ý đối với các nhóm sản phẩm. Xác thực người dùng cuối nằm ngoài phạm vi, nên đây không phải là cách để đăng nhập một người. Theo dõi uy tín của bot cũng nằm ngoài phạm vi, nên tiêu chuẩn này cho bạn biết ai đã ký một yêu cầu, chứ không nói liệu operator đó có đáng tin hay không.

Điều khoản liệt kê ba loại đầu ra:

Các tài liệu theo lộ trình tiêu chuẩn về kỹ thuật xác thực các máy khách tự động vào các trang web được xây dựng cho con người.
Các tài liệu theo lộ trình tiêu chuẩn về việc truyền đạt thêm thông tin về một bot yêu cầu bằng cách dùng một định danh hiện có như tên miền hoặc URL.
Các tài liệu thực hành tốt nhất hiện hành hoặc tài liệu thông tin về các chủ đề vận hành như quản lý khóa, vòng đời và triển khai.

Trạng thái các tài liệu, tính đến tháng 11 năm 2026

Tính đến tháng 11 năm 2026, nhóm làm việc có một tài liệu đã được chấp nhận: draft-ietf-webbotauth-httpsig-protocol, có tiêu đề "HTTP Message Signatures for automated traffic", ở bản sửa đổi 01, ngày 29 tháng 10 năm 2026. Đây là một Internet-Draft, nghĩa là tài liệu đang trong quá trình phát triển và vẫn có thể thay đổi. Nó chưa phải RFC.

Một số bản nháp cá nhân cũng gắn với nhóm và đang được thảo luận, bao gồm các đề xuất về định dạng sổ đăng ký và thẻ tác tử, xác thực bot ẩn danh, một định dạng JSON để công bố các dải IP của máy khách tự động, và một header cho siêu dữ liệu tác tử đã ký. Các bản nháp cá nhân là đề xuất; tính đến ngày này, không bản nào đã được nhóm chấp nhận.

Điều khoản đặt ra các mốc trong năm 2026 để gửi các đặc tả cho IESG phê duyệt. Tính đến tháng 11 năm 2026, tài liệu giao thức vẫn là bản nháp của nhóm làm việc. Bạn có thể theo dõi trạng thái hiện tại trên trang datatracker của IETF cho nhóm làm việc và bản nháp giao thức.

Cách HTTP Message Signatures hoạt động

Web Bot Auth dựa trên RFC 9421, HTTP Message Signatures, được công bố vào tháng 2 năm 2024 dưới dạng Proposed Standard. RFC 9421 là một cơ chế tổng quát: nó định nghĩa cách ký các phần được chọn của một thông điệp HTTP và cách mang chữ ký trong headers. Web Bot Auth điều chỉnh nó cho các máy khách tự động.

Nói đơn giản, một yêu cầu tác tử đã ký hoạt động như sau:

Operator tạo một cặp khóa. Nó giữ bí mật private key và công bố public key.
Máy khách chọn những phần cần ký. Nó chọn các thành phần của yêu cầu, như host đích hoặc URI và thời điểm tạo. Bản nháp hiện tại yêu cầu bao phủ authority hoặc target URI, để một chữ ký cho một site không thể đơn giản bị phát lại sang site khác.
Máy khách ký và gửi. Yêu cầu mang một header Signature-Input mô tả những gì đã được ký và bằng khóa nào, cùng với một header Signature chứa giá trị chữ ký. Bản nháp dùng một thẻ web-bot-auth và yêu cầu thời điểm tạo và hết hạn trên mỗi chữ ký.
Trang web xác minh. Nó tìm public key, dựng lại các thành phần đã ký từ yêu cầu nó nhận được, và kiểm tra chữ ký. Nếu kiểm tra đạt, yêu cầu đã được ký bởi người giữ khóa đó và các phần được bao phủ không bị thay đổi.

Bản nháp cũng cho phép một trang web yêu cầu chữ ký. Một origin có thể gửi header Accept-Signature, thường kèm theo một từ chối, để báo rằng nó muốn nhận các yêu cầu đã ký.

Ý tưởng thư mục khóa

Một chữ ký chỉ hữu ích nếu trang web có thể tìm đúng public key. Web Bot Auth giải quyết điều đó bằng một thư mục khóa.

Trong bản nháp hiện tại của nhóm làm việc, máy khách thêm một header Signature-Agent chứa một URL HTTPS. URL đó cung cấp một thư mục các public key của operator dưới dạng JSON Web Key Set. Trang web lấy thư mục, chọn khóa khớp với định danh khóa trong chữ ký, rồi xác minh. Bản nháp cũng định nghĩa một path quen thuộc, /.well-known/http-message-signatures-directory, nơi operator có thể phục vụ thư mục của mình.

Ý tưởng hữu ích cho các nhóm sản phẩm là URL trở thành danh tính. Operator của tác tử được xác định bởi nơi nó công bố khóa, và điều đó ràng buộc chữ ký với một domain mà operator kiểm soát. Xoay vòng khóa hoạt động bằng cách công bố một khóa mới bên cạnh khóa cũ, rồi xóa khóa cũ.

Các trang web xác minh cần xử lý thư mục cẩn thận: lưu đệm theo các quy tắc HTTP thông thường, đặt giới hạn kích thước và thời gian chờ, và tránh lấy dữ liệu từ các địa chỉ mạng riêng. Đây là các mối quan tâm kỹ thuật tiêu chuẩn, và cũng là lý do nhiều nhóm thích một thành phần tự làm việc xác minh cho họ.

Chữ ký hợp lệ chứng minh điều gì, và không chứng minh điều gì

Đây là phần quan trọng nhất đối với bất kỳ ai viết chính sách sản phẩm.

Một chữ ký hợp lệ chứng minh:

Yêu cầu đã được ký bởi người giữ một private key cụ thể.
Khóa đó được công bố tại một URL thư mục do operator kiểm soát.
Các phần đã ký của yêu cầu không bị thay đổi trong quá trình truyền, và chữ ký nằm trong khoảng hiệu lực của nó.

Một chữ ký hợp lệ không chứng minh:

Rằng tác tử đó được ủy quyền để thực hiện hành động. Có thể nhận dạng không đồng nghĩa với được phép. Xem agent authorization.
Rằng tác tử hành động thay cho một người cụ thể, hoặc trong phạm vi quyền hạn mà người đó đã trao. Xem delegated authority.
Rằng operator đáng tin hoặc rằng tác tử sẽ cư xử tốt. Uy tín được nhóm làm việc loại trừ rõ ràng khỏi phạm vi.
Bất kỳ điều gì về các yêu cầu không có chữ ký. Lưu lượng không có chữ ký vẫn cần cách xử lý riêng.

Hãy coi một chữ ký hợp lệ là bằng chứng mạnh về ai đã gửi yêu cầu, rồi để kiểm soát truy cập của chính bạn quyết định người gửi đó được làm gì.

Các nhóm sản phẩm nên làm gì với nó

Bạn không cần đợi RFC mới lập kế hoạch. Lưu lượng tác tử đã ký là điều bạn có thể chuẩn bị ngay, với kỳ vọng rằng một số chi tiết của bản nháp có thể thay đổi.

1. Đo lường trước khi quyết định

Tìm hiểu bao nhiêu lưu lượng của bạn là tự động, tác tử dùng những route nào, và bao nhiêu trong số đó đã được ký. Hãy bắt đầu ở chế độ quan sát để việc đo lường không thay đổi gì đối với người dùng của bạn.

2. Tách bằng chứng khỏi chính sách

Ghi lại điều bằng chứng cho thấy, verified, declared, inferred hoặc unknown, tách biệt với điều bạn quyết định làm. Làm vậy sẽ giúp chính sách dễ đọc hơn và cho phép bạn siết chặt hoặc nới lỏng chúng mà không phải triển khai lại công cụ đo. Mục cơ sở bằng chứng giải thích bốn mức này.

3. Cho tác tử verified một đường đi tốt hơn

Ở nơi hợp lý, hãy phục vụ tác tử verified nội dung có cấu trúc hoặc một luồng thân thiện với tác tử thay vì các trang được xây cho con người. Hướng dẫn về phục vụ tác tử AI bằng nội dung có cấu trúc trình bày các mẫu này.

4. Giữ ủy quyền trong code của bạn

Dùng chữ ký để biết ai đang yêu cầu. Dùng các quyền, phạm vi và xác nhận hiện có của bạn để quyết định họ được làm gì. Những hành động có tác động lớn vẫn có thể cần một xác nhận của con người, bất kể ai đã ký yêu cầu. Xem bảo vệ các hành động nhạy cảm mà không chặn tác tử.

5. Lập kế hoạch cho lưu lượng không có chữ ký và Unknown

Hỗ trợ việc ký khác nhau giữa các tác tử và công cụ, vì vậy hãy kỳ vọng trong một thời gian sẽ có cả yêu cầu đã ký và chưa ký. Quyết định theo từng route điều gì xảy ra với lưu lượng declared, inferred và Unknown, thay vì chọn một quy tắc áp dụng cho toàn site. Hướng dẫn về xử lý lưu lượng Unknown sẽ đi qua vấn đề này.

Proof of Actor dùng Web Bot Auth như thế nào

Proof of Actor cho ứng dụng của bạn biết ai hoặc cái gì đang hành động trong mỗi tương tác, Human, Human + AI, Agent hoặc Unknown, và nêu rõ cơ sở bằng chứng. Chữ ký Web Bot Auth là một trong những nguồn bằng chứng mạnh nhất của nó.

Khi một tác tử ký yêu cầu của nó bằng HTTP Message Signatures, Proof of Actor sẽ kiểm tra chữ ký với public key đã được công bố của operator. Nếu kiểm tra đạt, kết quả sẽ mang cơ sở verified, cùng với bằng chứng mà nhóm của bạn có thể xem xét. Nếu một máy khách chỉ tự khai báo mình trong một header, kết quả là declared. Nếu kết luận dựa trên các tín hiệu hành vi hoặc ngữ cảnh, nó được gắn nhãn inferred. Nếu bằng chứng chưa đủ, kết quả là Unknown.

Ứng dụng của bạn quyết định làm gì với ngữ cảnh đó. Chính sách được viết theo từng route, từng lớp tác tử và từng cơ sở, với các kết quả như allow, adapt, challenge, review và rate-limit. Không có gì được enforce theo mặc định: bạn preview một chính sách trên lưu lượng thực tế và enforce theo từng route, trong code của chính bạn.

Các đội Founding có thể thu thập bằng chứng qua middleware Node.js, Next.js, một tích hợp edge, một trình thu thập trên trình duyệt ở các trang được phê duyệt, HTTP API tổng quát, hoặc một tích hợp MCP server. Xem tích hợp, và hướng dẫn xác minh các yêu cầu tác tử đã ký để biết các bước thực tế.

Proof of Actor tuân theo giới hạn giống như tiêu chuẩn: một chữ ký verified cho bạn biết khóa nào đã ký yêu cầu, chứ không cho biết tác tử đó có được ủy quyền hay không. Ủy quyền vẫn thuộc về bạn. Trang bằng chứng và giới hạn nêu rõ mỗi kết quả có thể và không thể hỗ trợ điều gì.

Bắt đầu

Proof of Actor đang ở private beta. Các đội phát triển Founding đượ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ỏa thuận, không có thanh toán tự động. Đăng ký quyền truy cập sớm và cho chúng tôi biết những route nào bạn dự kiến các tác tử đã ký sẽ dùng và bạn muốn làm gì với chúng.

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

Web Bot Auth là gì?

Web Bot Auth là tên của một nhóm làm việc IETF, webbotauth, và cũng là cách tiếp cận mà nhóm này đang chuẩn hóa: các máy khách tự động ký các yêu cầu HTTP bằng HTTP Message Signatures (RFC 9421) và công bố khóa công khai của họ, để các trang web có thể xác minh operator nào đã gửi một yêu cầu.

Web Bot Auth đã là một tiêu chuẩn hoàn chỉnh chưa?

Chưa. Tính đến tháng 11 năm 2026, tài liệu giao thức chính, draft-ietf-webbotauth-httpsig-protocol, vẫn là một Internet-Draft của nhóm làm việc ở bản sửa đổi 01. RFC 9421, định dạng chữ ký mà nó dựa trên, đã được công bố dưới dạng Proposed Standard.

Chữ ký Web Bot Auth hợp lệ có nghĩa là tác tử được phép hành động không?

Không. Nó chứng minh khóa nào đã ký yêu cầu và rằng các phần đã ký không bị sửa đổi. Việc tác tử đó có được đọc dữ liệu, gửi biểu mẫu hay hành động thay cho một người dùng cụ thể hay không vẫn là quyết định ủy quyền do ứng dụng của bạn đưa ra.

Các nhóm sản phẩm có cần tự triển khai Web Bot Auth không?

Trang web sẽ xác minh chữ ký; họ không cần tự ký gì cả, trừ khi họ cũng vận hành các máy khách tự động. Việc xác minh bao gồm lấy thư mục khóa, lưu đệm chúng một cách an toàn và kiểm tra chữ ký, và một công cụ như Proof of Actor có thể làm việc đó cho bạn.

Chúng ta nên làm gì với các tác tử không ký yêu cầu của họ?

Xử lý chúng theo bằng chứng hiện có: declared, inferred hoặc Unknown. Hãy kỳ vọng trong một thời gian sẽ có cả lưu lượng đã ký và chưa ký, và đặt phương án dự phòng cho từng route thay vì một quy tắc áp dụng cho toàn bộ site.

Proof of Actor dùng Web Bot Auth như thế nào?

Nó kiểm tra HTTP Message Signatures với khóa đã công bố và, khi kiểm tra đạt, sẽ báo cáo kết quả với cơ sở verified. Khi đó, chính sách của bạn có thể đối xử với tác tử verified khác với lưu lượng declared hoặc Unknown.

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