AI Agent Identity — DID, UCAN & Delegation Model Cho Thế Giới Agentic

TL;DR — Tóm tắt trong 60 giây

AI agent có thể có cryptographic identity (DID, keypair) — nhưng "accountability" vẫn là khái niệm pháp lý về human principal
Multi-agent system: agent cần chứng minh cả "tôi là ai" lẫn "tôi được ủy quyền làm gì"
UCANUser-Controlled Authorization Network: capability-based auth không cần central server. Delegation chain có scope + expiry + proof chain — phù hợp AI agent authorization. (User Controlled Authorization Networks): delegation model cho agent — capability chained từ human xuống agent
Rủi ro chính: agent impersonation, capability escalation, thiếu audit trail rõ ràng
AI agent identity là area đang phát triển nhanh — chưa có production standard được adopt rộng

1. Vấn Đề Danh Tính Của AI Agent

Khi một AI agent tự động gửi email, ký hợp đồng, thực hiện giao dịch, hay tương tác với service khác — câu hỏi đặt ra là: Agent đó là ai? Ai ủy quyền cho nó? Và ai chịu trách nhiệm khi nó làm sai?

Với con người, identity được chứng minh bằng CMND, biometric, hay credential từ issuer tin cậy. Với AI agent, identity phức tạp hơn vì:

Một agent có thể chạy nhiều instance song song — không có "unique body"
Agent model có thể được copy, fork, fine-tune — "cùng agent" là khái niệm mơ hồ
Không có legal personhood — accountability luôn phải map về human hoặc organization
Agent có thể delegate cho sub-agent — tạo chain delegation phức tạp

🔑

Phân biệt quan trọng: Authentication (agent prove "tôi là agent X") và Authorization (agent prove "tôi được phép làm Y") là hai bài toán khác nhau và cần giải quyết riêng. Nhiều system chỉ giải quyết authentication mà bỏ quên authorization granularity.

🤖

📌 Key Takeaway

AI agent cần identity riêng vì accountability thực tế: khi agent action có consequence pháp lý hoặc tài chính, "AI tự làm, tôi không biết" không còn là lý do hợp lệ. Thiết kế identity từ đầu, không add-on sau.

2. Cryptographic Identity Cho AI Agent

Về mặt kỹ thuật, AI agent có thể có identity thông qua:

Keypair cơ bản

Agent được provisioned với một public/private keypair lúc instantiation. Agent sign mọi action với private key. Verifier check signature với public key. Đây là cách đơn giản nhất — nhưng không giải quyết delegation hay capability scoping.

DID cho Agent

Agent có DID riêng — ví dụ did:key:zAGENT_PUBKEY hoặc did:ethr:0xAGENT_ADDR. DID Document chứa public key của agent và có thể chứa service endpoint để contact agent. Human principal cũng có DID — relationship "agent phục vụ principal" có thể được express thông qua DID Document controller field hoặc Verifiable Credential.

// DID Document của AI Agent
{
  "id": "did:key:zAGENT_PUBKEY_123",
  "controller": "did:ethr:0xHUMAN_PRINCIPAL",  ← owner
  "verificationMethod": [{
    "id": "did:key:zAGENT_PUBKEY_123#key-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "zAGENT_PUBKEY_123"
  }],
  "service": [{
    "type": "AgentEndpoint",
    "serviceEndpoint": "https://agent.example.com/api"
  }]
}

🤖

📌 Key Takeaway

Delegation chain: User → Agent → Sub-agent. Mỗi hop phải explicit, scope-limited, có expiry, và có audit trail. Agent không tự expand scope — cần re-authorization từ principal. Không có "implicit permission".

3. UCAN — Delegation Model Cho Agent

UCAN (User Controlled Authorization Networks) là một approach đặc biệt phù hợp cho AI agent delegation: capability-based authorization được chain từ root đến leaf.

// UCAN delegation chain

// Level 0: Human tạo root UCAN
Human (did:ethr:0xHUMAN) grants:
  - resource: "storage://mybucket/*"
  - abilities: ["storage/put", "storage/get"]
  - expiration: 2026-04-01T00:00:00Z
  - audience: did:key:zAGENT_A  ← ủy quyền cho Agent A

// Level 1: Agent A delegates một phần cho Agent B
Agent A (did:key:zAGENT_A) grants:
  - resource: "storage://mybucket/reports/*"  ← narrow scope
  - abilities: ["storage/get"]                ← chỉ read, không write
  - expiration: 2026-03-15T00:00:00Z          ← shorter expiry
  - audience: did:key:zAGENT_B
  - proof: [root_UCAN]  ← chain back to human

