Định danh AI Agent 2026: Xác thực & Phân quyền cho Tác nhân

Posted on: 6/6/2026 1:13:37 AM

Năm 2026, câu hỏi khó nhất khi đưa AI Agent lên production không còn là "model có đủ thông minh không?" mà là "khi agent gọi vào database, gửi email hay chuyển tiền — nó đang hành động dưới danh nghĩa ai, và ai chịu trách nhiệm?". Đây là bài toán định danh (identity) và phân quyền (authorization) cho tác nhân tự trị — phần hạ tầng âm thầm nhưng quyết định việc một hệ thống multi-agent có thể vận hành an toàn hay không.

Nếu bài trước trong chuỗi này nói về bảo mật AI Agent ở góc độ chống prompt injection và Lethal Trifecta, thì bài này đi xuống một tầng sâu hơn: danh tính của chính agent — nó là "ai" trong con mắt của hệ thống IAM, lấy token kiểu gì, được làm gì và không được làm gì.

1. Tại sao AI Agent cần một danh tính riêng?

Trong kiến trúc truyền thống, mọi thứ chạy dưới danh nghĩa người dùng (qua session) hoặc dưới danh nghĩa dịch vụ (qua API key tĩnh). AI Agent phá vỡ cả hai mô hình: nó vừa hành động thay mặt người dùng, vừa có quyền tự chủ để gọi hàng chục công cụ, sinh ra hàng loạt sub-agent, và chạy bất đồng bộ khi người dùng đã offline. Câu hỏi "ai vừa xóa bản ghi này?" trở nên cực kỳ khó trả lời nếu agent không có danh tính độc lập, có thể truy vết.

2. Ba bài toán cốt lõi: Xác thực, Phân quyền, Uỷ quyền

Định danh agent không phải một bài toán, mà là ba bài toán liên quan chặt chẽ. Tách bạch chúng ngay từ đầu là chìa khoá để thiết kế đúng:

Sai lầm phổ biến nhất là gộp ba thứ này vào một API key tĩnh có toàn quyền: agent vừa "là" service account đó, vừa "được phép làm mọi thứ", và "không biết đang thay mặt ai". Khi key rò rỉ — và với agent xử lý nội dung không tin cậy, rò rỉ chỉ là vấn đề thời gian — kẻ tấn công thừa hưởng trọn vẹn quyền lực đó.

3. Tại sao agent không dùng mật khẩu — hai mô hình xác thực

AI agent không gõ mật khẩu, không nhận SMS OTP, không bấm passkey. Nó xác thực bằng thông tin định danh liên kết (federated credential) hoặc chứng chỉ workload — những thứ máy-có-thể-chứng-minh chứ không phải con-người-ghi-nhớ. Có hai mô hình truy cập, và việc chọn đúng mô hình cho từng thao tác là quyết định kiến trúc quan trọng nhất:

