Một chính sách cho mọi người nữa là chưa đủ
Phần lớn ứng dụng được thiết kế quanh một kiểu người dùng duy nhất: một người nhấp qua giao diện, đã đăng nhập vào tài khoản. Kiểm soát truy cập dựa trên giả định đó. Nếu session hợp lệ, request được đi qua. Nếu có vẻ tự động, CAPTCHA hoặc một khối chặn sẽ xuất hiện.
Mô hình đó đang vỡ ra. Ngày nay cùng một ứng dụng phục vụ con người, con người làm việc với trợ lý AI, và tác nhân tự động hành động thay mặt ai đó. Một số tác nhân là tích hợp của chính khách hàng. Một số là trợ lý AI đang lấy tài liệu. Một số là crawler. Một vài đang cố lạm dụng sản phẩm của bạn. Một quy tắc có hoặc không đơn giản không thể phục vụ tốt cho tất cả họ.
Định tuyến tác nhân AI và chính sách truy cập thay thế quy tắc đơn lẻ đó bằng một tập quyết định có chủ đích: tác nhân nào nhận trải nghiệm nào, trên route nào, dưới điều kiện nào. Proof of Actor cung cấp cho ứng dụng của bạn bằng chứng để ra các quyết định đó, và để chính các quyết định nằm trong tay bạn. Với các nguyên tắc thiết kế đằng sau cách tiếp cận này, hãy đọc thiết kế chính sách ứng dụng cho con người và tác nhân AI, và xem trường hợp sử dụng cho ứng dụng SaaS để biết cách chính sách gắn với workflow sản phẩm thực tế.
Một chính sách tác nhân tốt trông như thế nào
Một chính sách hữu ích phải cụ thể. Nó nêu tên một route hoặc một workflow, một lớp tác nhân, mức độ bằng chứng cần có, và phản hồi. Ví dụ:
- Các route danh mục chỉ đọc: cho phép tác nhân đã xác minh và trả về phản hồi có cấu trúc; cho phép tác nhân đã khai báo với giới hạn tốc độ tiêu chuẩn.
- Các hành động thay đổi tài khoản: giữ nguyên bước xác thực lại hiện có cho mọi người; thêm bước xem xét khi tác nhân là Unknown và hành động có tác động lớn.
- Gửi yêu cầu hỗ trợ: chấp nhận nội dung có AI hỗ trợ được công bố và gắn nhãn để định tuyến.
- Đăng ký: giữ nguyên các kiểm tra hiện có; không bao giờ quyết định chỉ từ kết quả tác nhân suy luận.
Mỗi chính sách này phản hồi theo tác nhân mà không xem mọi tác nhân là lạm dụng và cũng không tin mù quáng vào mọi tác nhân. Sự cân bằng đó là toàn bộ mục đích của truy cập hiểu tác nhân, và bài viết trên thiết kế chính sách ứng dụng cho con người và tác nhân AI triển khai thêm các ví dụ theo từng route.
Năm phản hồi
Khả năng Route của Proof of Actor được xây dựng quanh năm phản hồi mà chính sách của bạn có thể chọn.
Cho phép
Cho request đi tiếp như bình thường. Phần lớn lưu lượng, bao gồm phần lớn lưu lượng tác nhân trên các route công khai hoặc rủi ro thấp, chỉ nên được cho phép.
Điều chỉnh
Thay đổi trải nghiệm để phù hợp với tác nhân. Phục vụ phản hồi API có cấu trúc hoặc phiên bản Markdown của một trang cho tác nhân đã xác minh thay vì giao diện dành cho con người. Hướng dẫn về phục vụ nội dung có cấu trúc cho tác nhân AI trình bày mẫu này.
Thử thách
Yêu cầu một thứ mạnh hơn: đăng nhập mới, credential bổ sung, xác nhận từ chủ tài khoản. Dùng thử thách trên những route mà chi phí của quyết định sai là cao.
Xem xét
Đưa action vào hàng đợi thay vì hoàn tất ngay, hoặc gắn cờ để một người kiểm tra. Xem xét hữu ích khi chặn sẽ gây hại cho người dùng hợp lệ nhưng hoàn tất mà không giám sát lại quá rủi ro.
Giới hạn
Áp dụng giới hạn tốc độ hoặc khối lượng được tinh chỉnh theo tác nhân và route, để các caller tự động không thể làm quá tải một workflow được thiết kế cho con người.
Vì sao robots.txt không phải là chính sách truy cập
Nhiều đội bắt đầu với robots.txt, và đó là tín hiệu ban đầu hợp lý cho crawler. Nhưng nó không phải là chính sách truy cập cho tác nhân. Nhà vận hành crawler ghi nhận hành vi khác nhau cho các user agent khác nhau: Anthropic nói rằng bot của họ tuân thủ chỉ thị robots.txt (tài liệu crawler của Anthropic), trong khi OpenAI lưu ý rằng với ChatGPT-User, vốn hành động khi người dùng hỏi ChatGPT một câu hỏi, các quy tắc robots.txt có thể không áp dụng vì hành động được khởi tạo bởi người dùng (tài liệu crawler của OpenAI). robots.txt cũng không nói gì về API, công cụ MCP hay workflow đã đăng nhập.
Một chính sách truy cập phải chạy ở nơi request được xử lý, đọc bằng chứng như một chữ ký được kiểm tra theo RFC 9421, và chọn phản hồi theo từng route. Với MCP server, đặc tả ủy quyền MCP xác định cách client nhận access token qua HTTP; các chính sách tác nhân bổ sung ngữ cảnh lên trên điều đó, chứ không thay thế nó.
Proof of Actor cung cấp dữ liệu cho chính sách của bạn như thế nào
Mỗi request mà tích hợp của bạn đánh giá đều tạo ra một kết quả tác nhân với bốn phần mà chính sách của bạn có thể đọc:
- Lớp: Human, Human + AI, Agent hoặc Unknown.
- Cơ sở: verified, declared, inferred hoặc unknown, để chính sách của bạn có thể xử lý một chữ ký đã xác thực khác với tên client tự khai báo.
- Tóm tắt bằng chứng: mô tả dễ đọc về cơ sở của kết quả, hữu ích cho logging và xem xét.
- Ngữ cảnh: tích hợp nào và route nào đã tạo ra nó.
Vì cơ sở được nêu rõ, chính sách của bạn có thể chính xác. "Cho phép tác nhân" trở thành "cho phép tác nhân đã xác minh trên các route đọc, giới hạn tốc độ tác nhân đã khai báo, áp dụng phương án dự phòng Unknown cho mọi thứ còn lại." Toàn bộ luồng từ request đến quyết định được mô tả trên Cách hoạt động.
Phương án dự phòng là một phần của chính sách
Một chính sách chỉ tốt khi hành vi của nó trong trường hợp thiếu bằng chứng cũng tốt. Proof of Actor làm cho các trường hợp đó trở nên rõ ràng thay vì che giấu chúng.
- Unknown: bằng chứng không đủ để đưa ra kết luận. Chính sách của bạn sẽ nêu Unknown có nghĩa là gì trên từng route. Nó không bao giờ bị chuyển thành Human và mặc định cũng không bị coi là có hại.
- Timeout: kết quả không đến kịp thời. Tích hợp của bạn áp dụng phương án dự phòng mà bạn đã chọn cho route đó.
- Thiếu tín hiệu: một collector không chạy hoặc một header bị thiếu. Kết quả phản ánh điều đó, và chính sách của bạn xử lý tương ứng.
Với mỗi route, bạn quyết định fail open hay fail closed. Fail open nghĩa là request tiếp tục như khi không có Proof of Actor; fail closed nghĩa là kiểm tra mạnh hiện có của bạn được áp dụng. Các route rủi ro thấp thường fail open. Các hành động nhạy cảm thường fail closed. Bạn thiết lập điều này theo từng mức rủi ro, không phải trên toàn hệ thống.
Giữ riêng danh tính, credential và ủy quyền
Chính sách truy cập tác nhân nằm trên ba lớp riêng biệt, và việc giữ chúng tách nhau sẽ ngăn được những sai lầm nghiêm trọng nhất.
- Bằng chứng danh tính trả lời tác nhân nào đang gọi và điều gì chứng minh điều đó. Proof of Actor cung cấp phần này.
- Credential trả lời tài khoản nào chịu trách nhiệm. Session, token hoặc API key của bạn cung cấp phần này.
- Ủy quyền trả lời caller này có được phép thực hiện action này hay không. Mô hình quyền của bạn cung cấp phần này.
Một danh tính tác nhân đã xác minh không có nghĩa là tác nhân đó đã được ủy quyền, rằng một người đã giao quyền cho nó, hoặc rằng action của nó an toàn. Hãy dùng kết quả tác nhân để định tuyến và bổ sung ngữ cảnh. Hãy dùng mô hình ủy quyền của bạn để cấp quyền. Trang Detection & Limitations giải thích chính xác từng loại bằng chứng có thể xác lập điều gì.
Triển khai mà không làm hỏng bất cứ thứ gì
Cách an toàn nhất để giới thiệu chính sách truy cập tác nhân là theo từng giai đoạn.
- Quan sát. Cài đặt Proof of Actor ở chế độ quan sát. Không có gì thay đổi đối với người dùng của bạn; kết quả được ghi lại.
- Hiểu. Xem xét tác nhân nào dùng route nào, tỷ lệ Unknown trên từng route, và bất kỳ kết quả nào không khớp với những gì bạn đã biết.
- Xem trước. Chạy một chính sách ở chế độ xem trước, ghi lại điều nó sẽ làm mà không thực thi.
- Thực thi có phạm vi hẹp. Bật chính sách trên một route nơi bằng chứng hỗ trợ rõ ràng. Theo dõi kết quả.
- Mở rộng. Mở rộng sang nhiều route hơn khi mức độ tin cậy tăng lên.
Hướng dẫn về triển khai chính sách hiểu tác nhân một cách an toàn đi qua từng giai đoạn, và bảo vệ các hành động nhạy cảm mà không chặn tác nhân bao quát các route có rủi ro cao.
Đội ngũ của bạn nhận được gì
Với Proof of Actor, đội ngũ của bạn nhận một tích hợp với ba năng lực. Detect thu thập tín hiệu tác nhân và tách các khẳng định đã xác minh khỏi suy luận. Understand hiển thị phân tích tác nhân, xu hướng và bằng chứng phía sau từng kết quả, đồng thời giữ Unknown luôn hiển thị. Route cho phép bạn viết các chính sách được mô tả trên trang này và áp dụng chúng ở nơi bạn chọn. Trong giai đoạn private beta, các chính sách định tuyến được thiết kế cùng từng đội ngũ sáng lập và chạy trong code ứng dụng của chính bạn, nên bạn giữ toàn quyền kiểm soát.
Những lỗi chính sách phổ biến cần tránh
Các đội lần đầu thiết kế truy cập cho tác nhân thường lặp lại một số lỗi. Tránh chúng sẽ tiết kiệm được nhiều tuần làm lại.
- Chặn mặc định mọi tác nhân. Khi đó các tác nhân hợp lệ sẽ tìm đường vòng qua bạn, thường bằng cách quét giao diện bạn xây cho con người, vốn khó bảo vệ hơn một đường đi có cấu trúc.
- Tin vào tên tự khai báo. Một client chỉ tự đặt tên mình mới đưa ra một lời khẳng định, chứ chưa cung cấp bằng chứng. Hãy xử lý nó như một caller chưa được xác minh.
- Dùng một phương án dự phòng cho mọi nơi. Unknown trên trang giá công khai và Unknown khi đổi mật khẩu là hai tình huống khác nhau. Mỗi route cần câu trả lời riêng.
- Đưa ra quyết định về con người từ một suy luận. Kết quả tác nhân là ngữ cảnh để định tuyến, không phải phán quyết về một cá nhân. Hãy giữ các quyết định có hậu quả trong các biện pháp kiểm soát và quy trình xem xét của riêng bạn.
- Bỏ qua giai đoạn quan sát. Thực thi ngay từ ngày đầu nghĩa là bạn sẽ phát hiện false positive qua phàn nàn của khách hàng. Hãy quan sát trước, rồi mới thực thi ở nơi bằng chứng rõ ràng.
Một buổi rà soát chính sách ngắn với các đầu mối an ninh, sản phẩm và hỗ trợ trước mỗi bước thực thi sẽ phát hiện sớm phần lớn các vấn đề này.
Bắt đầu với chương trình nhà phát triển sáng lập
Proof of Actor đang ở private beta. Các đội ngũ phát triển sáng lập được chọn có thể nhận tối đa 12 tháng sử dụng miễn phí, trong giới hạn sử dụng đã thỏa thuận, cùng hỗ trợ trực tiếp từ kỹ sư của chúng tôi khi bạn thiết kế các chính sách đầu tiên.
Nếu bạn đang quyết định cách ứng dụng của mình nên xử lý tác nhân AI, hãy đăng ký quyền truy cập sớm. Hãy cho chúng tôi biết route nào quan trọng nhất và những quyết định bạn muốn đưa ra, chúng tôi sẽ giúp bạn xây dựng các chính sách phù hợp. Bạn cũng có thể xem cách điều này áp dụng cho APIs và MCP servers.
Nguồn
- Anthropic có thu thập dữ liệu từ web không, và chủ trang có thể chặn crawler như thế nào?, Anthropic.
- Tổng quan về crawler của OpenAI, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, tháng 2 năm 2024.
- MCP authorization, modelcontextprotocol.io.