Bài 4 — Danh tính agent: mỗi agent một identity riêng

Khi agent gọi database, API hay tool, hệ thống bên kia cần biết chắc: đây là ai? Nếu mọi agent (và cả con người) dùng chung một tài khoản, thì khi sự cố xảy ra bạn không thể truy ra thủ phạm, không thể thu hồi riêng, không thể phân quyền riêng. Mỗi agent phải có một danh tính (identity) riêng, xác thực được.

Ba loại danh tính bạn phải phân biệt

• Danh tính của agent (workload identity): chính bản thân dịch vụ agent — ví dụ agent-cskh-prod.
• Danh tính người dùng cuối: người đang nhờ agent làm việc.
• Danh tính hành động thay mặt (delegated / on-behalf-of): agent hành động thay người dùng — cần mang theo cả hai.

Nhầm lẫn ba loại này là nguồn gốc của confused deputy — agent dùng quyền cao của chính nó để làm việc mà người dùng cuối lẽ ra không được phép.

Ví dụ: agent duyệt nghỉ phép

Agent HR có quyền đọc bảng leave_requests. Nhân viên An hỏi: "Xem đơn nghỉ phép của tôi." Agent phải trả về chỉ đơn của An, không phải của cả công ty — dù bản thân agent có quyền đọc tất cả.

# SAI: dùng quyền agent, bỏ qua danh tính người hỏi
rows = db.query("SELECT * FROM leave_requests")

# ĐÚNG: mang danh tính người dùng vào truy vấn
def handle(user_id, msg):
    # user_id lấy từ token đã xác thực, KHÔNG từ nội dung chat
    return db.query(
        "SELECT * FROM leave_requests WHERE employee_id=%s", (user_id,))

Điểm mấu chốt: user_id đến từ token đã xác thực, không phải từ câu chữ trong chat (kẻ xấu có thể gõ "tôi là giám đốc").

Cơ chế danh tính theo môi trường

• Cloud: IAM role / workload identity (AWS IAM Role, GCP Service Account, Azure Managed Identity) — không cần lưu key.
• On-prem / K8s: SPIFFE/SPIRE cấp SVID (chứng chỉ danh tính ngắn hạn) cho mỗi workload.
• Vault: AppRole gắn với từng agent.
• Delegation: OAuth2 token exchange / on-behalf-of flow để mang danh tính người dùng qua nhiều lớp.

Các bước thiết lập danh tính agent

• Đặt tên danh tính rõ ràng cho mỗi agent + môi trường: agent-<vaitro>-<env>.
• Gắn danh tính đó với hệ thống xác thực (IAM/SPIFFE/AppRole), không dùng chung.
• Dùng credential ngắn hạn (short-lived token) thay vì key tĩnh.
• Truyền danh tính người dùng riêng qua context, tách khỏi danh tính agent.
• Ở mỗi tool, kiểm tra quyền theo danh tính người dùng, không chỉ danh tính agent.

Luồng danh tính hành động thay mặt (on-behalf-of)
Người dùng (An, token U) 
   → Agent (identity: agent-hr-prod, token A) 
      → API HR nhận cả (A + U) 
         → chỉ trả dữ liệu An được phép

Khung tư duy: "Ai + Thay ai + Làm gì"

Mỗi lần agent gọi một hệ thống, log và policy phải trả lời đủ:

• Ai đang gọi? (danh tính agent)
• Thay ai? (danh tính người dùng cuối)
• Làm gì? (hành động + tài nguyên)

Thiếu bất kỳ vế nào là lỗ hổng confused deputy.

Checklist danh tính

• [ ] Mỗi agent + môi trường có danh tính riêng, đặt tên rõ ràng.
• [ ] Không dùng chung tài khoản giữa agent, người và dịch vụ khác.
• [ ] Credential ngắn hạn, tự hết hạn (không key tĩnh vĩnh viễn).
• [ ] Danh tính người dùng cuối được truyền và kiểm tra riêng.
• [ ] Quyền được kiểm ở tầng tài nguyên theo danh tính người dùng.
• [ ] user_id lấy từ token, không từ nội dung do LLM/người dùng gõ.

Sai lầm thường gặp

• Confused deputy: agent dùng quyền cao của mình để lấy dữ liệu người dùng cuối không được phép xem.
• Chung một service account cho mọi agent — không truy vết được, thu hồi một cái là chết cả cụm.
• Tin user_id do LLM sinh ra từ nội dung chat thay vì từ token xác thực.
• Danh tính không hết hạn: token agent sống mãi, không xoay.
• Không phân biệt agent với người trong log, nên khi điều tra không biết là bot hay người thật hành động.

Bài 5 sẽ biến những hành động của các danh tính này thành bằng chứng: audit log — ghi lại mọi việc agent làm để không thể chối bỏ.