Bỏ qua nội dung chính
TỰ ĐỘNG HÓA ĐÃ XÁC MINH

Nhận diện các yêu cầu tự động đã xác minh

Khi một client tự động ký các yêu cầu của mình, ứng dụng của bạn có thể kiểm tra chữ ký đó và xử lý bên gọi cho phù hợp. Proof of Actor biến bước kiểm tra đó thành một kết quả rõ ràng, có thể định tuyến.

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

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

Không phải mọi lưu lượng tự động đều giống nhau

Các client tự động đến ứng dụng của bạn mỗi phút: trình thu thập dữ liệu tìm kiếm, công cụ giám sát, tích hợp đối tác, trợ lý AI lấy trang cho người dùng, và các agent tự trị hoàn thành tác vụ. Trong nhiều năm, cách duy nhất mà hầu hết ứng dụng có thể phân biệt chúng là header user-agent, một chuỗi mà bất kỳ client nào cũng có thể đặt thành bất cứ giá trị nào.

Điều đó đặt các nhóm ứng dụng vào thế khó. Xem tất cả tự động hóa với sự nghi ngờ thì trải nghiệm của những agent hợp lệ mà khách hàng của bạn phụ thuộc vào sẽ bị suy giảm. Tin vào header thì bạn đang mời bất kỳ ai tự nhận là một trình thu thập dữ liệu nổi tiếng.

Các yêu cầu tự động đã xác minh thay đổi bài toán. Khi một client tự động ký các yêu cầu của mình bằng một khóa mà nó đã công bố, ứng dụng của bạn có thể kiểm tra chữ ký và biết, theo cách mật mã, client nào đã ký yêu cầu đó. Proof of Actor đưa bước kiểm tra đó thành một kết quả actor nhất quán duy nhất mà code của bạn có thể định tuyến dựa trên. Để hiểu kỹ hơn điều gì mà bước kiểm tra đó xác lập và không xác lập, hãy đọc chữ ký của yêu cầu agent AI đã ký chứng minh điều gì.

Cách hoạt động của việc ký yêu cầu

Cách tiếp cận đang nổi lên cho lưu lượng tự động sử dụng HTTP message signatures, được chuẩn hóa trong RFC 9421, quy định cách tạo, mã hóa và xác minh chữ ký trên các thành phần của một HTTP message. Client ký các phần được chọn của mỗi yêu cầu bằng một khóa riêng và đưa chữ ký cùng các tham số của nó vào các header. Nó công bố khóa công khai tương ứng tại một vị trí gắn với một định danh mà nó kiểm soát, thường là domain của nó.

Khi yêu cầu đến, bên nhận sẽ lấy hoặc tra cứu khóa đã công bố, tái tạo nội dung đã được ký, và kiểm tra chữ ký. Nếu chữ ký hợp lệ, yêu cầu đó đã được ký bởi bên nắm giữ khóa ấy. Công việc về ký lưu lượng tự động vẫn đang tiếp tục trong nhóm làm việc Web Bot Auth working group của IETF, với điều khoản hoạt động bao phủ việc xác thực bằng mật mã các client tự động như crawler và agent AI hoạt động cho người dùng cuối; mục từ điển Web Bot Auth tóm tắt nội dung này. Bài viết blog về chữ ký của yêu cầu agent AI đã ký chứng minh điều gì đi qua một yêu cầu đã xác minh từ đầu đến cuối, và use case cho APIs cho thấy nơi việc xác minh mang lại lợi ích trước tiên.

Hướng dẫn về xác minh các yêu cầu agent đã ký trình bày chi tiết cơ chế, bao gồm timestamp, replay window và cache khóa.

Chữ ký đã xác minh chứng minh điều gì, và điều gì không

Đây là phần quan trọng nhất khi xử lý tốt các yêu cầu tự động đã xác minh.

Một chữ ký hợp lệ chứng minh rằng yêu cầu đã được ký bằng một khóa gắn với định danh đã công bố. Nếu khóa đó thuộc về domain của một nhà vận hành, thì yêu cầu đến từ một client đang giữ khóa của nhà vận hành đó.

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

  • ai đã chỉ dẫn agent, hoặc có phải một người đã yêu cầu hành động này hay không;
  • rằng một người đã ủy quyền cho agent;
  • danh tính pháp lý trong thế giới thực đứng sau nhà vận hành;
  • rằng hành động được yêu cầu là an toàn hoặc được phép trong ứng dụng của bạn.

Đó là các câu hỏi riêng biệt. Ứng dụng của bạn trả lời chúng bằng thông tin xác thực, mô hình cấp quyền và chính sách của riêng mình. Proof of Actor chủ ý giữ chúng tách biệt, và trang về Detection & Limitations nêu rõ chính xác từng loại bằng chứng có thể xác lập điều gì.

