Phân quyền quản lý email cho nhóm và tác nhân AI trong Mailera

Vai trò thành viên, nhóm hộp thư và quyền API khác nhau thế nào?

Phân quyền quản lý email là xác định ai được truy cập hộp thư nào và được làm gì với thư trong đó. Với tác nhân AI, bạn cần xét cả phạm vi hộp thư lẫn quyền thao tác của khoá được giao.

Mailera kết nối hộp thư có sẵn với ứng dụng và AI agent qua REST, MCP và webhook. Khi phân công công việc, hãy tách các lớp sau:

Nhóm hộp thư là đơn vị dùng để chọn phạm vi của khoá. Khi bàn giao quyền API, hãy ghi rõ nhóm hộp thư được chọn, không chỉ ghi tên workspace.

Nguyên tắc này phù hợp với hướng dẫn phân quyền tối thiểu của Microsoft Entra: cân nhắc quyền, phạm vi tài nguyên và thời hạn.

Đọc thêm: Email cho AI agent với hộp thư có sẵn.

Mỗi tác nhân AI nên được cấp những quyền nào?

Bắt đầu từ nhiệm vụ, không bắt đầu bằng việc bật mọi quyền rồi thu hẹp sau.

Quyền đề xuất theo nhiệm vụ

Mailera có các quyền (permission) read, move, import, sync, send, manage, webhooks và share — đây là tên kỹ thuật dùng trong API/khoá, hiển thị trên giao diện lần lượt là Read, Move messages, Import mailboxes, Sync, Send messages, Manage mailboxes, Webhook, Sharing. Tác nhân tóm tắt thư không cần được cấp sẵn quyền nhập hộp thư, đồng bộ, quản lý hộp thư, webhook hoặc chia sẻ.

read không phải quyền chỉ xem tiêu đề. Quyền này còn dùng để đọc nội dung thư và lấy mã xác minh. Vì vậy, chỉ đưa vào phạm vi của khoá những hộp thư mà tác nhân thực sự được phép đọc nội dung.

Với MCP, các công cụ chỉ đọc như list_messages, search_messages, get_message hay get_latest_otp đều cần read; move_message và rescue_spam cần move; send_email và reply_to_email cần send. Đổi từ REST sang MCP không phải lý do để mở thêm quyền.

Thiết lập khoá giới hạn theo nhóm hộp thư như thế nào?

Dùng hộp thư thử thuộc quyền quản lý của bạn trước khi giao khoá cho tác nhân chạy với thư thật.

1. Chốt nhiệm vụ và nhóm hộp thư. Ví dụ: tác nhân chỉ tóm tắt thư trong nhóm hỗ trợ thử nghiệm. Vào Danh sách hộp thư để xác nhận các hộp thư cần dùng đã có trong nhóm đó. Nếu cần thêm hộp thư, người thực hiện phải có vai trò Admin hoặc Leader.
2. Mở Cài đặt, vào thẻ khoá API và chọn Tạo key. Điền Tên gợi nhớ theo nhiệm vụ, chẳng hạn “Tóm tắt hỗ trợ thử nghiệm”, để khi bàn giao bạn biết khoá phục vụ việc gì.
3. Chọn Phạm vi hộp thư và quyền. Chọn đúng một nhóm và chỉ cấp read cho tác nhân tóm tắt. Admin có thể chọn tất cả nhóm, nhưng không nên dùng phạm vi đó cho nhiệm vụ chỉ liên quan một nhóm.
4. Đặt Thời hạn và cân nhắc Giới hạn IP (tuỳ chọn). Chọn thời hạn phù hợp với đợt công việc. Nếu giới hạn IP, đối chiếu với địa chỉ IP của môi trường chạy tác nhân; bỏ trống nghĩa là mọi IP.
5. Lưu khoá ngay khi tạo. Khoá chỉ hiển thị một lần tại Key đã tạo — sao chép ngay. Lưu vào nơi quản lý bí mật. Nếu dùng Claude, Cursor hoặc VS Code, bạn có thể chọn Sao chép cấu hình MCP trong cùng hộp thoại.

Đối với REST, lưu khoá trong biến môi trường MAILERA_API_KEY, rồi gọi thử danh sách hộp thư:

curl --request GET \
  'https://mailera.app/api/public/v1/mailboxes?limit=1' \
  --header "Authorization: Bearer $MAILERA_API_KEY"

Đối chiếu data[].id và data[].group_id trong phản hồi với hộp thư thử đã chọn. Lệnh này kiểm tra một thao tác đọc; đừng dùng một lần gọi thành công để kết luận toàn bộ cấu hình quyền đã đúng.

