Câu trả lời ngắn: phân quyền AI Agent là gì?
Phân quyền AI Agent là việc xác định rõ mỗi Agent được đọc dữ liệu nào, được dùng công cụ nào, được tự làm hành động nào và hành động nào phải chờ người phê duyệt. Nhật ký kiểm toán là bản ghi cho phép trả lời sau này: Agent nào, nhân danh ai, đã làm gì, lúc nào, dựa trên dữ liệu gì và ai đã duyệt.
Hai thứ này cần đi cùng nhau. Phân quyền giới hạn thiệt hại khi Agent hiểu sai yêu cầu hoặc bị thao túng; nhật ký giúp phát hiện, điều tra và chứng minh với khách hàng, đối tác hay cơ quan quản lý rằng con người vẫn kiểm soát hệ thống.
Bài viết dành cho người phụ trách vận hành, CNTT và pháp chế ở doanh nghiệp đang đưa AI Agent vào quy trình thật, dựa trên hướng dẫn công khai của OWASP, NIST và các quy định liên quan trong Luật Trí tuệ nhân tạo 2025, Luật Bảo vệ dữ liệu cá nhân 2025.
Vì sao AI Agent cần cách phân quyền riêng
Chatbot chỉ trả lời bằng văn bản. AI Agent thì gọi công cụ: tra CRM, sửa đơn hàng, gửi tin nhắn, tạo tài khoản. Khi đã có quyền hành động, một câu trả lời sai có thể trở thành một thao tác sai trên dữ liệu thật.
OWASP Top 10 cho ứng dụng LLM (bản 2025) gọi rủi ro này là Excessive Agency (LLM06): hệ thống thực hiện hành động gây hại vì đầu ra bất thường, mơ hồ hoặc bị thao túng của mô hình. Ba gốc rễ thường gặp:
Nguyên nhân có thể là câu lệnh viết chưa tốt, mô hình yếu, hoặc nội dung độc hại cài trong email, tài liệu mà Agent đọc (xem Prompt injection là gì). Không thể loại bỏ hết các nguyên nhân này, nên cách thực tế là thu hẹp những gì Agent làm được khi nó sai.
- Quá nhiều chức năng: chỉ cần đọc email để tóm tắt nhưng công cụ có cả quyền gửi và xóa thư.
- Quá nhiều quyền: chỉ cần đọc bảng sản phẩm nhưng tài khoản kết nối được sửa, xóa mọi bảng.
- Quá nhiều quyền tự quyết: Agent tự xóa tài liệu hoặc đăng nội dung mà không hỏi lại người dùng.
Bước 1: cấp danh tính riêng cho từng AI Agent
Sai lầm phổ biến là cho Agent dùng chung tài khoản của một nhân viên hoặc tài khoản quản trị chung. Khi đó nhật ký chỉ ghi “tài khoản X đã sửa đơn hàng”, không phân biệt được người hay Agent đã làm, và không thể thu hồi quyền của Agent mà không ảnh hưởng đến người.
OWASP khuyến nghị theo dõi phạm vi quyền của người dùng để hành động mà Agent làm thay một người được thực hiện trong đúng ngữ cảnh của người đó, với quyền tối thiểu cần thiết, thay vì dùng một danh tính chung có quyền cao.
Tài khoản dịch vụ (service account) cho Agent
Mỗi Agent nên có một tài khoản dịch vụ riêng, đặt tên theo vai trò (ví dụ: agent-tiep-nhan-don, agent-doi-soat-hoa-don), có người chủ sở hữu nghiệp vụ và người chủ sở hữu kỹ thuật được ghi rõ.
- Đăng ký Agent trong một danh mục: tên, mục đích, quy trình phục vụ, hệ thống được truy cập, mức quyền, người phụ trách, trạng thái (đang chạy, tạm dừng, ngừng).
- Khóa hoặc thu hồi được tài khoản Agent ngay lập tức mà không ảnh hưởng tài khoản người dùng.
- Rà soát quyền định kỳ như với nhân viên: quyền không còn dùng thì gỡ.
Khi Agent làm việc thay một người cụ thể
Nếu Agent đọc hộp thư hay tài liệu của một nhân viên, hãy để nhân viên đó ủy quyền qua cơ chế đăng nhập chuẩn với phạm vi hẹp nhất (OWASP lấy ví dụ OAuth với phạm vi tối thiểu). Nhật ký nên ghi cả hai: Agent nào thực hiện và nhân danh người dùng nào.
Bước 2: chọn mô hình phân quyền, RBAC hay ABAC
RBAC (phân quyền theo vai trò) gán quyền cho vai trò, rồi gán vai trò cho người hoặc Agent. Đây là cách hầu hết phần mềm doanh nghiệp đang dùng và dễ hiểu với bộ phận nghiệp vụ.
ABAC (phân quyền theo thuộc tính) được NIST định nghĩa trong SP 800-162 là phương pháp quyết định quyền bằng cách đánh giá thuộc tính của chủ thể, đối tượng, thao tác được yêu cầu và trong một số trường hợp là điều kiện môi trường, so với chính sách hoặc quy tắc. Với AI Agent, ABAC hữu ích khi quyền phụ thuộc vào ngữ cảnh: số tiền, chi nhánh, mức nhạy cảm của dữ liệu, giờ làm việc.
Trong thực tế, nhiều doanh nghiệp kết hợp: RBAC xác định Agent thuộc vai trò nào, ABAC thêm điều kiện cho những thao tác nhạy cảm.
| Tiêu chí | RBAC (theo vai trò) | ABAC (theo thuộc tính) |
|---|---|---|
| Cách quyết định quyền | Agent có vai trò nào thì có quyền của vai trò đó | Đánh giá thuộc tính của Agent, dữ liệu, thao tác và bối cảnh theo chính sách |
| Ví dụ minh họa | Vai trò “Hỗ trợ khách hàng” được đọc đơn hàng, tạo phiếu hỗ trợ | Được hoàn tiền nếu số tiền dưới ngưỡng, đúng chi nhánh, trong giờ làm việc |
| Điểm mạnh | Dễ hiểu, dễ rà soát, có sẵn trong nhiều phần mềm | Linh hoạt, kiểm soát chi tiết theo ngữ cảnh |
| Điểm yếu | Dễ phình số vai trò, khó diễn đạt điều kiện như hạn mức | Cần dữ liệu thuộc tính chính xác và chính sách được quản lý tốt |
| Phù hợp khi | Agent làm việc ổn định, phạm vi rõ | Quyền phụ thuộc số tiền, mức nhạy cảm, địa điểm, thời gian |
Bước 3: token phạm vi hẹp và kiểm tra quyền ở hệ thống đích
Token hay khóa API mà Agent dùng chính là quyền của Agent. Nếu token có quyền đọc toàn bộ CRM, Agent về mặt kỹ thuật có thể xuất toàn bộ CRM, dù câu lệnh hệ thống dặn không được làm vậy.
OWASP nhấn mạnh: chỉ cấp cho Agent những công cụ thực sự cần, và kiểm tra quyền ở hệ thống phía sau thay vì để mô hình tự quyết định hành động có được phép hay không.
- Tách quyền theo động từ: đọc, soạn nháp, ghi, gửi ra ngoài, xóa. Agent tóm tắt chỉ cần đọc.
- Ưu tiên công cụ hẹp như “tạo phiếu hỗ trợ” thay vì công cụ mở như “chạy lệnh tùy ý” hoặc “gọi URL bất kỳ”.
- Dùng token có thời hạn ngắn, cấp cho từng tác vụ khi có thể, và thu hồi khi tác vụ kết thúc.
- Không đặt khóa API trong câu lệnh hay tài liệu mà Agent đọc; lưu trong kho bí mật của hạ tầng.
- Đặt giới hạn tần suất cho các công cụ có tác động (gửi tin, sửa dữ liệu) để giảm thiệt hại nếu Agent chạy sai hàng loạt.
Bước 4: điểm phê duyệt cho hành động không thể hoàn tác
OWASP khuyến nghị dùng cơ chế con người trong vòng lặp để yêu cầu người phê duyệt các hành động có tác động lớn trước khi thực hiện. Điểm phê duyệt nên được cài trong chính công cụ thực thi (ví dụ: công cụ “đăng bài” luôn chờ người bấm duyệt), không chỉ là một dòng nhắc trong câu lệnh.
Luật Trí tuệ nhân tạo số 134/2025/QH15, có hiệu lực từ 01/3/2026, tại khoản 2 Điều 4 đặt nguyên tắc AI phục vụ con người, không thay thế thẩm quyền và trách nhiệm của con người, và phải duy trì sự kiểm soát, khả năng can thiệp của con người đối với quyết định và hành vi của hệ thống AI. Khoản 4 Điều 7 của Luật cấm hành vi cản trở, vô hiệu hóa hoặc làm sai lệch cơ chế giám sát, can thiệp và kiểm soát của con người. Xem phân tích chi tiết trong bài Luật Trí tuệ nhân tạo 2025.
Người duyệt cần thấy đủ thông tin để quyết định: yêu cầu ban đầu, dữ liệu Agent đã dùng, hành động dự kiến và phần còn chưa chắc chắn. Một nút “Đồng ý” đứng một mình dễ biến phê duyệt thành thủ tục. Cách thiết kế điểm duyệt được trình bày kỹ hơn trong bài Human-in-the-loop.
| Mức | Ví dụ hành động | Cách kiểm soát gợi ý |
|---|---|---|
| Tự làm | Đọc, tóm tắt, phân loại, soạn nháp nội bộ | Ghi nhật ký; rà soát mẫu định kỳ |
| Làm rồi báo | Tạo phiếu hỗ trợ, cập nhật trạng thái nội bộ có thể sửa lại | Ghi nhật ký; cho phép hoàn tác; cảnh báo khi bất thường |
| Phải duyệt trước | Gửi thông tin cho khách hàng, hoàn tiền, đổi quyền tài khoản, xóa dữ liệu, ký hoặc chốt hợp đồng | Dừng chờ người có thẩm quyền; ghi ai duyệt, lúc nào, với nội dung gì |
| Không cho phép | Thay đổi chính quyền hạn của Agent, tắt nhật ký, chuyển tiền ra ngoài hạn mức | Không cấp công cụ; hệ thống đích từ chối |
Bước 5: nhật ký kiểm toán cần ghi những gì
Hướng dẫn phát triển của OWASP yêu cầu mỗi bản ghi có đủ siêu dữ liệu (khi nào, ở đâu, ai, làm gì) để điều tra được dòng thời gian của sự kiện, gồm thời điểm, mức độ, danh tính tài khoản, mã truy vết, kết quả và mô tả sự kiện. Với AI Agent, cần bổ sung thông tin về công cụ được gọi và việc phê duyệt.
Ghi bao nhiêu nội dung là quyết định cân bằng. OWASP lưu ý không nên ghi quá nhiều hay quá ít, và tài liệu từ vựng ghi log của OWASP khuyên tránh ghi toàn văn câu lệnh và đầu vào, đầu ra của công cụ, ưu tiên ghi lượng sử dụng, ngưỡng chính sách, mã yêu cầu và công cụ, mô hình liên quan. Nếu cần lưu nội dung để điều tra, hãy che bớt dữ liệu cá nhân và đặt thời hạn lưu ngắn hơn phần siêu dữ liệu.
| Nhóm | Trường | Ghi chú |
|---|---|---|
| Ai | Mã Agent, phiên bản cấu hình hoặc câu lệnh hệ thống, người dùng mà Agent làm thay | Phân biệt Agent với người; biết phiên bản nào đang chạy khi lỗi xảy ra |
| Cái gì | Tên hành động, đối tượng bị tác động (mã đơn, mã khách hàng) | Dùng mã thay vì tên, số điện thoại khi có thể |
| Khi nào | Dấu thời gian có múi giờ, mã truy vết nối các bước của một tác vụ | Đồng bộ đồng hồ giữa các hệ thống |
| Đầu vào | Mã yêu cầu, nguồn dữ liệu đã đọc, bản tóm tắt hoặc giá trị băm của đầu vào | Tránh ghi toàn văn nếu chứa dữ liệu cá nhân |
| Lần gọi công cụ | Tên công cụ, tham số chính, kết quả trả về (thành công, thất bại, bị từ chối) | Ghi cả các lần bị hệ thống đích từ chối quyền |
| Đầu ra | Kết quả cuối, thay đổi dữ liệu (trước và sau) | Đủ để hoàn tác nếu cần |
| Phê duyệt | Người duyệt, thời điểm, quyết định, lý do nếu từ chối | Bằng chứng cho nguyên tắc con người kiểm soát |
| Mô hình | Tên và phiên bản mô hình, lượng token | Hữu ích khi điều tra lỗi và kiểm soát chi phí |
Thời hạn lưu nhật ký và dữ liệu cá nhân
Nhật ký của AI Agent gần như chắc chắn chứa dữ liệu cá nhân như tên khách hàng, nội dung tin nhắn, mã nhân viên. OWASP lưu ý nhật ký vì vậy phải được bảo vệ khỏi truy cập, sửa và xóa trái phép.
Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, có hiệu lực từ 01/01/2026 (cùng Nghị định 356/2025/NĐ-CP quy định chi tiết, thay thế Nghị định 13/2023/NĐ-CP), quy định tại khoản 3 Điều 3 rằng dữ liệu cá nhân được lưu trữ trong khoảng thời gian phù hợp với mục đích xử lý, trừ trường hợp pháp luật có quy định khác. Điều 14 liệt kê các trường hợp xóa, hủy dữ liệu cá nhân, trong đó có khi đã hoàn thành mục đích xử lý và khi hết thời hạn lưu trữ theo quy định. Xem checklist đầy đủ trong bài Luật Bảo vệ dữ liệu cá nhân 2025.
Nói cách khác, doanh nghiệp cần chính sách lưu giữ có lý do, không phải “giữ mãi cho chắc”.
- Xác định mục đích của từng loại nhật ký: điều tra sự cố, đối soát nghiệp vụ, chứng minh phê duyệt.
- Đặt thời hạn lưu riêng cho phần siêu dữ liệu và phần nội dung chi tiết; phần chứa dữ liệu cá nhân nên ngắn hơn, trừ khi luật chuyên ngành yêu cầu giữ lâu hơn.
- Che hoặc mã hóa trường nhạy cảm; giới hạn ai được xem nhật ký đầy đủ.
- Khi hết hạn, xóa theo quy trình có ghi nhận, kể cả trong bản sao lưu theo chu kỳ xoay vòng.
Chống sửa nhật ký, giải thích dễ hiểu
Nhật ký chỉ có giá trị khi người đọc tin rằng nó không bị sửa sau sự việc. OWASP Top 10:2025 khuyến nghị dấu vết kiểm toán có cơ chế chống sửa hoặc xóa, ví dụ bảng cơ sở dữ liệu chỉ cho phép ghi thêm.
Hãy hình dung nhật ký như cuốn sổ đóng gáy, đánh số trang: viết thêm trang mới thì được, nhưng xé hay sửa trang cũ sẽ để lại dấu vết. Các cách kỹ thuật thường dùng:
- Chỉ ghi thêm: tài khoản ứng dụng và tài khoản Agent không có quyền sửa hay xóa bản ghi cũ.
- Nối chuỗi dấu vân tay: mỗi bản ghi chứa giá trị băm (một dạng dấu vân tay số) của bản ghi trước. Sửa một bản ghi cũ sẽ làm chuỗi phía sau không khớp, nên phát hiện được.
- Lưu tách biệt: gửi nhật ký sang kho lưu trữ riêng mà người quản trị hệ thống ứng dụng không tự xóa được.
- Cảnh báo khi nhật ký ngừng ghi: OWASP khuyến nghị có quy trình phát hiện việc ghi log bị dừng và việc truy cập, xóa trái phép.
- Agent không bao giờ được cấp công cụ để đọc toàn bộ hoặc sửa nhật ký của chính nó.
Checklist triển khai và cách EYC làm việc
Không cần mua một nền tảng lớn để bắt đầu. Phần lớn các bước dưới đây làm được với hệ thống quản lý danh tính, cơ sở dữ liệu và kho log mà doanh nghiệp đang có.
- Lập danh mục AI Agent: mục đích, chủ sở hữu, hệ thống truy cập, mức quyền.
- Mỗi Agent một tài khoản dịch vụ riêng; không dùng chung tài khoản người.
- Chọn RBAC cho vai trò, thêm điều kiện ABAC cho thao tác có hạn mức.
- Token phạm vi hẹp, thời hạn ngắn; quyền được kiểm tra ở hệ thống đích.
- Phân tầng hành động; cài điểm phê duyệt trong công cụ cho hành động không thể hoàn tác.
- Nhật ký đủ trường ai, cái gì, khi nào, đầu vào, đầu ra, công cụ, phê duyệt.
- Chính sách lưu giữ theo mục đích; che dữ liệu cá nhân.
- Nhật ký chỉ ghi thêm, lưu tách biệt, có cảnh báo khi ngừng ghi.
- Rà soát quyền và diễn tập thu hồi quyền Agent định kỳ.
EYC áp dụng những gì
EYC vận hành các quy trình nội bộ về kiểm soát truy cập, ghi nhật ký kiểm toán, sao lưu và ứng phó sự cố. Khi xây dựng giải pháp AI & Tự động hóa cho khách hàng, chúng tôi thiết kế danh tính riêng cho Agent, công cụ có phạm vi hẹp, điểm phê duyệt cho hành động quan trọng và nhật ký có thể rà soát. Thời hạn lưu nhật ký, mức hỗ trợ và các cam kết vận hành khác được quy định theo thỏa thuận trong hợp đồng của từng dự án.
Câu hỏi thường gặp
AI Agent có nên dùng chung tài khoản với nhân viên không?
Không nên. Dùng chung khiến nhật ký không phân biệt được người hay Agent đã thao tác, và không thể thu hồi quyền của Agent mà không ảnh hưởng đến người. Mỗi Agent nên có tài khoản dịch vụ riêng; khi Agent làm thay một người, hãy dùng cơ chế ủy quyền với phạm vi hẹp và ghi cả hai danh tính vào nhật ký.
Nên chọn RBAC hay ABAC cho AI Agent?
RBAC đủ cho Agent có phạm vi ổn định và rõ ràng. Khi quyền phụ thuộc vào ngữ cảnh như số tiền, chi nhánh hay mức nhạy cảm của dữ liệu, hãy bổ sung điều kiện theo kiểu ABAC. Nhiều doanh nghiệp kết hợp cả hai.
Chỉ cần dặn AI Agent trong câu lệnh hệ thống là không được xóa dữ liệu có đủ không?
Có thể dặn, nhưng không đủ. OWASP khuyến nghị kiểm tra quyền ở hệ thống phía sau thay vì để mô hình tự quyết định. Nếu Agent không cần quyền xóa, đừng cấp công cụ hay token có quyền xóa.
Nhật ký AI Agent có cần lưu toàn bộ câu lệnh và câu trả lời không?
Không nhất thiết. Hướng dẫn của OWASP khuyên tránh ghi toàn văn câu lệnh và đầu vào, đầu ra của công cụ, ưu tiên mã yêu cầu, công cụ, mô hình và lượng sử dụng. Nếu cần nội dung để điều tra, hãy che dữ liệu cá nhân và đặt thời hạn lưu ngắn hơn.
Nhật ký AI Agent nên được lưu bao lâu?
Luật Bảo vệ dữ liệu cá nhân 2025 yêu cầu lưu dữ liệu cá nhân trong thời gian phù hợp với mục đích xử lý, trừ khi pháp luật quy định khác. Doanh nghiệp nên đặt thời hạn theo mục đích của từng loại nhật ký và kiểm tra thêm các quy định chuyên ngành áp dụng cho mình.