AI agent authorization trả lời một câu hỏi cụ thể: agent có được phép thực hiện hành động này, với công cụ này, trên tài nguyên này, ngay tại thời điểm này hay không? Authentication chỉ xác nhận danh tính. Authorization phải đánh giá cả mục tiêu, phạm vi, dữ liệu, trạng thái phiên và mức rủi ro của từng tool call.

Vì sao mô hình quyền ứng dụng truyền thống chưa đủ?

Ứng dụng thông thường thường có luồng thao tác được lập trình trước. Agent có thể tự chọn công cụ, tạo chuỗi hành động và điều chỉnh kế hoạch từ kết quả trung gian. Một quyền rộng như “được dùng email” hoặc “được truy cập database” không thể hiện agent được đọc hộp thư nào, gửi cho ai, truy vấn bảng nào hay thay đổi bao nhiêu bản ghi.

Ranh giới authorization cần nằm ngay trước khi tool được thực thi. Agent có thể đề xuất hành động, nhưng policy enforcement point phải quyết định cho phép, từ chối, thu hẹp tham số hoặc yêu cầu phê duyệt.

Bốn lớp ngữ cảnh cho quyết định policy

• Principal: người dùng, service account hoặc workload đang ủy quyền cho agent.
• Action: thao tác cụ thể như đọc, tạo, gửi, cập nhật, xóa hoặc thực thi.
• Resource: tài nguyên đích, tenant, project, repository, bảng dữ liệu hoặc nhóm người nhận.
• Context: mục đích phiên, nguồn yêu cầu, mức nhạy cảm, thời gian, môi trường và kết quả của các bước trước.

Kiến trúc authorization cho AI agent

Mỗi tool nên công bố schema đầu vào, hành động có thể gây thay đổi và phạm vi tài nguyên. Trước khi gọi tool, agent gửi một authorization request chuẩn hóa tới policy decision point. Quyết định trả về không chỉ là allow hoặc deny; hệ thống có thể giới hạn số bản ghi, loại bỏ trường nhạy cảm, chuyển sang chế độ chỉ đọc hoặc yêu cầu con người xác nhận.

Credential không nên được đưa trực tiếp vào context của model. Một broker giữ credential và chỉ cấp token ngắn hạn, giới hạn scope sau khi policy được chấp thuận. Cách này giảm khả năng secret xuất hiện trong prompt, log hoặc output.

Phê duyệt theo mức rủi ro

Không phải tool call nào cũng cần con người. Đọc tài liệu công khai có thể tự động; truy cập dữ liệu nội bộ cần kiểm tra scope; gửi thông báo hàng loạt, thay đổi production hoặc chuyển tiền cần step-up authentication và phê duyệt rõ ràng. Policy nên dựa trên tác động có thể xảy ra, khả năng hoàn tác và độ tin cậy của ngữ cảnh.

Audit và khả năng giải thích

Mỗi quyết định cần ghi principal, policy version, tool, tham số đã làm sạch, tài nguyên đích, kết quả, người phê duyệt và correlation ID. Không ghi secret hoặc dữ liệu nhạy cảm nguyên bản. Log phải cho phép tái dựng chuỗi hành động mà không trở thành nguồn rò rỉ mới.

Checklist triển khai

1. Lập danh mục tool và đánh dấu thao tác read/write/destructive.
2. Ánh xạ quyền của agent về quyền hiện có của người dùng, không tạo quyền ngầm định mới.
3. Đặt policy enforcement point ngoài model và ngoài phần prompt có thể bị thao túng.
4. Dùng credential ngắn hạn, ràng buộc audience, scope và thời gian.
5. Yêu cầu phê duyệt cho hành động tác động cao và hiển thị chính xác agent sắp làm gì.
6. Kiểm thử prompt injection, confused deputy, replay và chuỗi tool call vượt phạm vi.

Một thiết kế tốt không cố đoán agent có “ý định tốt” hay không. Nó giả định mọi đề xuất hành động đều cần được kiểm tra bằng policy có thể kiểm toán trước khi chạm tới hệ thống thật.