Quyền được ủy quyền có nghĩa là gì
Quyền được ủy quyền là sự cho phép mà một người (hoặc một tổ chức) trao cho tác nhân AI để hành động thay cho họ. Khi một trợ lý đặt lịch họp vào lịch của bạn, tạo ticket hỗ trợ dưới tên bạn hoặc truy xuất hóa đơn từ cổng của nhà cung cấp, nó đang thực thi quyền hạn có nguồn gốc từ bạn.
Việc ủy quyền tốt có ba đặc tính: nó có phạm vi (tác nhân chỉ có thể làm một số việc, không phải mọi việc), bị giới hạn theo thời gian (hết hạn hoặc có thể bị thu hồi) và có thể quy trách nhiệm (ứng dụng nhận biết được quyền hạn của ai đang được thực thi).
Vì sao điều này quan trọng với ứng dụng
Từ góc nhìn của một ứng dụng, một yêu cầu từ tác nhân đặt ra tối đa ba câu hỏi riêng biệt:
- Client nào đã gửi yêu cầu này? Đó là danh tính tác nhân, và các yêu cầu được ký có thể xác lập điều đó (xem HTTP Message Signatures).
- Nó đang hành động dưới quyền hạn của ai? Đó là ủy quyền.
- Quyền hạn đó có đủ cho hành động này không? Đó là authorization, do chính chính sách của ứng dụng quyết định.
Một yêu cầu được ký từ một nhà vận hành trợ lý đã biết có thể trả lời tốt câu hỏi thứ nhất. Nó không tự nói gì về câu hỏi thứ hai. Trợ lý có thể đang hành động cho một trong các người dùng của bạn, cho một người không phải là người dùng của bạn, hoặc hoàn toàn theo sáng kiến của chính nó. Xem những gì các yêu cầu tác nhân AI được ký chứng minh, và những gì chúng không chứng minh.
Cách ủy quyền thường được thể hiện
- Các cấp quyền kiểu OAuth. Người dùng đăng nhập vào ứng dụng của bạn và cấp cho một tác nhân một token với các scope giới hạn, như được định nghĩa trong OAuth 2.0 (RFC 6749). Khi đó ứng dụng của bạn biết chính xác token mang quyền của ai, và cấp quyền đó có thể bị thu hồi (RFC 7009).
- API key gắn với tài khoản do người dùng tạo cho một tích hợp cụ thể, lý tưởng là với quyền hạn hẹp.
- Xác nhận ngay trong ứng dụng cho các hành động có tác động lớn, khi người dùng phê duyệt một hành động cụ thể mà tác nhân đã chuẩn bị.
- Các tuyên bố ủy quyền ở cấp token. OAuth 2.0 Token Exchange (RFC 8693) định nghĩa một claim
act(actor) ghi nhận một bên hành động thay cho bên khác. Công việc mới hơn về biểu đạt ủy quyền tác nhân trong các yêu cầu vẫn đang phát triển, và ứng dụng nên đối chiếu mọi claim ủy quyền với hồ sơ riêng của mình thay vì chấp nhận nguyên trạng.
Những hiểu lầm phổ biến
- "Nếu tác nhân được xác minh thì người dùng đã phê duyệt." Việc xác minh chỉ nhận diện client. Việc phê duyệt phải đến từ người dùng, qua một kênh mà ứng dụng của bạn tin cậy.
- "Một tác nhân dùng session của người dùng tôi là ổn." Có thể là vậy, nhưng session đó được cấp cho việc sử dụng tương tác của con người. Nhiều ứng dụng ưu tiên một cấp quyền riêng, có phạm vi rõ ràng cho tự động hóa để các hành động có thể quy trách nhiệm và bị thu hồi.
- "Ủy quyền là hoặc toàn bộ hoặc không gì cả." Các quyền ủy quyền an toàn nhất là hẹp: quyền đọc rộng, quyền ghi chỉ cho các hành động cụ thể, và cần xác nhận cho bất kỳ điều gì không thể đảo ngược.
Proof of Actor liên quan thế nào
Proof of Actor giúp bạn thấy khi nào một tương tác do tác nhân điều khiển hoặc được AI hỗ trợ, và dựa trên cơ sở nào: Verified, Declared, Inferred hoặc Unknown. Bối cảnh đó cho bạn biết các câu hỏi về ủy quyền phát sinh ở đâu, ví dụ một autonomous agent đang hoạt động bên trong một phiên tài khoản của con người. Proof of Actor không cấp hoặc xác thực thông tin xác thực ủy quyền, và kết quả Agent không bao giờ ngụ ý rằng một người đã cho phép hành động đó. Các cấp quyền, phạm vi và xác nhận của chính ứng dụng bạn sẽ quyết định điều đó, và Route cho phép bạn áp dụng chính sách phù hợp cho từng route sau khi đã quan sát lưu lượng thực tế. Với các mẫu chính sách, xem thiết kế chính sách ở cấp ứng dụng cho con người và tác nhân AI.
Đọc điều mà bằng chứng có thể và không thể xác lập, hoặc đăng ký truy cập sớm.
Nguồn
- RFC 6749: The OAuth 2.0 Authorization Framework: các cấp quyền có phạm vi từ chủ sở hữu tài nguyên cho client
- RFC 7009: OAuth 2.0 Token Revocation: thu hồi một token được ủy quyền
- RFC 8693: OAuth 2.0 Token Exchange: claim
act(actor) cho ủy quyền