graph TD
    U["Nguoi dung"] -->|"uy quyen"| AG["AI Agent
(co danh tinh rieng)"]
    AG -->|"Mo hinh 1:
Delegated / On-Behalf-Of"| R1["Tai nguyen voi
quyen CUA NGUOI DUNG"]
    AG -->|"Mo hinh 2:
App-only / Workload"| R2["Tai nguyen voi
quyen RIENG CUA AGENT"]
    R1 --> NOTE1["VD: doc email cua chinh user,
tao file trong drive cua user"]
    R2 --> NOTE2["VD: ghi log he thong,
goi internal service"]
    style U fill:#e94560,stroke:#fff,color:#fff
    style AG fill:#16213e,stroke:#fff,color:#fff
    style R1 fill:#4CAF50,stroke:#fff,color:#fff
    style R2 fill:#2c3e50,stroke:#fff,color:#fff
    style NOTE1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style NOTE2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50

Hình 1: Hai mô hình truy cập của agent — Delegated (mượn quyền người dùng) và App-only (quyền riêng của agent)

Delegated access dùng khi agent làm việc thay mặt một người dùng cụ thể: quyền bị giới hạn bởi giao của quyền người dùng và quyền agent. App-only / workload access dùng cho tác vụ nền không gắn người dùng nào. Nguyên tắc vàng: thao tác đụng tới dữ liệu của người dùng phải đi qua delegated access — đừng để agent dùng quyền hệ thống "thần thánh" để lách qua kiểm soát truy cập của chính người dùng đó.

4. OAuth 2.1 cho Agent: Authorization Code + PKCE

Chuẩn de-facto để agent lấy token thay mặt người dùng là OAuth 2.1 Authorization Code Flow với PKCE. Vì agent là public client — không thể giữ bí mật một client secret một cách an toàn — PKCE (Proof Key for Code Exchange) là bắt buộc, không còn là tuỳ chọn như thời OAuth 2.0.

sequenceDiagram
    participant U as Nguoi dung
    participant A as AI Agent (client)
    participant AS as Authorization Server
    participant RS as Resource Server (MCP/API)
    A->>AS: 1. Authorize + code_challenge (PKCE)
resource=https://mcp.example.com
    AS->>U: 2. Man hinh consent
(hien danh tinh agent)
    U->>AS: 3. Chap thuan scope toi thieu
    AS->>A: 4. Authorization code
    A->>AS: 5. Doi code + code_verifier
    AS->>A: 6. Access token (short-lived)
+ refresh token
    A->>RS: 7. Goi API kem Bearer token
    RS->>RS: 8. Validate aud == chinh minh
(RFC 8707 resource binding)
    RS->>A: 9. Ket qua

Hình 2: Luồng OAuth 2.1 Authorization Code + PKCE cho AI Agent

Một yêu cầu token điển hình của agent (bước 5) trông như sau — chú ý resource (RFC 8707 Resource Indicators) gắn token vào đúng một server, và PKCE code_verifier:

POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&redirect_uri=https://agent.example.com/callback
&resource=https://mcp.example.com
&client_id=agent-orchestrator

5. Uỷ quyền theo chuỗi: Token Exchange & On-Behalf-Of

Hệ thống multi-agent hiếm khi phẳng: một orchestrator gọi sub-agent, sub-agent gọi tiếp một tool-agent... Mỗi chặng cần trả lời được: "token này rốt cuộc đại diện cho ai, qua tay những ai?". Câu trả lời là OAuth 2.0 Token Exchange (RFC 8693).

Token Exchange cho phép một bên đổi token hiện có lấy token mới có phạm vi hẹp hơn, kèm thông tin actor (bên đang muốn hành động thay) qua tham số actor_token. Chuỗi uỷ quyền được biểu diễn bằng cách lồng claim act: claim ngoài cùng là actor hiện tại, các claim lồng bên trong là các actor trước đó.

graph LR
    U["Nguoi dung
(subject)"] -->|"delegate"| O["Orchestrator
Agent"]
    O -->|"token exchange"| S["Sub-Agent
(scope hep hon)"]
    S -->|"token exchange"| T["Tool-Agent
(1 hanh dong)"]
    T --> API["Resource Server"]
    style U fill:#e94560,stroke:#fff,color:#fff
    style O fill:#16213e,stroke:#fff,color:#fff
    style S fill:#2c3e50,stroke:#fff,color:#fff
    style T fill:#2c3e50,stroke:#fff,color:#fff
    style API fill:#4CAF50,stroke:#fff,color:#fff

Hình 3: Chuỗi uỷ quyền multi-agent — mỗi chặng thu hẹp scope và ghi lại actor

Payload của access token cuối chuỗi mang nguyên vẹn lịch sử uỷ quyền nhờ claim act lồng nhau — đây chính là thứ giúp audit "ai-thay-mặt-ai" sau sự cố trở nên khả thi:

{
  "sub": "user-8842",
  "aud": "https://mcp.example.com",
  "scope": "files:read calendar:write",
  "act": {
    "sub": "agent://orchestrator-prod",
    "act": {
      "sub": "agent://subagent-scheduler"
    }
  }
}

6. Danh tính trong MCP và A2A

Hai giao thức nền tảng của hệ sinh thái agent 2026 — MCP (agent ↔ tool) và A2A (agent ↔ agent) — đều đã đặt định danh làm công dân hạng nhất, nhưng theo cách khác nhau:

Điểm thiết kế quan trọng trong spec MCP 06/2025: MCP Server chỉ đóng vai resource server, không tự phát hành token mà chỉ validate token do một Authorization Server chuyên biệt cấp. Sự tách bạch này tránh được phản-mẫu "mỗi server tự làm IAM" — vốn là nguồn gốc của vô số lỗ hổng.

7. Bức tranh nhà cung cấp: Entra Agent ID và bạn bè

Các ông lớn IAM đã nhảy vào. Tháng 4/2026, Microsoft Entra Agent ID đạt General Availability — một nền tảng định danh dành riêng cho agent, mở rộng nguyên tắc Zero Trust (xác thực, phân quyền, governance, lifecycle) sang non-human identity bằng các chuẩn mở OAuth 2.0, MCP và A2A.

8. Nguyên tắc thiết kế: quyền tối thiểu, tức thời, có cổng người

Công nghệ chỉ là một nửa; nửa còn lại là kỷ luật thiết kế. Bốn nguyên tắc nên áp dụng cho mọi agent production:

• Least privilege theo scope: mỗi token chỉ chứa đúng scope cho tác vụ trước mắt. Đừng cấp admin:* khi agent chỉ cần files:read.
• Just-in-time & step-up: nâng quyền đúng lúc cần, hết việc thì token hết hạn. Thao tác nhạy cảm kích hoạt step-up authorization.
• Human-in-the-loop làm cổng phân quyền: những hành động không thể đảo ngược (chuyển tiền, xoá dữ liệu, gửi mail ra ngoài) phải qua phê duyệt của con người — chính là tầng authorization cuối cùng.
• Truy vết được mọi hành động: mọi lời gọi đều mang danh tính agent + chuỗi act, đẩy vào audit log bất biến để trả lời "ai làm gì" sau sự cố.

9. Kết luận

Khi AI agent chuyển từ demo sang production, danh tính trở thành chu vi an ninh mới. Một agent không có danh tính riêng là một agent không thể truy vết, không thể giới hạn quyền, và không thể audit — ba điều kiện tối thiểu để bất kỳ hệ thống tự trị nào được tin tưởng.

Tin tốt: ta không cần phát minh lại bánh xe. OAuth 2.1 + PKCE cho xác thực, RFC 8707 cho resource binding, RFC 8693 Token Exchange cho chuỗi uỷ quyền, draft on-behalf-of cho danh tính agent trên màn consent, và các nền tảng như Entra Agent ID cho governance — bộ công cụ đã sẵn sàng. Việc còn lại là kỷ luật: cấp quyền tối thiểu, token ngắn hạn, và đặt con người ở đúng những cánh cổng không thể đảo ngược. Trong kỷ nguyên mà danh tính phi-người áp đảo con người 45:1, đây không còn là "nice to have" — đó là điều kiện sống còn.

Nguồn tham khảo

• Model Context Protocol — Authorization Specification
• RFC 8693 — OAuth 2.0 Token Exchange
• Microsoft Learn — What is Microsoft Entra Agent ID?
• Microsoft Learn — Authentication protocols in agents
• Descope — Diving Into the MCP Authorization Specification
• NHI Mgmt Group — Identity governance & non-human identities outnumbering humans