Zero Trust cho AI Agent: khi nào cần người duyệt?

TL;DR: Cho AI Agent tự động hoàn toàn không phải là đích đến — đó là một cái bẫy. Controlled Autonomy là nguyên tắc phân cấp quyền tự chủ theo mức độ rủi ro của từng hành động: việc có thể hoàn tác thì để Agent tự quyết, việc không thể hoàn tác (gửi tiền, xóa dữ liệu, đăng nội dung công khai) bắt buộc phải có người duyệt trước khi thực thi.

Tôi từng nghĩ mục tiêu cuối cùng của việc xây AI Agent là loại bỏ hoàn toàn con người khỏi quy trình. Càng tự động, càng "AI xịn". Sai. Sau nhiều tháng vận hành hệ thống multi-agent cho công việc hàng ngày, tôi nhận ra thứ quyết định một hệ thống có đáng tin hay không không phải là nó tự động được bao nhiêu việc, mà là nó biết dừng lại đúng lúc hay không. Đây là cách tôi phân cấp quyền tự chủ cho Agent — và tại sao "full auto" luôn là lựa chọn sai ở những hành động không thể hoàn tác.

Bài viết này nối tiếp mạch Human-in-the-loop là gì — và khi nào AI cần người kiểm soát, nhưng đi sâu hơn vào phần khó nhất: không chỉ xác định có cần checkpoint hay không, mà xây một ma trận phân cấp cụ thể để Agent tự biết khi nào nó được phép hành động, và khi nào phải dừng chờ.

Controlled Autonomy là gì, và vì sao "tự động hoàn toàn" là cái bẫy?

Controlled Autonomy là nguyên tắc thiết kế quyền hành động của AI Agent theo từng mức rủi ro cụ thể, thay vì cấp một mức quyền cố định cho toàn bộ hệ thống. Agent được tự chủ tối đa ở các hành động có thể hoàn tác, và bị khóa lại ở các hành động không thể hoàn tác — bất kể mức độ "thông minh" của model đứng sau nó.

Cái bẫy của "tự động hoàn toàn" nằm ở một giả định ngầm: rằng nếu Agent đủ giỏi, nó sẽ không bao giờ sai. Nhưng vấn đề không nằm ở việc Agent có sai hay không — nó sẽ sai, sớm hay muộn, giống hệt con người. Vấn đề nằm ở cái giá phải trả khi nó sai.

Một Agent tự động phân loại email bị sai một lần — bạn sửa lại, mất 10 giây. Một Agent tự động gửi email cho toàn bộ danh sách khách hàng bị sai một lần — bạn không sửa lại được nữa. Cùng một model, cùng một task loại "gửi", nhưng rủi ro khác nhau hoàn toàn tùy vào phạm vi và tính hoàn tác của hành động, không phải tùy vào độ thông minh của AI.

Đây là lý do tôi bỏ hẳn tư duy "cấp quyền theo Agent" (Agent A được full quyền, Agent B chỉ đọc) và chuyển sang "cấp quyền theo hành động". Cùng một Agent có thể vừa tự chủ hoàn toàn ở việc này, vừa bị khóa cứng ở việc khác — vì bản chất hành động khác nhau, không phải vì Agent khác nhau.

Ba biến số tôi dùng để định mức rủi ro cho mỗi hành động:

• Tính khả nghịch (reversibility): Hành động này có thể hoàn tác trong vòng vài phút không, hay đã xảy ra là không thể lấy lại?
• Phạm vi tác động (blast radius): Sai thì ảnh hưởng một dòng dữ liệu nội bộ, hay ảnh hưởng ra bên ngoài (khách hàng, công chúng, tiền bạc)?
• Chi phí xác minh (verification cost): Con người kiểm tra kết quả trước khi nó xảy ra tốn bao nhiêu thời gian, so với chi phí nếu để nó xảy ra rồi mới sửa?

Ma trận phân cấp: hành động nào Agent tự làm, hành động nào cần Approval Gate

Từ ba biến số trên, tôi chia hành động của Agent thành bốn cấp quyền. Đây là khung tôi đang dùng cho hệ thống cá nhân — không phải chuẩn ngành, nhưng là cách tư duy có thể áp dụng cho bất kỳ hệ thống Agent nào, dù nhỏ hay lớn.

Điểm mấu chốt nằm ở Cấp 3 — đây là nơi hầu hết hệ thống SME bỏ sót. Nhiều người xây Agent chỉ nghĩ tới hai thái cực: "để nó tự làm hết" (Cấp 1 áp cho mọi thứ) hoặc "cái gì cũng phải duyệt" (Cấp 4 áp cho mọi thứ). Cả hai đều sai — cực đầu làm hệ thống rủi ro, cực sau làm hệ thống chậm đến mức không ai buồn dùng.

Approval Gate ở Cấp 3 không có nghĩa là con người làm lại toàn bộ việc. Nó có nghĩa là Agent làm hết phần chuẩn bị — soạn nội dung, tổng hợp ngữ cảnh, đề xuất hành động — và dừng đúng một bước cuối cùng: bấm nút xác nhận. Sự khác biệt giữa "Agent làm hộ 95% công việc, người duyệt 5% cuối" và "người tự làm 100%" là toàn bộ giá trị của tự động hóa có kiểm soát.

Xu hướng Zero-Trust Agent Mesh: bài học áp dụng được cho hệ thống nhỏ của SME

Zero-Trust Agent Mesh là mô hình kiến trúc trong đó không Agent nào được mặc định tin tưởng — mọi hành động, kể cả giữa các Agent nội bộ với nhau, đều phải được xác thực và giới hạn quyền theo từng tác vụ cụ thể, thay vì cấp quyền một lần rồi để hệ thống tự vận hành.