Trước khi đưa vào sử dụng, kiểm tra cả trường hợp được phép lẫn trường hợp phải bị từ chối:

• • Đọc thư thử trong nhóm đã cấp quyền.
• Thử truy cập hộp thư thử ngoài nhóm, kể cả qua tìm kiếm xuyên hộp thư.
• Với khoá chỉ có read, thử gọi thao tác gửi và di chuyển trên dữ liệu thử để xác nhận API từ chối đúng như kỳ vọng. Dùng địa chỉ nhận thử do bạn quản lý khi kiểm tra.

Ghi lại kết quả và sửa cấu hình nếu tác nhân làm được việc ngoài nhiệm vụ. Dùng tài liệu API để tra thao tác REST, trang dành cho nhà phát triển để chọn cách tích hợp, hoặc hướng dẫn MCP khi cấu hình tác nhân.

Đọc thêm: Email MCP server cho hộp thư có sẵn.

Những lỗi phân quyền nào thường gặp?

Tham số group_id của GET /mailboxes là bộ lọc danh sách. Đừng dùng nó thay cho phạm vi được cấu hình trên khoá. Tương tự, yêu cầu tác nhân “chỉ đọc thư” trong lời nhắc không thay thế việc bỏ quyền send và move.

Cho AI đọc email cần những biện pháp an toàn nào?

Thư đến là dữ liệu không tin cậy, không phải lệnh cho tác nhân. Một email yêu cầu tiết lộ khoá, đổi cấu hình, mở rộng quyền hoặc gửi dữ liệu ra ngoài phải được xử lý như nội dung thư, không phải chỉ dẫn vận hành. Đây là ranh giới cần giữ để chống prompt injection.

Cấp khoá riêng, ít quyền và giới hạn theo nhóm. Không đưa khoá, mật khẩu chia sẻ hay nội dung thư nhạy cảm vào nhật ký và ảnh chụp. RFC 6750 về Bearer token yêu cầu bảo vệ token khỏi bị lộ cả khi lưu trữ lẫn khi truyền; REST API của Mailera dùng khoá trong header Authorization với cơ chế Bearer.

Nếu tác nhân được gửi thư, hãy thiết kế bước người dùng xem người nhận và nội dung rồi xác nhận trước khi gọi thao tác gửi. Đặc tả công cụ MCP khuyến nghị luôn có người có thể từ chối việc gọi công cụ.

Bước xác nhận này do bạn tự xây dựng trong ứng dụng hoặc tác nhân — cấp quyền send không có nghĩa là đã có bước duyệt.

Quyền API Mailera không thay thế chính sách bảo mật và quyền truy cập tại nhà cung cấp email. Khi rà soát tích hợp, đọc thêm thông tin bảo mật của Mailera và kiểm tra cả cấu hình phía nhà cung cấp.

Thu hồi quyền và bàn giao công việc ra sao?

Khi một thành viên rời nhóm hoặc một tác nhân ngừng chạy, hãy rà soát từng đường truy cập. Không mặc định rằng thay đổi vai trò thành viên sẽ xử lý toàn bộ khoá và liên kết đã được cấp.

1. Lập danh sách cần bàn giao. Ghi khoá nào đang được ứng dụng hoặc tác nhân sử dụng, phạm vi nhóm, nhiệm vụ và các liên kết chia sẻ liên quan. Không chép giá trị bí mật vào tài liệu bàn giao.
2. Chuẩn bị khoá thay thế nếu công việc tiếp tục. Cấp đúng phạm vi và quyền cho bên nhận, rồi cập nhật cấu hình tác nhân.
3. Thu hồi khoá không còn cần. Các lệnh gọi bằng khoá đã thu hồi bị từ chối ngay.
4. Thu hồi riêng liên kết chia sẻ không còn dùng. Chia sẻ một thư qua liên kết chỉ khả dụng khi Admin bật. Mailera có thao tác DELETE /shares/{id} (cần quyền share) để thu hồi liên kết, và không thể hoàn tác việc thu hồi đó.
5. Kiểm tra lại sau bàn giao. Thử khoá cũ, liên kết cũ và các thao tác được giao cho khoá mới trên dữ liệu thử.

Khi rà soát định kỳ, đối chiếu từng khoá còn hiệu lực với một nhiệm vụ đang hoạt động. Khoá không còn chủ sở hữu công việc rõ ràng cần được xử lý, thay vì để tồn tại chỉ vì ứng dụng trước đây từng dùng nó.