Proof of Actor xử lý các yêu cầu tự động đã xác minh như thế nào

Detect

Tích hợp của bạn chuyển ngữ cảnh yêu cầu, bao gồm bất kỳ header chữ ký nào, cho Proof of Actor. Các chữ ký được kiểm tra với các khóa đã công bố. Các yêu cầu xác thực hợp lệ được ghi lại với cơ sở Verified. Các client chỉ tự xưng danh được ghi là Declared. Các mẫu hành vi được ghi là Inferred. Khi chưa đủ cơ sở để kết luận, kết quả là Unknown. Không có gì được nâng lên thành verified nếu chưa qua kiểm tra mật mã thành công.

Understand

Xem những nhà vận hành đã xác minh nào gọi ứng dụng của bạn, họ dùng những route nào, tần suất ra sao, và điều đó so sánh thế nào với tự động hóa declared và unknown. Bản tóm tắt bằng chứng trên mỗi kết quả cho bạn biết khóa và định danh nào đã liên quan, để nhóm của bạn có thể điều tra nhanh bất kỳ yêu cầu nào.

Route

Dùng cơ sở đó trong chính sách của bạn. Các mẫu phổ biến gồm:

  • Trả về phản hồi có cấu trúc cho verified agent trên các route chỉ đọc, chẳng hạn một API hoặc một phiên bản Markdown của một trang.
  • Tăng rate limit cho các nhà vận hành đã xác minh mà bạn nhận ra trong khi giữ giới hạn tiêu chuẩn cho client declared.
  • Giữ nguyên cơ chế cấp quyền hiện có trên mọi route ghi, bất kể chữ ký nói gì.
  • Xác định một phương án dự phòng rõ ràng cho các caller không có chữ ký và Unknown trên từng route.

Chính sách do bạn quyết định; Proof of Actor cung cấp bằng chứng.

Vì sao header user-agent là chưa đủ

Chuỗi user-agent là lời khai báo. Bất kỳ client nào cũng có thể gửi bất kỳ giá trị nào, và giả mạo user-agent thì không cần kỹ năng gì. Đó là lý do các nhà vận hành crawler công bố các kiểm tra của riêng họ: Google tài liệu hóa tra cứu DNS ngược và xuôi cùng các dải IP đã công bố để xác minh Googlebot, Bing tài liệu hóa một kiểm tra DNS để xác minh Bingbot, và OpenAI công bố các tệp dải IP cho từng crawler và user agent của mình. Proof of Actor xem một tuyên bố user-agent là bằng chứng declared, không bao giờ là xác minh. Điều đó có nghĩa là một client tự nhận là một crawler nổi tiếng nhưng không có chữ ký hợp lệ sẽ được báo cáo với cơ sở declared hoặc inferred, và chính sách của bạn có thể xử lý nó khác với một client đã chứng minh danh tính của mình.

Đây là điều làm cho các yêu cầu tự động đã xác minh có giá trị: chúng cho bạn một cách đáng tin cậy để mở rộng niềm tin tới những client xứng đáng có được nó, mà không mở rộng nó cho tất cả những ai sao chép header của họ.

Bằng chứng danh tính, thông tin xác thực và cấp quyền

Ba lớp phối hợp với nhau trong bất kỳ ứng dụng nào phục vụ client tự động:

  1. Bằng chứng danh tính: client nào đã ký yêu cầu này? Chữ ký đã xác minh trả lời điều đó.
  2. Thông tin xác thực: tài khoản nào chịu trách nhiệm? API key, token hoặc session của bạn trả lời điều đó.
  3. Cấp quyền: caller này có được phép làm việc này không? Mô hình quyền của bạn trả lời điều đó.

Proof of Actor tăng cường lớp đầu tiên và làm cho nó hiển thị được. Nó không cấp thông tin xác thực danh tính hay ủy quyền, và cũng không thay thế cơ chế cấp quyền của bạn. Giữ các lớp tách biệt chính là điều cho phép bạn rộng rãi với verified agent trên các route ít rủi ro và thận trọng trên những route có tác động lớn.

Nó phù hợp ở đâu

Proof of Actor đứng bên cạnh gateway, xác thực và rate limiting của bạn. Các tích hợp chạy như middleware phía server, ở edge, trong MCP server của bạn hoặc thông qua một tích hợp HTTP tổng quát, được triển khai trực tiếp cùng từng nhóm sáng lập. Nếu lưu lượng của bạn chủ yếu là APIs và công cụ, các use case APIs và MCP Servers cho thấy những mẫu quan trọng nhất.

