Chúng ta đang chứng kiến sự không phù hợp cơ bản giữa cách các hệ thống danh tính được thiết kế và cách các tác nhân AI thực sự hoạt động. Quản lý Danh tính và Truy cập truyền thống (IAM) giả định một chân lý cốt lõi: con người luôn tham gia. Một người dùng đăng nhập, bị thách thức bằng MFA, suy nghĩ về những gì họ đang làm, rồi hành động.
Các tác nhân AI đã phá bỏ giả định đó trong tích tắc.
Khi một bot dịch vụ khách hàng xử lý 10.000 yêu cầu mỗi phút vào lúc 3 giờ sáng, nó không thể tạm dừng để chờ con người phê duyệt thông báo đẩy MFA. Khi một quy trình tự động chạy các nhiệm vụ ủy quyền qua API, nó cần quản lý chứng thực mà không ai phải nhấp gì cả. Cơ sở hạ tầng hiện tại—nhắc nhở mật khẩu, thách thức MFA, quy trình xác minh con người—trở thành nút thắt cổ chai khiến mọi thứ bị đình trệ.
Điều này không phải là một vấn đề UX nhỏ. Đó là một khủng hoảng kiến trúc.
Nơi Các Hệ Thống Truyền Thống Gặp Sự Cổ Chết
Các giải pháp xác thực máy-máy hiện có cũng không giải quyết được vấn đề này. Chúng được xây dựng cho giao tiếp đơn giản giữa dịch vụ với dịch vụ, không phải cho vòng đời phức tạp của tác nhân với yêu cầu quyền linh hoạt và chuỗi ủy quyền tinh vi.
Vấn đề cốt lõi: IAM truyền thống cấp quyền ở cấp độ người dùng. Khi bạn ủy quyền một trợ lý AI quản lý email của bạn, các hệ thống hiện tại hoặc là cấp quyền truy cập đầy đủ vào mọi thứ bạn có thể làm—hoặc là hoàn toàn thất bại vì chúng không hỗ trợ giới hạn phạm vi chi tiết.
Hãy xem ví dụ ngân hàng: Một con người có thể suy nghĩ về các hướng dẫn. Họ tự nhiên biết rằng một yêu cầu “chuyển $100,000 đến một tài khoản không rõ” có thể đáng ngờ, ngay cả khi về mặt kỹ thuật là cho phép. Một hệ thống AI thiếu khả năng phán đoán này. Nó cần các giới hạn rõ ràng: tác nhân này chỉ có thể thanh toán cho các nhà cung cấp được phê duyệt, tối đa $5,000 mỗi giao dịch, ngày hết hạn là 31 tháng 12 năm 2025.
Đây là lý do tại sao chúng ta cần quyền tối thiểu theo mặc định cho các tác nhân được ủy quyền—một khái niệm mà IAM truyền thống chưa từng phải thực hiện vì con người đã cung cấp lớp lý luận đó.
Hai Mô Hình Tác Nhân Cơ Bản Khác Nhau Đòi Hỏi Các Phương Pháp Danh Tính Khác Nhau
Tác Nhân Bán Tự Động: Vấn Đề Ủy Quyền
Khi một con người ủy quyền nhiệm vụ cho một tác nhân AI (nghĩ: trợ lý điều hành xử lý lịch trình và báo cáo chi phí), hệ thống cần thực hiện xác thực danh tính kép:
Danh tính chính: Người đã ủy quyền tác nhân
Danh tính phụ: Phiên bản tác nhân có phạm vi hạn chế rõ ràng
Trong thuật ngữ OAuth 2.1/OIDC, điều này có nghĩa là một trao đổi token tạo ra các token truy cập hạn chế:
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Cách Các Đại Lý AI Phá Vỡ Các Hệ Thống Kiểm Soát Truy Cập Truyền Thống
Khủng Hoảng IAM Không Ai Ngờ Đến
Chúng ta đang chứng kiến sự không phù hợp cơ bản giữa cách các hệ thống danh tính được thiết kế và cách các tác nhân AI thực sự hoạt động. Quản lý Danh tính và Truy cập truyền thống (IAM) giả định một chân lý cốt lõi: con người luôn tham gia. Một người dùng đăng nhập, bị thách thức bằng MFA, suy nghĩ về những gì họ đang làm, rồi hành động.
Các tác nhân AI đã phá bỏ giả định đó trong tích tắc.
Khi một bot dịch vụ khách hàng xử lý 10.000 yêu cầu mỗi phút vào lúc 3 giờ sáng, nó không thể tạm dừng để chờ con người phê duyệt thông báo đẩy MFA. Khi một quy trình tự động chạy các nhiệm vụ ủy quyền qua API, nó cần quản lý chứng thực mà không ai phải nhấp gì cả. Cơ sở hạ tầng hiện tại—nhắc nhở mật khẩu, thách thức MFA, quy trình xác minh con người—trở thành nút thắt cổ chai khiến mọi thứ bị đình trệ.
Điều này không phải là một vấn đề UX nhỏ. Đó là một khủng hoảng kiến trúc.
Nơi Các Hệ Thống Truyền Thống Gặp Sự Cổ Chết
Các giải pháp xác thực máy-máy hiện có cũng không giải quyết được vấn đề này. Chúng được xây dựng cho giao tiếp đơn giản giữa dịch vụ với dịch vụ, không phải cho vòng đời phức tạp của tác nhân với yêu cầu quyền linh hoạt và chuỗi ủy quyền tinh vi.
Vấn đề cốt lõi: IAM truyền thống cấp quyền ở cấp độ người dùng. Khi bạn ủy quyền một trợ lý AI quản lý email của bạn, các hệ thống hiện tại hoặc là cấp quyền truy cập đầy đủ vào mọi thứ bạn có thể làm—hoặc là hoàn toàn thất bại vì chúng không hỗ trợ giới hạn phạm vi chi tiết.
Hãy xem ví dụ ngân hàng: Một con người có thể suy nghĩ về các hướng dẫn. Họ tự nhiên biết rằng một yêu cầu “chuyển $100,000 đến một tài khoản không rõ” có thể đáng ngờ, ngay cả khi về mặt kỹ thuật là cho phép. Một hệ thống AI thiếu khả năng phán đoán này. Nó cần các giới hạn rõ ràng: tác nhân này chỉ có thể thanh toán cho các nhà cung cấp được phê duyệt, tối đa $5,000 mỗi giao dịch, ngày hết hạn là 31 tháng 12 năm 2025.
Đây là lý do tại sao chúng ta cần quyền tối thiểu theo mặc định cho các tác nhân được ủy quyền—một khái niệm mà IAM truyền thống chưa từng phải thực hiện vì con người đã cung cấp lớp lý luận đó.
Hai Mô Hình Tác Nhân Cơ Bản Khác Nhau Đòi Hỏi Các Phương Pháp Danh Tính Khác Nhau
Tác Nhân Bán Tự Động: Vấn Đề Ủy Quyền
Khi một con người ủy quyền nhiệm vụ cho một tác nhân AI (nghĩ: trợ lý điều hành xử lý lịch trình và báo cáo chi phí), hệ thống cần thực hiện xác thực danh tính kép:
Danh tính chính: Người đã ủy quyền tác nhân Danh tính phụ: Phiên bản tác nhân có phạm vi hạn chế rõ ràng
Trong thuật ngữ OAuth 2.1/OIDC, điều này có nghĩa là một trao đổi token tạo ra các token truy cập hạn chế: