Module 4 • Bài 1545 phút

Danh tính Agent, Elicitation & Xác thực Đa lớp

Tách biệt thẩm quyền con người khỏi danh tính Agent, đặt điểm phê duyệt Just-In-Time, cơ chế Elicitation, xác thực MFA và đối chiếu thay đổi qua Vibe Diff.

Cấp danh tính độc lập cho Agent thay vì dùng quyền hạn mặc định của user
Thiết kế luồng tương tác Elicitation giúp con người ra quyết định đủ thông tin
Ứng dụng MFA và Vibe Diff để xác thực các hành động có mức độ rủi ro cao

Cấp danh tính cho agent, không trao quyền hạn mặc định của người dùng

Một agent có quá nhiều quyền hạn có thể trở thành một kẻ đại diện bị nhầm lẫn (confused deputy). Một chỉ dẫn độc hại yêu cầu nó thực hiện một hành động mà người dùng về mặt kỹ thuật có thể làm nhưng hoàn toàn không có ý định làm. Nếu agent thừa hưởng thông tin đăng nhập dài hạn của con người, hệ thống không thể phân biệt rõ ràng giữa hành vi của người dùng và hành vi máy được ủy quyền.

Tách biệt thẩm quyền của con người khỏi danh tính của agent

Hãy phân biệt danh tính được ủy quyền (delegated identity) với danh tính agent (agentic identity). Danh tính được ủy quyền cho biết con người nào đã khởi tạo tác vụ và quyền hạn nào của người dùng có thể được xem xét. Danh tính agent cho biết đối tượng không phải con người nào thực sự lập kế hoạch hoặc thực thi hành động. Bản ghi kiểm toán cần cả hai. Nếu agent chỉ chạy dưới danh tính của người dùng, một agent bị xâm nhập sẽ trông giống như hoạt động hợp lệ của người dùng; nếu chỉ chạy dưới danh tính riêng, hệ thống lại mất đi sự đồng ý và ranh giới tổ chức của người dùng.

Ví dụ, Maya có thể được phép chỉnh sửa mọi tài khoản do team bán hàng của cô ấy sở hữu. Research agent không cần toàn bộ thẩm quyền của Maya chỉ vì cô ấy đã khởi chạy nó. Với tác vụ "soạn bản tóm tắt cho Acme," agent phải có danh tính riêng và một token chỉ đọc được các trường thông tin đã duyệt của Acme trong vài phút. Bản ghi kiểm toán lúc này ghi nhận được cả "Maya đã ủy quyền tác vụ này" lẫn "research-agent-v3 đã thực hiện lệnh gọi tool này."

Từ đó hình thành mô hình danh tính zero-trust thực tế:

  1. Không có thẩm quyền mặc định (Zero Ambient Authority): Agent khởi đầu không có master key và không thừa hưởng phiên làm việc của con người.
  2. Danh tính được ủy quyền: Mọi hành động vẫn truy xuất được về tổ hợp con người-agent-tác vụ.
  3. Truy cập tức thì (Just-In-Time - JIT access): Chỉ sau khi biết chính xác hành động mới cấp token hẹp cần thiết cho hành động đó.
  4. Thu hẹp phạm vi tài nguyên (Resource downscoping): Giới hạn API, bản ghi, file, môi trường và điểm đến đi ra ngoài-không chỉ dừng lại ở tên tool.
  5. Hết hạn và thu hồi: Thẩm quyền kết thúc khi bước thực thi hoặc khoảng thời gian phê duyệt kết thúc, kể cả khi phiên đăng nhập của người dùng vẫn còn.

Thu hẹp quyền JIT phải bao phủ cả hệ thống file lẫn API. Sử dụng các quy tắc cây file mặc định từ chối (deny-by-default file-tree rules) để script được sinh ra chỉ chạm vào các đường dẫn dự án được phép, tuyệt đối không đọc secret, manifest triển khai hoặc script build không liên quan. Agent con hoặc sandbox nhận một token mới cho đúng tài nguyên của nó, không bao giờ thừa hưởng token rộng hơn của agent cha.