Bắt đầu ở chế độ quan sát

Mỗi tích hợp đều bắt đầu ở chế độ quan sát. Kết quả được ghi lại mà không thay đổi cách ứng dụng của bạn phản hồi, để bạn có thể thấy bao nhiêu phần trăm lưu lượng tự động của bạn đã được xác minh, những nhà vận hành nào đang ký, và tỷ lệ unknown cao nhất ở đâu. Chính sách sẽ đến sau, theo từng route, khi bằng chứng hỗ trợ chúng. How It Works đi qua toàn bộ luồng.

Các chi tiết thực tế giúp việc xác minh đáng tin cậy

Việc kiểm tra chữ ký chỉ tốt bằng các chi tiết xung quanh nó. Một vài thực hành giúp các yêu cầu tự động đã xác minh trở nên đáng tin cậy trong production.

Kiểm tra độ mới

RFC 9421 định nghĩa các tham số chữ ký created và expires, và các yêu cầu đã ký thường mang chúng. Hãy từ chối các chữ ký nằm ngoài một khoảng cửa sổ ngắn, để một yêu cầu đã bị chụp lại không thể bị phát lại sau này.

Cache khóa một cách hợp lý

Việc lấy các khóa đã công bố của nhà vận hành cho mọi yêu cầu sẽ làm tăng độ trễ. Hãy cache chúng trong một khoảng thời gian hợp lý và làm mới khi chữ ký thất bại vì không có key identifier, để việc luân chuyển khóa không gây ra lỗi giả.

Ký đúng các phần của yêu cầu

Một chữ ký chỉ bao phủ timestamp thì chứng minh rất ít. Hãy kiểm tra rằng các thành phần đã ký bao gồm method, path và host, để chữ ký gắn với chính yêu cầu mà ứng dụng của bạn thực sự nhận được.

Ghi lại bằng chứng

Giữ key identifier, định danh đã công bố và kết quả cùng với mỗi yêu cầu đã xác minh. Khi có điều bất thường xảy ra, nhóm của bạn có thể thấy chính xác client nào đã ký gì và khi nào.

Proof of Actor xử lý các kiểm tra này như một phần của bước Detect và báo cáo kết quả dưới dạng một cơ sở mà chính sách của bạn có thể đọc, để code ứng dụng của bạn vẫn đơn giản.

Tham gia chương trình nhà phát triển sáng lập

Proof of Actor đang ở private beta. Các nhóm phát triển sáng lập được chọn có thể nhận tối đa 12 tháng truy cập miễn phí, trong các giới hạn sử dụng đã thỏa thuận, kèm hỗ trợ tích hợp trực tiếp từ kỹ sư của chúng tôi.

Nếu client tự động đến ứng dụng của bạn và bạn muốn xử lý những client đã xác minh theo cách khác, hãy đăng ký quyền truy cập sớm. Hãy cho chúng tôi biết về ứng dụng của bạn và những caller tự động mà bạn thấy, chúng tôi sẽ chỉ cho bạn Proof of Actor phù hợp như thế nào.

Nguồ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

Yêu cầu tự động đã xác minh là gì?

Đó là một yêu cầu từ một client tự động có chữ ký mật mã hợp lệ đối với một khóa được công bố cho một định danh đã biết, chẳng hạn tên miền của nhà vận hành. Nó cho biết client nào đã ký yêu cầu.

Chữ ký đã xác minh có nghĩa là agent đã được cấp quyền không?

Không. Chữ ký liên kết một yêu cầu với một khóa và định danh đã công bố của nó. Việc client đó có được phép thực hiện một hành động hay không là một quyết định cấp quyền riêng do ứng dụng của bạn đưa ra.

Còn các client tự động không ký yêu cầu của họ thì sao?

Proof of Actor vẫn phân loại chúng, dùng bằng chứng declared và inferred khi có thể, và báo cáo Unknown khi bằng chứng chưa đủ mạnh. Mỗi kết quả đều nêu rõ cơ sở của nó.

Một chuỗi user-agent có thể xác minh một client không?

Không. Chuỗi user-agent rất dễ bị giả mạo, nên chúng được tính là khai báo, không phải xác minh. Chữ ký mật mã mới là thứ làm cho một yêu cầu có thể được xác minh.

Tôi bắt đầu như thế nào?

Hãy đăng ký quyền truy cập sớm. Các nhóm sáng lập sẽ bắt đầu ở chế độ quan sát và các nhóm được chọn có thể nhận tối đa 12 tháng miễn phí trong các giới hạn sử dụng đã thỏa thuận.

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ớmXem giá

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