Phê duyệt qua email cho tác nhân AI: đúng người, đúng nội dung

Khi nào nên phê duyệt qua email cho tác nhân AI?

Agent đã soạn xong thư trả lời khách hàng, nhưng người phụ trách phải duyệt trước khi gửi. Điều kiện cần kiểm tra không phải “đã thông báo cho người phụ trách”, mà là “người có quyền đã chấp thuận đúng nội dung sắp gửi”.

Phê duyệt qua email là quy trình dùng email để chuyển yêu cầu hoặc nhận quyết định, còn ứng dụng giữ quyền cho phép thực thi. Thêm người duyệt vào CC chỉ gửi cho họ một bản thư; trong thiết kế này, CC không thay thế quyết định chấp thuận.

Hãy thử với hộp thư bạn sở hữu và nội dung khách hàng giả lập. Mailera kết nối hộp thư có sẵn, không tạo địa chỉ mới. Nếu cần chuẩn bị phần kết nối, xem cách dùng hộp thư có sẵn cho AI agent.

Nên chọn trang xác nhận có đăng nhập cho thư gửi ra ngoài chứa thông tin nhạy cảm. Người duyệt cần thấy người nhận và nội dung thực tế, không chỉ bản tóm tắt do AI viết.

Mailera đảm nhiệm phần nào?

Tách agent đề xuất khỏi bộ thực thi. Agent dùng list_messages hoặc get_message với quyền read. Dịch vụ tin cậy giữ quyền send để gửi yêu cầu duyệt và thư đã được duyệt; send_email và reply_to_email dùng quyền này.

Đặc tả công cụ MCP khuyến nghị có con người được quyền từ chối việc gọi công cụ và xác nhận thao tác nhạy cảm. MCP không bắt buộc một mô hình tương tác cụ thể. Vì vậy, đừng coi kết nối MCP là cơ chế chặn gửi chờ duyệt.

Dùng hướng dẫn MCP của Mailera để cấu hình kết nối và danh mục công cụ MCP theo tác vụ để chọn công cụ đọc thư. Phần gửi REST có trong tài liệu dành cho nhà phát triển.

Nếu nhận quyết định qua thư trả lời, ứng dụng có thể xử lý message.received hoặc đọc thư định kỳ. Sự kiện nhận thư chỉ báo có thư mới, không có nghĩa yêu cầu đã được duyệt.

Xây quy trình theo những bước nào?

1. Lưu đề xuất trước khi xin duyệt. Tạo mã yêu cầu riêng, lưu người có quyền duyệt, hộp thư gửi, hành động, người nhận, tiêu đề, nội dung, phiên bản và hạn duyệt. Đây là dữ liệu ứng dụng tự quản lý, không phải trường API Mailera. Giữ bản nội dung bất biến để đối chiếu về sau.
2. Gửi yêu cầu có đủ nội dung để quyết định. Thư cần ghi rõ hành động sắp thực hiện, người nhận, phiên bản và hạn phản hồi. Chỉ đưa dữ liệu cần thiết vào thư; phần nhạy cảm có thể để trên trang xác nhận có kiểm soát truy cập.
3. Yêu cầu đăng nhập và chấp thuận rõ ràng. Trang xác nhận kiểm tra người đang đăng nhập có quyền duyệt yêu cầu đó. Thiết kế thao tác mở liên kết bằng GET chỉ để hiển thị, không đổi trạng thái. Chỉ ghi nhận quyết định sau thao tác xác nhận riêng, khi yêu cầu còn hiệu lực.
4. Nếu dùng thư trả lời, kiểm tra bằng quy tắc cố định. Đối chiếu mã yêu cầu, phiên bản, thời hạn, người duyệt và mẫu phản hồi. Không dùng riêng địa chỉ From hoặc một câu AI diễn giải là đủ điều kiện. RFC 5322 về định dạng thư mô tả định dạng và một phần ngữ nghĩa nội dung thư, không phải chính sách cấp quyền duyệt của ứng dụng. Nếu không xác định được danh tính theo chính sách của bạn, giữ trạng thái chờ và yêu cầu xác nhận trên trang đăng nhập.
5. Giành quyền thực thi bằng cập nhật có điều kiện. Ngay trước khi gửi, kiểm tra lại quyền duyệt, thời hạn và phiên bản. Chỉ chuyển từ “đã duyệt” sang “đang thực thi” nếu trạng thái và phiên bản vẫn khớp. Tiến trình không cập nhật được phải dừng. Nếu nội dung hoặc người nhận thay đổi, tạo phiên bản mới và xin duyệt lại.
6. Gửi đúng bản đã duyệt. Bộ thực thi lấy nội dung từ bản đã lưu, không yêu cầu mô hình viết lại. Gọi POST /mailboxes/{id}/send bằng quyền send, gắn Idempotency-Key đã lưu cho lần thực thi đó. Lưu mã lần gửi và theo dõi bằng GET /sends/{id}.
7. Ghi lịch sử quyết định và kết quả. Lưu ai đã duyệt, phiên bản nào, thời điểm, lần thực thi và trạng thái gửi. Không ghi khóa API hoặc liên kết xác nhận còn hiệu lực vào nhật ký công khai.