Giữa tháng 8/2026, giới công nghệ chú ý tới một dự án mã nguồn mở tên SAM (Sovereign Agent Mesh) — theo đưa tin của MarkTechPost ngày 18/08/2026, đây là một lớp mạng ngang hàng (P2P) zero-config, zero-trust, cho phép các AI Agent tự động khám phá và gọi công cụ MCP (Model Context Protocol) của nhau trên nhiều môi trường khác nhau. Tôi không dùng lại chi tiết kỹ thuật của dự án này — không phải trọng tâm bài viết, và tôi cũng chưa tự kiểm chứng — nhưng cái tên "Zero Trust" mà cộng đồng kỹ thuật quốc tế đang chọn cho các hệ thống multi-agent nói lên một điều đáng chú ý: xu hướng lớn không phải là tăng mức độ tự động hoàn toàn, mà là tăng mức độ kiểm soát khi hệ thống có nhiều Agent phối hợp với nhau.

Với một SME hay một Solo Expert đang tự xây hệ thống Agent quy mô nhỏ, bạn không cần đến hạ tầng mạng ngang hàng phức tạp. Nhưng nguyên tắc gốc — "không mặc định tin tưởng, xác thực theo từng hành động" — áp dụng được ngay cả khi bạn chỉ có 2-3 Agent chạy nội bộ:

• Đừng cấp quyền theo "vai trò" cố định. Một Agent chuyên xử lý email không nên mặc định có quyền gửi email ra ngoài chỉ vì nó "là Agent email". Quyền gửi (Cấp 3 ở trên) nên tách riêng khỏi quyền soạn (Cấp 1).
• Ghi log mọi hành động Cấp 2 trở lên, kể cả khi Agent tự làm không cần duyệt. Bạn không cần xem log mỗi ngày, nhưng cần nó tồn tại khi có sự cố cần truy vết lại "Agent đã làm gì, lúc nào".
• Coi mỗi kết nối giữa hai Agent là một điểm cần giới hạn quyền riêng, không phải một đường ống mở. Agent A gọi Agent B không có nghĩa là Agent A thừa hưởng toàn bộ quyền của Agent B.

Bài học không phải "hãy xây hạ tầng zero-trust phức tạp như các dự án lớn". Bài học là: ngay cả những nơi đang đẩy mạnh tự động hóa multi-agent nhất, xu hướng kiến trúc vẫn đang đi về phía nhiều lớp kiểm soát hơn, không phải ít hơn. Nếu bạn đang cân nhắc bỏ qua Approval Gate cho gọn, đây là một dữ kiện đáng cân nhắc lại.

Cách thiết lập cổng duyệt qua Telegram/Slack mà không làm chậm vận hành

Approval Gate chỉ có giá trị nếu nó nhanh hơn thời gian bạn tự làm việc đó. Nếu duyệt một hành động mất công mở nhiều tab, tìm log, đọc lại toàn bộ ngữ cảnh — bạn sẽ dần bỏ qua bước duyệt, và cổng kiểm soát trở thành vô nghĩa trên giấy.

Cách tôi thiết lập để cổng duyệt không làm chậm vận hành:

1. Đưa quyết định về đúng nơi bạn đã ở sẵn. Với tôi đó là Telegram — nơi tôi kiểm tra nhiều lần trong ngày. Agent gửi yêu cầu duyệt về đúng kênh đó thay vì một dashboard riêng bạn phải nhớ mở.
2. Gói ngữ cảnh đủ dùng trong một tin nhắn, không bắt người duyệt phải đi tìm. Một yêu cầu duyệt tốt phải trả lời được ba câu hỏi ngay trong nội dung: Agent định làm gì, tại sao nó đề xuất làm vậy, và điều gì xảy ra nếu bạn không phản hồi.
3. Có hành vi mặc định rõ ràng khi không phản hồi kịp, thay vì để hệ thống treo vô thời hạn. Với hành động không khẩn — mặc định là hủy, không phải mặc định là thực thi. Bắt Agent phải chờ "có" rõ ràng, không được suy diễn im lặng là đồng ý.
4. Duyệt bằng một hành động đơn — trả lời một ký tự, bấm một nút — không bắt người duyệt gõ lại toàn bộ nội dung hay đăng nhập vào hệ thống khác. Ma sát càng thấp, Approval Gate càng được tôn trọng đúng chức năng của nó thay vì bị bỏ qua vì phiền.

Cổng duyệt không phải là cách để làm chậm hệ thống lại — nó là cách để bạn dám để hệ thống chạy nhanh hơn ở những phần còn lại, vì bạn biết chắc phần rủi ro nhất luôn có một điểm dừng cuối cùng.

Kết luận

Tôi không còn hỏi "làm sao để Agent này tự động hoàn toàn" nữa. Câu hỏi đúng hơn là: hành động nào trong hệ thống này thực sự cần một người dừng lại và gật đầu, và làm sao để việc gật đầu đó không tốn quá vài giây. Controlled Autonomy không phải là giới hạn tốc độ của AI Agent — nó là điều kiện để bạn có thể tin tưởng giao nhiều việc hơn cho nó theo thời gian, thay vì phải giám sát lại từ đầu mỗi khi có sự cố.

Nếu bạn đang thiết kế lớp nhân cách và giới hạn hành vi cho Agent của mình ở tầng system prompt, phần khung phân quyền này nên đi cùng với cách bạn viết prompt định hình Agent — tôi có trình bày kỹ hơn ở Director Mindset: viết System Prompt định hình nhân cách Agent.