AI Agent của bạn cần một danh tính trước khi lên production

Phòng tài chính của bạn vừa build xong một AI agent: nó đọc báo cáo đối chiếu, kiểm tra số liệu, và tự động draft comment cho các khoản mục chưa khớp. Demo chạy mượt mà. Rồi có người hỏi một câu đơn giản: Thực ra ai đã thực hiện thao tác này?

Agent đang hành động thay mặt một controller cụ thể? Hay nó là một hệ thống độc lập? Và nếu kết quả sai, ai chịu trách nhiệm?

Câu hỏi đó khiến nhiều đội nhóm lúng túng. Nó không phải chi tiết kỹ thuật vụn vặt. Nó chạm đến cách tổ chức nhìn nhận AI agent: như một công cụ vô danh, hay một tác nhân số có danh tính, quyền hạn và khả năng kiểm toán rõ ràng như bất kỳ con người hay ứng dụng nào.

Nhiều tổ chức đã rất giỏi trong việc nghĩ về model, prompt và tích hợp API. Nhưng khi use case chuyển từ demo sang production, một thứ thường xuyên bị bỏ qua: agent không có danh tính rõ ràng. Nó chạy trên một service account chung với quyền quá rộng, và log không thể giải thích nguồn gốc của hành động. Ngay khi agent đọc một hóa đơn, mở một ticket, thay đổi trạng thái đơn hàng, hay kích hoạt một luồng procurement, công ty không thể trả lời những câu hỏi cơ bản: Agent dùng danh tính gì? Nó hành động thay mặt ai? Nó có quyền gì? Và bối cảnh workflow nào dẫn đến hành động đó?

Đối với doanh nghiệp, đây không phải chi tiết nhỏ. Nếu không có mô hình danh tính và phân quyền rõ ràng, khả năng kiểm toán, trách nhiệm giải trình và kiểm soát runtime sẽ sụp đổ ngay khi agent bắt đầu mang lại giá trị thực.

Mô hình vận hành cho danh tính và truy cập của agent: từ nguồn ủy quyền qua các lớp phân quyền đến thực thi runtime và kiểm toán.

Agent không phải là một script vô danh

Trong kiến trúc doanh nghiệp truyền thống, chúng ta có nhiều loại tác nhân: con người, ứng dụng, service account, và các tiến trình định kỳ. Agentic AI thêm một loại mới: một tác nhân số có thể suy luận, chọn công cụ và hành động qua nhiều bước. Agent không nên bị đối xử như một script vô danh chạy ngầm.

Agent cần một danh tính rõ ràng vì doanh nghiệp cần biết ba điều: ai thực hiện hành động, dưới sự ủy quyền của ai, và trong workflow nào. Thiếu ba điều này, kiểm soát doanh nghiệp trở nên mơ hồ.

Hãy xem xét một agent procurement nhận yêu cầu đầu vào, kiểm tra hợp đồng, và draft một purchase request trong ERP. Nếu hành động đó chỉ được log là hoạt động từ một service account chung, thì khi có vấn đề, công ty không thể biết hành động đó được kích hoạt bởi một user cụ thể, một workflow định kỳ, một sự kiện tự động, hay một hành vi lạm dụng truy cập. Điều tương tự áp dụng cho quyết toán tài chính, vận hành khách hàng, hay vận hành IT. Khi agent bắt đầu chạm vào trạng thái kinh doanh, danh tính của nó phải có khả năng truy vết như bất kỳ con người hay ứng dụng nào.

Danh tính cũng là nền tảng của trách nhiệm giải trình. Trong mô hình cũ, trách nhiệm đi theo con người: analyst, approver, supervisor, system owner. Trong mô hình agentic, một số hành động chuyển sang lao động số. Điều đó không có nghĩa là trách nhiệm biến mất. Ngược lại, nó phải được làm rõ ràng hơn. Công ty cần trả lời: Agent này thuộc chức năng nào? Ai là business owner? Ai là technical owner? Những công cụ nào được phép? Ranh giới hành động cho phép là gì? Nếu không, tổ chức đối mặt với tình huống nguy hiểm: agent hành động với hậu quả thực, nhưng không có mô hình kiểm soát nào tương xứng với tác động của nó.