Lưu trạng thái thế nào để không duyệt nhầm hoặc gửi lặp?

Nên dùng bảng trạng thái riêng cho ứng dụng. Không gộp “đã duyệt” với “đã gửi”: một yêu cầu được chấp thuận vẫn có thể chưa thực thi hoặc cần đối soát.

Lưu cả dấu nhận diện sự kiện đã xử lý và khóa thực thi trong kho dữ liệu bền vững. Phản hồi lặp không được tạo thêm lần thực thi; phản hồi muộn không được mở lại yêu cầu hết hạn.

Idempotency-Key hỗ trợ chống lặp ở lệnh gửi REST, không thay thế trạng thái phê duyệt. Sau khi ứng dụng khởi động lại, phải khôi phục yêu cầu và khóa đã lưu thay vì tạo lần gửi mới.

Trạng thái lần gửi của Mailera gồm queued, sending, sent, failed và unknown. Khi gặp unknown, chuyển yêu cầu sang đối soát thay vì gửi lại ngay. Thiết kế này nhằm hạn chế thực thi lặp, không hứa gửi đúng một lần trong mọi tình huống.

Những lỗi hay gặp và cách kiểm tra

Không thấy yêu cầu duyệt thì kiểm tra kết nối hộp thư, trạng thái lần gửi và thư mục Thư rác. Mailera không bảo đảm thư nằm trong Hộp thư đến. Không dùng việc người duyệt chưa nhận được thư làm lý do bỏ qua bước duyệt; xem tài liệu Mailera để kiểm tra phần kết nối và thao tác thư.

Nếu nhận hai phản hồi, kiểm tra dấu sự kiện đã xử lý và phép chuyển trạng thái có điều kiện. Với email chuyển tiếp hoặc thư có trích dẫn chữ “đồng ý”, không coi phần trích dẫn là quyết định mới.

Khi người duyệt sửa bản trả lời sau khi xác nhận, phiên bản mới phải quay về chờ duyệt. Khi tiến trình gửi bị gián đoạn, khôi phục từ dữ liệu đã lưu và đối soát lần gửi trước.

Trước khi cho phép gửi thư thật, dùng bảng kiểm thử sau với hộp thư thử:

Làm sao ngăn email trở thành lệnh cho agent?

Thư đến là dữ liệu không tin cậy, không phải chỉ dẫn hệ thống. Nội dung yêu cầu “bỏ qua người duyệt”, tiết lộ khóa hay đổi người nhận không được thay đổi quy tắc ứng dụng. Đặt điều kiện phê duyệt trong mã bên ngoài mô hình; lời nhắc “hãy hỏi trước khi gửi” không thay thế kiểm soát quyền.

Tạo khóa chỉ có quyền read cho agent đề xuất, giới hạn theo nhóm hộp thư cần dùng. Giữ khóa send ở bộ thực thi, ngoài tầm truy cập của agent này. Trong hộp thoại Tạo API key, dùng Phạm vi hộp thư để giới hạn nhóm; xem thêm thông tin bảo mật của Mailera.

Với webhook, kiểm tra chữ ký theo tài liệu hiện hành trước khi xử lý sự kiện. Lưu bí mật ký an toàn khi tạo webhook: Mailera chỉ trả bí mật này một lần. Sau đó vẫn phải kiểm tra quyết định trong ứng dụng; webhook hợp lệ không đồng nghĩa với chấp thuận hợp lệ.

Chỉ gửi cho mô hình và người duyệt dữ liệu cần thiết. Liên kết chia sẻ một thư phục vụ việc xem thư, không nên được dùng thay cho bản ghi quyết định gắn với người duyệt và phiên bản.