Phê duyệt, chính sách và hạn mức MCP

Xem xét quyền cho từng thao tác: đọc cần quyền tương ứng, thay đổi hồ sơ cần xem trước và khóa thử lại, gửi còn cần chính sách đang có hiệu lực được người phụ trách duyệt. Kiểm tra cả sự đồng ý, danh sách không liên hệ, giấy phép và khu vực pháp lý.

Các bậc rủi ro là gì?

Bậc	Hành động	Kiểm soát
R0	`workspace.context`, `workspace.capabilities`	Scope `workspace:read`. Luôn được liệt kê khi scope được cấp.
R1	`companies.`, `trade.`, `contacts.*`, `leads.list`, `campaigns.list`	Quyền đọc tương ứng và quyền truy cập không gian làm việc.
R2	`leads.create`, `campaigns.draft`	Quyền tạo, xem trước bằng `dry_run`, bắt buộc có `idempotency_key` khi ghi thật.
R3	`email.send`, `sms.send`	Quyền gửi, `policy_id` đang có hiệu lực đã được người phụ trách duyệt, xem trước bằng `dry_run`, bắt buộc có `idempotency_key` khi gửi thật.

Dùng tools/list để xem các công cụ khả dụng cho kết nối. Phạm vi sử dụng phụ thuộc vào quyền đã cấp và quyền truy cập của không gian làm việc. Bắt đầu với quyền đọc; nhờ quản trị viên xem xét quyền còn thiếu thay vì yêu cầu quyền rộng.

Chính sách thường trực và xem xét hoạt động như thế nào?

Trước khi bật gửi, người phụ trách cần kiểm tra đối tượng, người gửi, các tuyên bố trong nội dung, sự đồng ý, danh sách không liên hệ, khu vực pháp lý, giấy phép và hạn mức ngân sách. Dùng policy_id của chính sách thường trực đang có hiệu lực cho các lần gửi được phép và xem trước bằng dry_run: true. Một chính sách có thể cho phép nhiều lần gửi; điều đó không có nghĩa mỗi tin nhắn đều được duyệt riêng. Tạm dừng khi điều kiện liên hệ hoặc quyền hạn chưa rõ.

Nên sử dụng chạy thử và khóa idempotency như thế nào?

Gửi dry_run: true trước cho mọi hành động R2/R3. Máy chủ kiểm tra scope, chính sách và tham số mà không tạo bản ghi hay gửi thông điệp.
Tạo một UUID idempotency_key cho mỗi lượt ghi dự kiến và tái sử dụng cho các lần thử lại. Khóa lặp lại trả về kết quả gốc thay vì tạo lead, bản thảo hoặc lượt gửi trùng lặp.
Không bao giờ tạo khóa mới khi thử lại lượt ghi hết thời gian chờ. Lưu khóa cùng request_id trong log riêng.
Bắt buộc khi ghi hoặc gửi thật; dùng lại cùng UUID khi thử lại cùng thao tác với tham số không đổi.

Những hạn mức nào được áp dụng?

Giới hạn yêu cầu và mức sử dụng phụ thuộc vào quyền truy cập của không gian làm việc và thao tác. Kiểm tra mức sử dụng hiện tại với quản trị viên. Khi gặp quota_exceeded, tuân thủ Retry-After và thời điểm đặt lại được trả về, rồi thử lại với thời gian chờ tăng dần và số lần giới hạn. Không dùng yêu cầu song song, thêm ứng dụng hoặc chính sách mới để né giới hạn.

quota_exceeded bao gồm reset_at và retry_after. Tuân thủ Retry-After và thử lại với backoff giới hạn. Không chạy dàn trải các lượt thử lại song song khi gặp 429.

Cách thu hồi quyền truy cập và xem xét hoạt động?

Thu hồi tại POST /oauth/revoke hoặc xóa OAuth client trong Settings → Integrations. Thu hồi dừng cả lệnh gọi MCP và REST agent cho token đó.
Rà soát sự kiện kiểm tra của workspace về phê duyệt chính sách, lượt gửi và thay đổi chính sách.
Kiểm tra mức dùng hằng ngày và theo cửa sổ trước khi nâng giới hạn hoặc thêm client mới.
Xoay vòng mọi token đã xuất hiện trong log, ảnh chụp màn hình hoặc ticket hỗ trợ. Không bao giờ gửi token cho bộ phận hỗ trợ; gửi request_id đã che, dấu thời gian, tên công cụ và mã lỗi.