// Nguyên tắc: agent không thể grant nhiều hơn mình có
// Capability chỉ có thể narrow hoặc giữ nguyên khi delegate

UCAN chạy trên JWT format, không cần blockchain. Đây là approach của Protocol Labs (Fission) và đang được xem xét cho agentic AI workflow trong nhiều framework.

🤖

📌 Key Takeaway

Credential cho agent phải: ephemeral (TTL ngắn), scope-limited, revocable ngay lập tức. Không dùng long-lived API key — leaked key = full access không audit trail. Design for least-privilege từ đầu.

4. Rủi Ro: Agent Impersonation & Capability Escalation

Agent Impersonation

Kẻ tấn công tạo agent giả mạo với DID tương tự hoặc claim là "Agent của company X". Nếu không có proper DID verification, user hoặc service có thể bị lừa giao credential hoặc quyền truy cập cho agent giả mạo.

Capability Escalation

Agent được grant quyền hạn chế nhưng tìm cách thực hiện action vượt scope. Ví dụ: agent được grant "đọc file" nhưng tìm cách dùng đọc để trigger side effect ghi file. Trong agentic system, capability escalation là attack surface nguy hiểm vì agent có thể chain nhiều tool call.

Audit Trail Gaps

Trong multi-agent system phức tạp, khó trace được chính xác: agent nào đã làm gì, với authorization từ đâu, và action nào đã trigger consequence gì. Mỗi agent cần log action kèm attestation (chữ ký) để tạo audit trail verifiable.

⚠️

Confused Deputy Attack: Agent A có quyền access resource R. Agent B thuyết phục A thực hiện action trên R thay mình — B không có quyền nhưng dùng A như "proxy". UCAN-style capability verification giúp ngăn điều này vì mỗi delegation phải explicit.

🤖

📌 Key Takeaway

UCAN (User-Controlled Authorization Network): capability-based auth không cần central server. Mỗi capability có audience, scope, expiry, proof chain. Phù hợp multi-agent, cross-domain authorization.

5. Accountability — Ai Chịu Trách Nhiệm Khi Agent Làm Sai?

Câu hỏi pháp lý quan trọng nhất: khi AI agent gây thiệt hại, ai chịu trách nhiệm? Hiện tại, framework pháp lý chưa có câu trả lời thống nhất. Nhưng từ góc độ kỹ thuật, accountability chain cần được thiết kế rõ ràng:

Principal accountability: Human hoặc organization tạo agent chịu trách nhiệm về behavior của agent đó
Delegation chain: Mọi action của agent phải traceable về authorization chain từ human
Capability limitation: Agent không thể thực hiện action ngoài scope được ủy quyền — enforce bởi cryptography, không phải chỉ policy
Revocation: Human có thể revoke delegation bất kỳ lúc nào

Về triển vọng rộng hơn của AI trong identity ecosystem — bao gồm AI làm cho Sybil attackTấn công bằng cách tạo nhiều danh tính giả để chiếm đa số trong hệ thống phân tán. Tên từ cuốn sách về bệnh nhân có 16 nhân cách (1973). dễ hơn — xem bài Sybil Attack. Về kiến trúc DID là nền tảng cho agent identity, xem bài DID là gì.

🤖

📌 Key Takeaway

Slashable stake thêm economic accountability vào cryptographic accountability. Agent phải stake trước khi act — misbehavior = slash. Không đủ alone nhưng là complement quan trọng cho on-chain agent.

6. State of the Art — Ai Đang Làm Gì?

Anthropic — Model Card và Usage Policy

Anthropic publish model card chi tiết nhưng chưa có cơ chế cryptographic identity cho Claude. Accountability hiện tại là policy-based, không phải cryptographic.

OpenAI — Actions và GPTs

OpenAI Actions cho GPTs cho phép agent call external API — nhưng authentication là OAuth của user, không phải agent identity. Agent đang "mượn" identity của user.

W3C Verifiable Credentials cho Agents

Một số proposal đang circulate để dùng VC issue cho AI agent — ví dụ VC chứng nhận "agent này được train bởi organization X, với capability Y, với audit trail Z". Chưa có standard được adopt.

DID-COMM cho Agent Communication

DID-COMM là messaging protocol dùng DID để authenticate message sender. Phù hợp cho agent-to-agent communication cần verifiable sender identity. Đang được develop bởi DIF (Decentralized Identity Foundation).

🤖

