Cách các Trợ lý AI Phơi bày những Sai sót Cơ bản trong Kiến trúc Quản lý Danh tính Truy cập Truyền thống

Vấn đề cốt lõi: Con người không phải lúc nào cũng đứng sau bàn phím

Hệ thống Quản lý Danh tính và Truy cập truyền thống được xây dựng dựa trên một giả định duy nhất—rằng có ai đó thực sự ở đó để xác thực. Một con người ngồi trước màn hình đăng nhập, nhập mật khẩu, nhận thông báo MFA, và phê duyệt nó. Quy trình làm việc này đã định hình an ninh trong nhiều thập kỷ.

Nhưng các tác nhân AI hoàn toàn phá vỡ giả định này.

Khi một tác nhân tự động xử lý các yêu cầu API với tốc độ cao trong giờ nghỉ, nó không thể tạm dừng để trả lời các thử thách MFA. Khi một tác nhân ủy quyền xử lý các công việc lịch trình và email thay mặt người dùng, nó không bao giờ nên thừa hưởng toàn bộ quyền hạn của người đó. Hệ thống xác thực không thể yêu cầu sự tương tác của con người cho các quy trình chạy 24/7 mà không có sự giám sát của con người. Toàn bộ kiến trúc—màn hình đăng nhập, lời nhắc mật khẩu, xác thực đa yếu tố do con người xác nhận—trở thành khoản nợ kiến trúc ngay khi các tác nhân tiếp quản thực thi quy trình làm việc.

Vấn đề thực sự: hệ thống IAM truyền thống không thể phân biệt giữa một yêu cầu hợp lệ từ tác nhân và một yêu cầu bị xâm phạm hoạt động dưới danh tính hợp lệ. Khi một chủ thể không có quyền truy cập vào một hoạt động API qua các kênh ủy quyền bình thường, hệ thống sẽ phát hiện ra. Nhưng khi thông tin đăng nhập của chủ thể đó bị chiếm đoạt hoặc khi ý định của tác nhân trở nên độc hại thông qua việc nhiễu loạn ngữ cảnh, các hệ thống truyền thống không có các biện pháp phòng vệ. Khoảng cách giữa xác thực danh tính kỹ thuật và độ tin cậy thực sự này định nghĩa thách thức cốt lõi của xác thực dựa trên tác nhân.

Hai mô hình tác nhân hoàn toàn khác nhau, hai yêu cầu danh tính khác nhau

Tác nhân ủy quyền bởi con người: Vấn đề phạm vi và quyền tối thiểu

Một tác nhân do con người ủy quyền hoạt động dựa trên quyền hạn được ủy quyền—bạn cho phép trợ lý AI quản lý lịch trình của mình. Nhưng phần nguy hiểm là: hầu hết các hệ thống hiện tại hoặc cấp toàn bộ quyền hạn của bạn cho tác nhân, hoặc yêu cầu bạn tự định nghĩa các hạn chế. Cả hai cách đều không phù hợp.

Tác nhân không cần thừa hưởng toàn bộ danh tính của bạn. Nó cần các quyền hạn được giới hạn chính xác. Bạn hiểu rõ rằng dịch vụ thanh toán hóa đơn không nên chuyển tiền đến các tài khoản tùy ý. Bạn tự nhiên ngăn chặn lệnh tài chính bị hiểu nhầm. Các hệ thống AI thiếu khả năng suy luận ngữ cảnh này, đó là lý do tại sao quyền tối thiểu không phải là tùy chọn—nó là bắt buộc.

Cách hoạt động kỹ thuật của điều này:

Hệ thống thực hiện xác thực danh tính kép. Tác nhân hoạt động dưới hai danh tính cùng lúc:

• Danh tính của bạn (người dùng ủy quyền) với toàn bộ quyền hạn
• Danh tính hạn chế của tác nhân với các giới hạn phạm vi rõ ràng

Khi bạn ủy quyền, một quá trình trao đổi token diễn ra. Thay vì tác nhân nhận thông tin đăng nhập của bạn, nó nhận một token hạn chế chứa đựng:

• agent_id: Định danh duy nhất cho phiên tác nhân cụ thể này
• delegated_by: ID người dùng của bạn
• scope: Các giới hạn quyền hạn (ví dụ, “ngân hàng: thanh toán hóa đơn” nhưng rõ ràng KHÔNG phải “ngân hàng: chuyển khoản”)
• constraints: Các hạn chế chính sách như danh sách người nhận được phê duyệt, giới hạn số tiền giao dịch, và thời hạn hết hạn

Đây là cách luồng hoạt động diễn ra: