Blog / Series AI Agents Thực Chiến

AI Agent Identity 2026: sau MCP, bài toán nóng nhất là danh tính, ủy quyền và trách nhiệm của agent

Vấn đề gốc: vì sao agent càng hữu ích thì câu hỏi danh tính càng trở nên cấp bách

Ở giai đoạn chatbot, câu hỏi lớn nhất thường là model có trả lời đúng hay không. Nhưng khi bước sang agent, câu hỏi đó không còn đủ. Một agent hữu ích phải chạm vào thế giới thực: lấy dữ liệu từ hệ thống nội bộ, đọc trạng thái hiện tại, gọi API, chỉnh cấu hình, gửi đề xuất, đôi khi còn khởi tạo hành động có hậu quả thật.

Ngay khoảnh khắc đó, hệ thống va vào ba áp lực cùng lúc.

Thứ nhất là áp lực bảo mật. Không thể để mọi agent cùng dùng một tài khoản quyền rộng rồi hy vọng log là đủ. Bài Agent Security 2026 đã nói về prompt injection và tool abuse; agent identity là phần biến các cảnh báo đó thành biên giới kỹ thuật cụ thể.

Thứ hai là áp lực vận hành. Nếu một agent tạo nhầm lệnh hoàn tiền, merge nhầm pull request, hay đẩy sai thay đổi hạ tầng, đội ngũ cần biết ai đã ủy quyền cho hành động đó, token nào được dùng, policy nào đã cho phép và vì sao hệ thống không chặn lại.

Thứ ba là áp lực quản trị. Doanh nghiệp không chỉ hỏi “agent làm được gì?” mà bắt đầu hỏi “agent có được xem như một thực thể vận hành có danh tính hay không?”. Khi số lượng agent tăng lên, không có lớp danh tính thì mọi thứ nhanh chóng trượt thành một mớ service account khó kiểm soát.

Tín hiệu thị trường gần đây phản ánh đúng điểm đau này. Các bài viết và công bố mới nhấn mạnh rằng cuộc chơi 2026 đang dịch từ model sang systems; đồng thời tại RSAC 2026, agent identity, passwordless cho non-human identities và mô hình human-in-the-loop authorization xuất hiện như một chủ đề riêng, không còn bị hòa tan trong “AI security” chung chung.

Agent identity là gì, và nó khác API key dịch vụ truyền thống ở đâu?

Agent identity là cách hệ thống biểu diễn một agent như một thực thể có thể xác thực, được ủy quyền, bị giới hạn phạm vi hành động và có thể bị audit sau này. Nó không chỉ là một token bí mật để gọi API.

Nhiều đội ngũ vẫn xử lý agent như một script tự động kiểu cũ: gán cho nó một API key hoặc một service account rồi để nó làm việc. Cách này có thể chạy được trong bản demo đầu tiên, nhưng sẽ vỡ rất nhanh khi agent bắt đầu:

• hành động thay mặt cho nhiều người dùng khác nhau,
• nhảy qua nhiều tool và nhiều hệ thống,
• gọi hành động có mức rủi ro khác nhau,
• tự lập kế hoạch nhiều bước và thay đổi quyết định giữa chừng.

API key dịch vụ truyền thống thường trả lời câu hỏi: ứng dụng nào đang gọi? Agent identity phải trả lời đồng thời nhiều lớp hơn:

1. Agent nào đang chạy?
2. Phiên thực thi nào đang hành động?
3. Thay mặt ai hoặc dưới chính sách nào?
4. Hành động này có cần phê duyệt thêm không?
5. Có thể chứng minh lại sau này không?

Nói ngắn gọn, service account nói về quyền truy cập; agent identity nói về danh tính, ngữ cảnh ủy quyền và chuỗi trách nhiệm. Đây là chỗ nó giao nhau với workflow, memory và approval. Vì một agent không chỉ cần được quyền truy cập, nó còn cần biết khi nào phải dừng để xin quyền hành động.

Bốn lớp tối thiểu của agent identity trưởng thành

• Authentication: hệ thống biết agent này thực sự là agent nào.
• Delegation: agent đang hành động với quyền gốc của chính nó hay quyền được ủy thác từ một con người/hệ thống khác.
• Authorization: hành động cụ thể này có được phép ở thời điểm cụ thể này hay không.
• Accountability: sau khi chạy xong, có thể tái dựng lại toàn bộ đường đi quyết định hay không.

Nếu thiếu lớp thứ tư, rất nhiều hệ thống tưởng mình “an toàn” nhưng thực chất chỉ là khó điều tra khi có sự cố.

Use case end-to-end: agent xử lý chi tiêu và triển khai thay đổi trong doanh nghiệp

Hãy bỏ qua các ví dụ quá sạch kiểu “tóm tắt tài liệu”. Một use case thực tế hơn là một doanh nghiệp triển khai hai agent nội bộ:

1. một agent tài chính đọc yêu cầu chi tiêu, đối chiếu chính sách, chuẩn bị hồ sơ thanh toán và đề xuất hoàn tiền;
2. một agent kỹ thuật đọc ticket sự cố, chuẩn bị thay đổi cấu hình hoặc pull request, rồi đề xuất rollout.

Cả hai agent đều hữu ích. Và cả hai đều nguy hiểm nếu không có identity đúng nghĩa.

Pha 1: nhận yêu cầu và xác định chủ thể gốc

Một nhân sự gửi yêu cầu mua phần mềm hoặc một kỹ sư yêu cầu rollout hotfix. Agent cần biết ai là người khởi tạo, phòng ban nào liên quan, mức nhạy cảm của tác vụ là gì. Nếu không có lớp danh tính gốc, agent chỉ nhìn thấy một đoạn text và dễ đẩy sai workflow.

Pha 2: truy cập dữ liệu bằng quyền phù hợp

Agent tài chính có thể cần đọc chính sách mua sắm, lịch sử vendor, hạn mức phòng ban. Agent kỹ thuật có thể cần đọc runbook, CI logs, config trước đó. Không phải mọi dữ liệu mà người dùng khởi tạo có quyền xem đều nên được agent lấy toàn bộ. Agent cần scope riêng và chỉ được đọc phần cần cho tác vụ.

Pha 3: lập kế hoạch nhưng chưa được xem là đã có quyền hành động

Đây là điểm nhiều đội ngũ bỏ qua. Việc agent đề xuất một hành động không đồng nghĩa agent được phép thực hiện hành động đó. Một agent tốt có thể tự soạn phương án hoàn tiền hoặc rollout. Nhưng đến ngưỡng rủi ro cao, quyền phải chuyển sang mô hình verified approval: ai duyệt, duyệt qua cơ chế nào, có bằng chứng xác thực nào gắn với quyết định đó.

Pha 4: thực thi bằng credential tạm thời, gắn chặt với policy

Sau khi được duyệt, hệ thống nên cấp một credential ngắn hạn hoặc một capability token chỉ đủ để agent thực hiện đúng hành động đã được chấp thuận. Đây là khác biệt lớn giữa kiến trúc nghiêm túc và kiểu “bấm duyệt xong thì agent dùng luôn tài khoản quyền rộng”.

Pha 5: audit và điều tra sau hành động

Nếu agent hoàn tiền sai hoặc rollout gây sự cố, log phải trả lời được tối thiểu các câu hỏi sau:

• ai khởi tạo tác vụ,
• agent nào xử lý,
• đã đọc dữ liệu nào,
• đã yêu cầu phê duyệt ở bước nào,
• ai phê duyệt, bằng cơ chế gì,
• credential nào được dùng để thực thi,
• chính sách nào cho phép hoặc chặn hành động.

Nếu một mắt xích trong chuỗi trên bị mất, doanh nghiệp không còn một hệ agent mà đang nuôi một vùng mù rất đắt đỏ.

Kiến trúc hệ thống: identity, delegation, approval và audit nên nằm ở đâu?

Kiến trúc agent identity không nên bị nhét vào prompt hoặc vài rule hậu kiểm. Nó phải là một lớp điều hành đứng song song với orchestration. Một mô hình tối thiểu thường có sáu phần.

1. Agent registry

Mỗi agent cần một hồ sơ danh tính riêng: mục đích, owner, môi trường được phép chạy, nhóm tool được phép dùng, mức dữ liệu được chạm tới, ngân sách và ngưỡng escalation. Nếu không có registry, việc cấp quyền cho agent thường diễn ra bằng tay và trôi dần khỏi kiểm soát.

2. Execution identity

Mỗi phiên chạy cần một execution ID và tốt hơn nữa là credential ngắn hạn riêng. Điều này cho phép phân biệt “agent A nói chung” với “lần chạy cụ thể số 8473 của agent A”. Trong điều tra sự cố, khác biệt này cực kỳ quan trọng.

3. Delegation layer

Khi agent hành động thay mặt cho một người dùng hoặc một nhóm chức năng, hệ thống cần biểu diễn rõ mối quan hệ ủy thác đó. Quyền của agent không nên mặc định bằng quyền rộng nhất của người dùng. Thay vào đó, nên tạo ra một tập quyền thu gọn theo tác vụ và theo thời gian.

4. Policy + approval engine

Lớp này quyết định hành động nào agent được tự làm, hành động nào phải dừng để xin duyệt. Đây là nơi nối kỹ thuật với quản trị. Một số thao tác có thể tự động hoàn toàn; một số thao tác chỉ được chạy khi có human-in-the-loop; một số thao tác phải bị cấm tuyệt đối dù agent đề xuất hợp lý đến đâu.

Về mặt thực thi, đây cũng là chỗ cần gắn chặt với độ tin cậy của agent. Hệ thống không thể đánh đồng “agent tự tin” với “hệ thống cho phép”.

5. Tokenization theo capability thay vì credential quyền rộng

Mỗi hành động quan trọng nên đi qua token ngắn hạn hoặc một capability cụ thể: ví dụ chỉ được tạo draft hoàn tiền dưới 20 triệu, chỉ được tạo PR chứ không được merge, chỉ được đọc bản config của một dịch vụ cụ thể. Cách này phức tạp hơn lúc đầu, nhưng giảm bán kính nổ khi agent bị prompt injection hoặc route sai.

6. Audit graph

Không chỉ ghi log text. Hệ thống nên lưu đồ thị quan hệ giữa request ban đầu, agent, tool calls, approvals, policy decisions và action outcomes. Khi số lượng agent tăng mạnh, audit graph trở thành lớp giúp tổ chức truy ra nguyên nhân thay vì chỉ nhìn thấy một chuỗi log rời rạc.

Trade-off và failure mode mà nhiều đội ngũ đánh giá quá nhẹ

Agent identity là hướng đi đúng, nhưng không phải bật lên là xong. Nó mang theo chi phí kiến trúc và nhiều failure mode riêng.

1. Càng chi tiết càng dễ phức tạp hóa vận hành

Nếu policy quá mịn ngay từ đầu, đội ngũ có thể tự xây một mê cung quyền hạn khiến agent liên tục bị chặn vì lý do khó giải thích. Giải pháp không phải bỏ identity, mà là rollout theo cấp độ rủi ro thay vì cố hoàn hảo từ ngày đầu.

2. Human-in-the-loop có thể trở thành nút thắt

Nhiều tổ chức tuyên bố sẽ “luôn có người duyệt”, nhưng nếu mọi hành động đều đổ về một nhóm duyệt trung tâm, agent sẽ làm tăng backlog chứ không giảm. Bài toán thật là chỉ đưa con người vào đúng những bước có rủi ro xứng đáng.

3. Delegation mơ hồ tạo ra lỗ hổng trách nhiệm

Failure mode phổ biến là agent dùng quyền của một service account chung, nhưng trên giao diện lại hiển thị như đang “làm thay cho người dùng”. Điều này tạo cảm giác kiểm soát giả: nhìn thì có vẻ có owner, nhưng khi xảy ra lỗi lại không chứng minh được quan hệ ủy quyền thực sự.

4. Scope creep từ tool layer

Nhiều hệ bắt đầu rất chặt, nhưng rồi từng tool được nới scope dần cho tiện triển khai. Sau vài tháng, agent quay về trạng thái “gần như toàn quyền” mà không ai để ý. Đây là lúc workflow engine và audit định kỳ phải vào cuộc.

5. Đồng nhất identity với compliance là một sai lầm

Có agent identity không đồng nghĩa hệ thống đã compliant. Nó chỉ tạo nền để compliance có chỗ bám. Nếu policy, retention, data residency và quy trình duyệt không được thiết kế cùng nhau, identity chỉ là một vỏ đẹp bên ngoài.

6. Failure mode thực tế cần canh ngay từ đầu

• Shared credential syndrome: nhiều agent dùng chung một credential mạnh.
• Approval theater: có nút duyệt nhưng không gắn bằng chứng xác thực mạnh hoặc không ràng buộc với hành động cụ thể.
• Broken delegation chain: không tái dựng được agent đang thay mặt ai ở bước hành động cuối.
• Invisible privilege expansion: tool hoặc connector được mở scope dần theo nhu cầu tình huống.
• Audit gap: lưu output cuối nhưng không lưu policy decision và tool path.
• Latency drag: mỗi bước xác thực/phê duyệt thêm làm agent chậm đến mức người dùng lách quy trình.

Checklist triển khai production

Nếu đội ngũ đang cân nhắc đưa agent identity vào hệ vận hành, checklist dưới đây thực tế hơn việc cố triển khai “zero trust cho agent” trong một đợt duy nhất.

Giai đoạn 1: phân loại hành động theo mức rủi ro

• Tách rõ hành động đọc, soạn thảo, đề xuất, thực thi.
• Gắn mỗi nhóm với mức dữ liệu, tác động tài chính và tác động hạ tầng.
• Đừng bắt đầu từ câu hỏi “agent cần quyền gì”, hãy bắt đầu từ câu hỏi “hành động nào bắt buộc phải có bằng chứng ủy quyền”.

Giai đoạn 2: tạo registry cho từng agent

• Mỗi agent phải có owner, mục đích, môi trường, tool whitelist và giới hạn ngân sách.
• Không cho phép agent “thử nghiệm” dùng thẳng credential production vô thời hạn.
• Áp dụng TTL ngắn cho credential thực thi ngay từ sớm.

Giai đoạn 3: tách planning khỏi execution

• Cho agent lập kế hoạch và chuẩn bị draft trước.
• Chỉ cấp capability token khi hệ thống đã xác minh đúng policy và đúng bước phê duyệt.
• Với hành động nhạy cảm, yêu cầu approval có tính ràng buộc mật mã hoặc ít nhất là identity assurance mạnh hơn nút bấm thường.

Giai đoạn 4: đo và review theo đường đi ủy quyền

• Đo tỷ lệ hành động phải escalate, tỷ lệ bị policy chặn, tỷ lệ approval timeout.
• Review định kỳ các action bị từ chối nhiều nhất để sửa policy hoặc UX.
• Kiểm tra ngược: một hành động bất kỳ có truy được đầy đủ chuỗi khởi tạo → duyệt → thực thi hay không.

Giai đoạn 5: chỉ tự động hóa sâu khi identity path đã ổn định

• Đừng cho agent auto-execute hành động nhạy cảm chỉ vì benchmark reasoning đẹp.
• Kết hợp identity với model routing để workload rủi ro cao đi vào tuyến kiểm soát chặt hơn.
• Định kỳ thu hẹp scope thay vì chỉ mở rộng scope.

Insight cuối cùng: nếu không có identity, agent không phải “đồng nghiệp số” mà chỉ là quyền lực vô chủ

Thị trường đang thích nói về AI agent như “digital worker”. Cụm từ này nghe hấp dẫn, nhưng nó chỉ có ý nghĩa khi đi kèm một thuộc tính rất con người trong vận hành doanh nghiệp: danh tính gắn với trách nhiệm.

Một nhân sự thật có tên, vai trò, phạm vi quyền hạn, người quản lý và lịch sử hành động. Nếu agent được phép chạm vào hệ thống thật nhưng không có những thuộc tính tương đương ở tầng kỹ thuật, tổ chức không hề có “digital worker”. Tổ chức chỉ có một cơ chế tự động mạnh nhưng mơ hồ.

Đó là lý do agent identity đang trở thành chủ đề nóng sau làn sóng MCP và tool calling. Khi kết nối đã trở nên dễ hơn, điểm nghẽn tự nhiên chuyển sang ủy quyền và accountability. Thị trường không còn thiếu agent biết làm. Thị trường bắt đầu thiếu agent có thể được tin để làm trong ranh giới rõ ràng.

Nói cách khác, chặng tiếp theo của AI agent không phải chỉ là thông minh hơn. Nó là được nhận diện đúng, được giao quyền đúng và bị buộc trách nhiệm đúng. Ai xây được lớp này sớm sẽ có lợi thế hệ thống bền hơn rất nhiều so với việc chỉ chạy theo model mới nhất.