📌 Key Takeaway

Standards 2025: W3C DID handle identifier ✓. W3C VC handle credential ✓. Còn thiếu: standardized delegation format và cross-framework interop. Đây là gap lớn nhất cần giải quyết trong 2025–2026.

7. So Sánh Các Agent Framework — Identity & Auth Model

Các agentic AI framework lớn hiện tại đang giải quyết bài toán identity theo những cách khác nhau — từ token-based đơn giản đến capability-based phức tạp:

Framework	Identity Model	Auth Mechanism	Delegation	Audit Trail
LangChain	Không native — dùng API key của user	API key passthrough	Không có	Cơ bản
AutoGen (Microsoft)	Agent object với tên + role	Azure AD / API key	Limited	Session log
CrewAI	Agent role + backstory	Tool-level auth	Role-based	Task log
Semantic Kernel	Plugin-based, user token	OAuth delegated	OAuth scope	OpenTelemetry
MCP (Anthropic)	Server DID / signed tools	Transport-layer auth	Server-scoped	Structured

Nhận xét: hầu hết framework hiện tại mượn identity của user — agent dùng API key hoặc OAuth token của người tạo nó, không có identity riêng. Đây là vấn đề accountability về dài hạn khi agent action ngày càng phức tạp và consequential hơn.

MCP — Model Context Protocol (Anthropic, 2024)

MCP là chuẩn mới được Anthropic giới thiệu để chuẩn hóa cách AI model connect với external tools và data sources. Từ góc độ identity, MCP server có thể expose DID-like identifier và signed tool descriptions — giúp model verify tool đến từ đúng source trước khi execute.

// MCP server manifest — có thể include identity claim
{
  "name": "payments-tool",
  "version": "1.0",
  "issuer": "did:web:payments.example.com",  ← server identity
  "capabilities": ["read_balance", "initiate_transfer"],
  "maxAmount": 1000000,  ← capability constraint
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:web:payments.example.com#key-1",
    "proofValue": "z..."  ← server ký manifest này
  }
}
// Agent verify signature trước khi trust tool
// Nếu fake MCP server inject → chữ ký không match → reject

🤖

📌 Key Takeaway

Framework comparison: LangChain/AutoGen mượn identity user. Semantic Kernel + MCP đang đi đúng hướng nhất. Chọn framework theo security model, không chỉ theo API convenience hay ecosystem size.

8. Case Study: Khi Agent Không Có Identity Rõ Ràng — Bài Học Thực Tế

Air Canada Chatbot (2024) — Accountability Failure

Năm 2024, Tòa án Canada phán quyết Air Canada phải chịu trách nhiệm về thông tin sai mà chatbot của họ cung cấp cho khách hàng về chính sách hoàn tiền. Air Canada lập luận chatbot là "thực thể riêng biệt" — tòa bác bỏ: operator chịu toàn bộ trách nhiệm về hành động của agent.

Đây là precedent pháp lý quan trọng: không có cơ chế nào để agent "escape" accountability về operator. Điều này reinforce nguyên tắc kỹ thuật — accountability chain phải luôn trace về human principal.

🔑

Bài học kỹ thuật: Mọi agent action cần signed attestation kèm theo: agent_id + principal_id + action + timestamp + capability_proof. Đây không chỉ là best practice — mà là requirement cho audit trail hợp lệ về mặt pháp lý.

Amazon Q trong AWS (2024)

Amazon Q Business dùng IAM role để scope agent capability — mỗi agent được assign IAM role với permission tối thiểu. Đây là "capability-based security" tương tự UCAN nhưng trong AWS ecosystem. Agent không thể access resource ngoài IAM role — enforced ở infrastructure level, không chỉ policy.

Google Agentspace (2025)

Google Agentspace dùng Google Workspace identity (OAuth) cho agent — agent "là" user trong Google context. Mọi action của agent tạo audit trail trong Google Workspace Admin Console với user_id của người authorize agent. Approach này đơn giản về identity nhưng không scale tốt khi agent cần delegate cho sub-agent.

🤖

📌 Key Takeaway

Air Canada precedent (2024): operator chịu toàn bộ trách nhiệm về agent action. Implication kỹ thuật: mọi agent action cần signed attestation với full audit trail ngay từ production deployment đầu tiên.

9. AI Agent Identity Tại Việt Nam — Góc Nhìn Thực Tế

Thị trường AI agent tại Việt Nam đang phát triển nhanh — đặc biệt trong fintech, banking và e-commerce. Tuy nhiên, hầu hết deployment hiện tại hoàn toàn bỏ qua bài toán identity:

