Cấp quyền cho AI agent: tài khoản dùng chung làm mất dấu trách nhiệm

Để cấp quyền cho AI agent truy cập dữ liệu hoặc công cụ doanh nghiệp, hãy tạo danh tính máy riêng cho agent, xác thực danh tính đó và giới hạn quyền theo tài nguyên, hành động, nhiệm vụ và thời hạn. Khi agent làm việc thay người dùng, quyết định cấp quyền phải lưu được người ủy quyền cùng phạm vi họ đã chấp thuận. NIST nêu nhu cầu áp dụng kiểm soát nhận dạng và ủy quyền phù hợp khi agent truy cập nhiều tập dữ liệu, công cụ và ứng dụng.

Nếu nhiều agent dùng chung một tài khoản và nhật ký chỉ ghi tên tài khoản đó, bản ghi không cho biết agent nào đã gửi dữ liệu hoặc sửa thông tin. Muốn truy trách nhiệm, hệ thống phải nối từng hành động với danh tính agent, quyền còn hiệu lực, nhiệm vụ và lần phê duyệt cụ thể. Nhật ký ở lớp ứng dụng có thể bổ sung dấu vết, nhưng chỉ hữu ích khi các hệ thống giữ được mối liên kết ấy xuyên suốt lời gọi công cụ.

Tách danh tính người, agent và công cụ

Trước khi tạo quyền, hãy xác định người yêu cầu công việc, người có thẩm quyền phê duyệt, agent thực thi và công cụ nhận lệnh. Agent cần một mã định danh máy để quản lý quyền và vòng đời; mỗi lần chạy có thêm mã nhiệm vụ hoặc mã phiên để phân biệt các yêu cầu do cùng agent tạo ra. Chủ sở hữu nghiệp vụ chịu trách nhiệm về cấu hình và mục đích sử dụng, nhưng tên của họ không thể thay thế danh tính agent trong sự kiện thực thi.

Concept paper của NCCoE đặt câu hỏi về metadata danh tính agent, cấp và thu hồi khóa, quyền tối thiểu, ủy quyền thay mặt người dùng, cùng cách gắn hành động của agent với sự cho phép của con người. Tài liệu này là bản thảo nêu vấn đề cho một dự án được đề xuất, không phải bộ bước triển khai bắt buộc. Với từng agent, hồ sơ nội bộ vì thế cần chỉ rõ ai sở hữu nó, nó được dùng cho quy trình nào và hệ thống nào ra quyết định cho phép trước khi công cụ thực thi.

Nếu một agent giao việc cho agent khác, ngữ cảnh yêu cầu cần giữ cả bên chuyển lệnh lẫn bên trực tiếp gọi công cụ. Chỉ lưu danh tính agent cuối cùng sẽ khiến chuỗi ủy quyền bị đứt: người rà soát thấy hành động đã xảy ra nhưng khó biết nó bắt đầu từ yêu cầu nào và có nằm trong quyền được giao hay không.

Đặt quyền theo hành động, không theo tên vai trò

Ma trận quyền nên bắt đầu từ những việc agent thực sự phải làm. Ví dụ giả định: một agent hỗ trợ xử lý yêu cầu khách hàng cần đọc hồ sơ của yêu cầu đang mở và tạo câu trả lời nháp. Tên quyền dưới đây là mẫu để ánh xạ sang tài nguyên, API và chính sách của từng doanh nghiệp, không phải phạm vi cấp sẵn cho mọi agent.

• Đọc: cho phép lấy dữ liệu của yêu cầu được giao, với điều kiện xác định được mã yêu cầu và tập dữ liệu liên quan. Quyền này không mặc nhiên mở toàn bộ kho hồ sơ khách hàng.
• Ghi: cho phép tạo bản nháp hoặc cập nhật những trường đã chỉ định. Việc sửa dữ liệu gốc cần được xét riêng vì tác động khác với thêm ghi chú nội bộ.
• Gửi: tách quyền soạn khỏi quyền gửi email, thông báo hoặc dữ liệu sang hệ thống ngoài. Chính sách cần nêu kênh, người nhận hợp lệ và điều kiện phải xin phê duyệt trước khi gửi.
• Phê duyệt: xác định quyết định nào thuộc về con người. Nếu một loại quyết định được giao cho agent, hãy ghi rõ nguồn ủy quyền và giới hạn theo loại việc, thay vì suy quyền phê duyệt từ quyền ghi.

Mỗi quyền cần trả lời cùng một bộ câu hỏi: agent nào được làm gì, trên tài nguyên nào, trong điều kiện nào và đến khi nào. Một token cho phép đọc hồ sơ không đồng nghĩa với quyền chuyển nội dung hồ sơ ra ngoài. Khi bổ sung công cụ hoặc đổi nhiệm vụ, hãy xét lại những ô liên quan trong ma trận trước khi mở rộng quyền; nếu không, phạm vi cũ có thể đi theo agent sang một công việc khác.