Danh tính cũng xác định ranh giới tin cậy. Một agent tương tác với nhân viên nội bộ khác với agent phục vụ khách hàng bên ngoài. Một agent chỉ đọc knowledge base khác với agent có thể thay đổi trạng thái thanh toán. Một agent chạy trong ngữ cảnh user đã xác thực khác với agent phục vụ kênh công cộng. Nếu tất cả agent được đối xử như nhau, công ty thường rơi vào hai thái cực: quá lỏng lẻo hoặc quá hạn chế. Cả hai đều tệ.

Vai trò tĩnh không đủ cho phân quyền agent

Khi agent đã có danh tính, câu hỏi khó hơn là phân quyền. Nhiều đội nhóm mắc một sai lầm cũ trong vỏ bọc mới: họ gán một vai trò tĩnh và hy vọng nó là đủ.

Đối với agent, quyền cần có ngữ cảnh. Agent đang hành động cho một user cụ thể, một workflow định kỳ, hay một sự kiện kích hoạt? Nó đang đọc dữ liệu, draft đề xuất, thực thi thay đổi, hay hỗ trợ phê duyệt? Dữ liệu là thông tin kinh doanh chung hay dữ liệu nhạy cảm như lương, ngân hàng nhà cung cấp, hợp đồng, hay thông tin khách hàng?

Cùng một agent có thể được phép đọc dữ liệu hóa đơn, draft giải thích sai lệch, và đề xuất giải pháp, nhưng không được phép giải phóng một payment block. Một HR agent có thể trả lời câu hỏi onboarding và draft thông báo, nhưng không được thay đổi lương hay trạng thái nhân viên. Phân quyền theo ngữ cảnh là thứ ngăn một pilot hữu ích trở thành rủi ro sản xuất với quyền quá rộng.

Ủy quyền: Agent hành động thay mặt ai?

Nhiều hành động của agent không thực sự thuộc về agent. Chúng đến từ một mandate: một chỉ thị của user, một workflow đã được phê duyệt, hay một sự kiện tự động kích hoạt.

Những nguồn này phải được phân biệt. Một agent procurement draft purchase request cho một buyer khác với một agent quyết toán tài chính chạy kiểm tra định kỳ hàng đêm, và cả hai đều khác với một agent IT ops phản hồi sự kiện giám sát. Audit trail nên ghi lại nguồn ủy quyền, danh tính agent, thời hạn hiệu lực, công cụ đã dùng, và liệu hành động có nằm trong chính sách hay không.

Ủy quyền cũng nên có giới hạn: có thể thu hồi, có thời hạn, có phạm vi, và đôi khi có giới hạn giá trị. Agent có thể draft purchase request tiêu chuẩn dưới một ngưỡng, gửi follow-up khách hàng rủi ro thấp, hay chạy chẩn đoán hạn chế. Ngoài mandate đó, nó nên dừng lại.

Mẫu triển khai cho doanh nghiệp

Mẫu triển khai cho doanh nghiệp đơn giản hơn bạn nghĩ: cho mỗi agent production một service identity riêng, gắn các lời gọi công cụ vào một policy engine, tách quyền theo loại hành động, và log toàn bộ chuỗi hành động.

Điều đó có nghĩa là agent không nên dùng chung một service account. Nó nên được đăng ký với business owner, technical owner, lĩnh vực quy trình, công cụ được phép, mức rủi ro, và trạng thái vòng đời. Quyền truy cập runtime nên được đánh giá mỗi khi agent gọi một công cụ, không chỉ khi session bắt đầu.

Mô hình phân quyền hữu ích nhất là phân lớp: đọc, đề xuất, draft, thực thi, và phê duyệt. Một agent tài chính có thể đọc sổ sách, đề xuất xử lý, và draft bình luận; thực thi có thể giới hạn ở các hành động rủi ro thấp; phê duyệt quan trọng nên vẫn do con người. Một agent procurement có thể đọc hợp đồng và draft purchase request, nhưng quyền phê duyệt nên thuộc về người phê duyệt có trách nhiệm.