Thực trạng hiện tại

Chatbot ngân hàng: VPBank NEO, Techcombank TADA, MB Bank — đều dùng API key hoặc session token của user, không có agent identity riêng. Accountability thuần túy là policy-based.
E-commerce automation: Tiki, Shopee VN — agent xử lý order, refund, support bằng service account chung. Không có per-agent audit trail.
Legal risk đang tăng: Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân yêu cầu accountability rõ ràng cho automated processing — agent identity trở thành vấn đề compliance, không chỉ là technical choice.

Bước thực tế cho team Việt Nam

Với team muốn implement agent identity đúng cách ngay hôm nay, không cần chờ standard hoàn chỉnh:

Assign mỗi agent type một keypair + metadata JSON (name, version, capabilities, principal)
Log mọi action với agent_signature(action + timestamp + context)
Implement capability whitelist — agent chỉ được gọi tools trong whitelist
Human approval cho high-stakes action (transfer tiền, gửi email ra ngoài, xóa data)
Rotation keypair theo sprint cycle (2–4 tuần) để giới hạn exposure window

Về nền tảng cryptographic cho agent identity — DID làm foundation — xem bài DID là gì. Về kiến trúc tổng thể danh tính phi tập trung, xem bài nghiên cứu chính tại WLD.VN.

🤖

📌 Key Takeaway

Việt Nam 2025: chưa có legal framework cho AI agent identity. Nhưng kỹ thuật có thể implement ngay — DID + VC + audit log cho agent. Chuẩn bị technical foundation trước khi regulation đến.

Câu hỏi thường gặp

AI agent có thể có danh tính thật sự không?

Kỹ thuật có: agent có thể có DID, keypair, và có thể ký action. Nhưng 'danh tính' theo nghĩa pháp lý — khả năng ký hợp đồng, chịu trách nhiệm pháp lý, có quyền — thì chưa. Accountability luôn phải map về human principal hoặc tổ chức. Về mặt kỹ thuật, agent có cryptographic identity. Về mặt pháp lý, đó là extended identity của chủ sở hữu agent.

Làm sao biết email hay message đến từ AI agent hay con người?

Hiện tại rất khó nếu không có explicit labeling. Về mặt kỹ thuật, nếu agent dùng DID-signed message, recipient có thể verify signature và check DID Document để biết sender là agent hay human. Nhưng hầu hết messaging system hiện tại không enforce điều này. DKIM signature trong email xác nhận domain, không phải human vs AI. Đây là gap lớn trong infrastructure hiện tại.

UCAN và OAuth khác nhau thế nào cho agent delegation?

OAuth: user grant permission cho application — centralized authorization server đứng giữa, token không transferable. UCAN: user tạo capability token có thể chain delegate — không cần central server, agent có thể sub-delegate (trong scope cho phép), capability explicit và verifiable. UCAN phù hợp hơn cho decentralized multi-agent system. OAuth phù hợp hơn khi đã có centralized IdP và Web2 ecosystem.

Agent identity có cần blockchain không?

Không nhất thiết. did:key không cần blockchain — DID Document derive từ public key. UCAN chạy trên JWT, không cần blockchain. Blockchain hữu ích khi cần: public registry of agent DIDs, on-chain revocation, hay tie agent identity với on-chain asset. Nhưng cho internal enterprise use case, off-chain DID + UCAN là đủ và đơn giản hơn nhiều.

Multi-agent system nên thiết kế identity thế nào?

Best practice: (1) Mỗi agent instance có unique DID ephemeral — không reuse key. (2) Delegation chain explicit từ human root đến agent leaf qua UCAN hoặc similar. (3) Mọi action được signed và logged với timestamp. (4) Short-lived capability token — agent không hold long-lived credential. (5) Revocation mechanism rõ ràng — human có thể disable agent bất kỳ lúc nào. (6) Capability scope tối thiểu — principle of least privilege áp dụng cho agent cũng như người dùng.

Tài liệu tham khảo

DIF. DID-COMM Messaging v2. identity.foundation/didcomm-messaging/spec/.
Fission. UCAN — User Controlled Authorization Networks. ucan.xyz.
W3C. Decentralized Identifiers (DIDs) v1.0. w3.org/TR/did-core/.
Tobin, A. & Reed, D. The Inevitable Rise of Self-Sovereign Identity. Sovrin Foundation. 2016.
ZRO Research. AI & Identity Research Hub. zro.vn/wld-vn/.