Giới hạn token và thiết kế đường thu hồi

Sau khi duyệt ma trận, cấp thông tin xác thực cho danh tính máy và phát hành token phù hợp với nhiệm vụ. Khuyến nghị bảo mật OAuth trong RFC 9700 nêu rằng đặc quyền của access token nên được giới hạn ở mức cần thiết; máy chủ tài nguyên phải kiểm tra ở mỗi yêu cầu xem token có dành cho máy chủ, tài nguyên và hành động đó hay không. Vì vậy, API nhận lệnh cần thực thi chính sách, thay vì chỉ dựa vào việc token đã được phát hành.

Hồ sơ cấp quyền cần ghi API đích, tài nguyên, hành động được phép, phạm vi token, thời điểm hết hạn và căn cứ ủy quyền. Chọn thời hạn phù hợp với nhiệm vụ; khi công việc kết thúc hoặc bối cảnh thay đổi, lần cấp tiếp theo phải được đánh giá theo quyền hiện có. Khóa dùng để xác thực agent cần được quản lý riêng, có người chịu trách nhiệm thay và thu hồi khi agent ngừng hoạt động hoặc thông tin xác thực có nguy cơ bị lộ.

Thu hồi danh tính trong danh sách quản trị chưa chắc đã chặn ngay một token đang còn hiệu lực. Thiết kế phải xác định điểm thực thi quyền kiểm tra trạng thái thu hồi bằng cách nào, phiên đang chạy được xử lý ra sao và độ trễ thu hồi nào có thể chấp nhận đối với từng hành động. Với quyền gửi hoặc phê duyệt, khoảng trễ đó là một thuộc tính vận hành cần được kiểm tra trước khi cấp quyền thật.

Ghi nhật ký nối hành động với lần phê duyệt

Một sự kiện kiểm toán có ích phải trả lời được ai yêu cầu, ai cho phép, agent nào thực hiện, công cụ nào nhận lệnh và kết quả là gì. Ghi cả yêu cầu bị từ chối để phân biệt lệnh vượt quyền với lệnh chưa từng đến API. Mã tương quan giúp ghép các bước của cùng nhiệm vụ mà không cần chép toàn bộ dữ liệu nhạy cảm vào nhật ký.

Với thao tác gửi hoặc phê duyệt, bản ghi nên chứa mã quyết định phê duyệt, người quyết định, thời điểm, phạm vi được chấp thuận và mã sự kiện thực thi. Nếu công cụ chỉ ghi “đã gửi” dưới tài khoản dùng chung, riêng bản ghi đó không thể phân biệt các agent đã dùng tài khoản, dù các dấu vết ở hệ thống khác có thể giúp điều tra. Nhật ký cần được bảo vệ khỏi sửa đổi trái phép và đối chiếu được với hồ sơ cấp quyền.

Mẫu hồ sơ agent trước khi cấp quyền thật

Một hồ sơ agent ngắn có thể làm đầu vào chung cho hệ thống danh tính, chính sách API và kiểm toán. Các trường sau nên được điền trước khi agent được phép chạm tới dữ liệu thật; mục đích chung chung như “hỗ trợ mọi việc” không đủ để xác định tài nguyên và hành động cần cấp.

• Chủ sở hữu và mục đích: bộ phận chịu trách nhiệm, người duyệt cấu hình, loại nhiệm vụ và giới hạn sử dụng.
• Danh tính máy: mã agent, môi trường chạy, phương thức xác thực và nơi quản lý khóa; tách khỏi tài khoản cá nhân hoặc tài khoản chung.
• Quyền truy cập: API đích, tài nguyên, hành động đọc, ghi, gửi hoặc phê duyệt, điều kiện áp dụng và phạm vi token.
• Nguồn ủy quyền: mã yêu cầu, người ủy quyền, thời điểm quyết định, phạm vi chấp thuận và thời hạn hiệu lực.
• Vòng đời: thời hạn token, người có quyền thu hồi, cách vô hiệu hóa phiên đang chạy và thời điểm rà soát quyền.
• Trường audit: mã agent, mã phiên, mã nhiệm vụ, người yêu cầu, mã ủy quyền, API, hành động, thời điểm, kết quả và mã tương quan.

Trước khi đưa agent vào vận hành, thử một yêu cầu hợp lệ, một yêu cầu vượt phạm vi và một trường hợp thu hồi giữa nhiệm vụ. Kết quả cần cho thấy API thực thi đúng ma trận và bản ghi của từng hành động dẫn ngược được về quyết định đã cho phép nó.

Đọc thêm:

• Vesta gọi 30 triệu USD: AI làm 40% việc, trách nhiệm vẫn ở bên cho vay
• 11,5 triệu việc làm Việt Nam có thể đổi nhiệm vụ vì GenAI, không chỉ mất việc
• Mỹ thêm 162.000 việc làm, ngành thông tin vẫn mất nhân sự