Audit trail phải giải thích nhiều hơn lời gọi API cuối cùng. Nó nên kết nối user hoặc nguồn mandate, danh tính agent, quyết định chính sách, lời gọi công cụ, đầu vào, đầu ra, phê duyệt, và thay đổi trạng thái cuối cùng. Nếu công ty không thể tái tạo chuỗi đó, agent chưa sẵn sàng cho quy mô production.

Áp dụng vào hệ thống thật

Dưới đây là cách điều này dịch sang sprint tiếp theo của bạn:

• Đăng ký mỗi agent như một danh tính hạng nhất trong hệ thống IAM, với business owner và technical owner.
• Tách quyền theo loại hành động: đọc, đề xuất, draft, thực thi, phê duyệt. Đừng cấp quyền ghi cho agent chỉ vì nó cần quyền đọc.
• Gắn lời gọi công cụ vào policy engine tại runtime, không chỉ khi session bắt đầu. Đánh giá mỗi lời gọi API dựa trên ngữ cảnh hiện tại.
• Log toàn bộ chuỗi ủy quyền: ai hoặc cái gì kích hoạt hành động, mandate nào đang hoạt động, công cụ nào được dùng, và trạng thái nào đã thay đổi.
• Làm cho ủy quyền có giới hạn: có thời hạn, có phạm vi, và có thể thu hồi. Một agent không nên có quyền vĩnh viễn.
• Kiểm tra thu hồi trong các bài tập xử lý sự cố. Bạn có thể vô hiệu hóa quyền truy cập của agent trong vòng 60 giây không?

Nếu đội của bạn vẫn dùng một service account chung cho nhiều agent, hoặc nếu quyền được cấp quá rộng để "cho nó chạy", thì đây là những thứ đầu tiên cần sửa.

Khi nào mẫu này chưa phù hợp

Không phải tổ chức nào cũng sẵn sàng áp dụng mô hình trưởng thành ngay lập tức. Có một số tín hiệu nguy hiểm cho thấy agent chưa sẵn sàng để mở rộng:

• Agent vẫn dùng service account chung không có danh tính riêng.
• Quyền được cấp quá rộng chỉ để use case chạy được.
• Không có sự phân tách giữa quyền đọc, draft và thực thi.
• Ủy quyền không được ghi lại rõ ràng.
• Lời gọi công cụ không đi qua policy engine hoặc kiểm soát runtime.
• Audit log chỉ ghi đầu ra cuối cùng, không ghi chuỗi quyết định.
• Không có cách nhanh chóng để thu hồi quyền truy cập agent trong sự cố.
• Business owner không biết chính xác agent dùng công cụ và dữ liệu gì.

Nếu có nhiều triệu chứng này, mở rộng agentic AI sẽ làm tăng rủi ro nhanh hơn giá trị.

Agent có quyền tự chủ thực thi cũng chưa phù hợp cho các lĩnh vực chạm đến giao dịch quan trọng không có rollback rõ ràng, nơi định nghĩa chính sách chưa thể dịch thành quy tắc runtime, nơi dữ liệu không ổn định, hoặc nơi quyền sở hữu quy trình còn mơ hồ. Trong những điều kiện đó, an toàn hơn là bắt đầu với đọc, đề xuất và draft, đồng thời củng cố danh tính, chính sách và logging trước.

Câu hỏi để mang về

Bài kiểm tra thực tế rất đơn giản. Nếu ngày mai một kiểm toán viên, cơ quan quản lý, hay ủy ban rủi ro hỏi: "Ai đã thực hiện hành động này, dưới sự ủy quyền của ai, và tại sao hệ thống cho phép nó?" - công ty bạn có thể trả lời bằng bằng chứng không?

Nếu câu trả lời chưa rõ ràng, ưu tiên tiếp theo không phải là một model mạnh hơn. Đó là mô hình danh tính, phân quyền, ủy quyền và kiểm toán cho phép AI agent trở thành một tác nhân doanh nghiệp đáng tin cậy.

Bài viết này được xuất bản lần đầu trên ariefwara.github.io.