ตรวจสอบสิทธิ์ของแต่ละการดำเนินการ การอ่านต้องมีสิทธิ์ที่ตรงกัน การแก้ระเบียนต้องดูตัวอย่างและมีคีย์สำหรับลองซ้ำ การส่งยังต้องมีนโยบายที่มีผลและผ่านการตรวจสอบของผู้รับผิดชอบ ตรวจสอบความยินยอม รายการห้ามติดต่อ สิทธิ์การใช้ข้อมูล และเขตอำนาจศาลด้วย
ระดับความเสี่ยงมีอะไรบ้าง
| ระดับ | การดำเนินการ | การควบคุม |
|---|---|---|
| R0 | workspace.context, workspace.capabilities | ขอบเขต workspace:read แสดงเสมอเมื่อได้รับขอบเขต |
| R1 | companies.*, trade.*, contacts.*, leads.list, campaigns.list | สิทธิ์อ่านที่ตรงกันและสิทธิ์การเข้าถึงพื้นที่ทำงาน |
| R2 | leads.create, campaigns.draft | สิทธิ์สร้าง ดูตัวอย่างด้วย dry_run และต้องมี idempotency_key สำหรับการเขียนจริง |
| R3 | email.send, sms.send | สิทธิ์ส่ง policy_id ที่มีผลและผ่านการตรวจสอบของผู้รับผิดชอบ ดูตัวอย่างด้วย dry_run และต้องมี idempotency_key สำหรับการส่งจริง |
ใช้ tools/list เพื่อดูเครื่องมือที่ใช้ได้กับการเชื่อมต่อนี้ ความพร้อมใช้งานขึ้นอยู่กับสิทธิ์ที่ได้รับและสิทธิ์การเข้าถึงของพื้นที่ทำงาน เริ่มด้วยสิทธิ์อ่าน และให้ผู้ดูแลตรวจสอบสิทธิ์ที่ขาดแทนการขอสิทธิ์กว้างเกินความจำเป็น
นโยบายถาวรและการทบทวนทำงานอย่างไร
ก่อนเปิดการส่ง ให้ผู้รับผิดชอบตรวจสอบกลุ่มเป้าหมาย ผู้ส่ง ข้อกล่าวอ้างในข้อความ ความยินยอม รายการห้ามติดต่อ เขตอำนาจศาลที่เกี่ยวข้อง สิทธิ์การใช้ข้อมูล และเพดานงบประมาณ ใช้ policy_id ของนโยบายถาวรที่มีผลสำหรับการส่งที่ได้รับอนุญาต และดูตัวอย่างด้วย dry_run: true นโยบายหนึ่งอาจอนุญาตหลายการส่ง จึงไม่ได้หมายความว่ามีคนอนุมัติทุกข้อความแยกกัน หยุดงานเมื่อสิทธิ์หรือคุณสมบัติของผู้รับไม่ชัดเจน
ควรใช้การเรียกแบบทดลองและคีย์ idempotency อย่างไร
- ส่ง
dry_run: trueก่อนสำหรับทุกการดำเนินการ R2/R3 เซิร์ฟเวอร์ตรวจสอบขอบเขต นโยบาย และอาร์กิวเมนต์โดยไม่เขียนระเบียนหรือส่งข้อความ - สร้าง UUID
idempotency_keyหนึ่งค่าต่อการเขียนที่ตั้งใจและใช้ซ้ำในการลองใหม่ คีย์ซ้ำจะส่งคืนผลเดิมแทนการสร้างลีด ร่าง หรือการส่งซ้ำ - ห้ามสร้างคีย์ใหม่เมื่อลองเขียนที่หมดเวลาใหม่ เก็บคีย์ไว้คู่กับ
request_idในบันทึกของตนเอง - จำเป็นสำหรับการเขียนหรือส่งจริง ใช้ UUID เดิมเมื่อลองการดำเนินการเดิมอีกครั้งโดยไม่เปลี่ยนอาร์กิวเมนต์
โควตาที่ใช้มีอะไรบ้าง
ข้อจำกัดคำขอและการใช้งานขึ้นอยู่กับสิทธิ์ของพื้นที่ทำงานและการดำเนินการ ตรวจสอบการใช้งานปัจจุบันกับผู้ดูแล เมื่อพบ quota_exceeded ให้ปฏิบัติตาม Retry-After และเวลารีเซ็ตที่ได้รับ แล้วลองใหม่โดยเพิ่มเวลารอและจำกัดจำนวนครั้ง ห้ามใช้คำขอซ้ำพร้อมกัน ไคลเอนต์เพิ่มเติม หรือนโยบายใหม่เพื่อหลีกเลี่ยงข้อจำกัด
quota_exceeded มี reset_at และ retry_after ปฏิบัติตาม Retry-After และลองใหม่ด้วย backoff แบบมีขอบเขต ห้ามกระจายการลองใหม่แบบขนานเมื่อพบ 429
วิธีเพิกถอนสิทธิ์และตรวจกิจกรรม
- เพิกถอนที่
POST /oauth/revokeหรือลบไคลเอนต์ OAuth ใน Settings → Integrations การเพิกถอนหยุดทั้งการเรียก MCP และ REST agent ของโทเค็นนั้น - ตรวจเหตุการณ์ตรวจสอบของเวิร์กสเปซสำหรับการทบทวนนโยบาย การส่ง และการเปลี่ยนนโยบาย
- ตรวจสอบการใช้งานรายวันและรายหน้าต่างก่อนเพิ่มขีดจำกัดหรือเพิ่มไคลเอนต์ใหม่
- เปลี่ยนโทเค็นใหม่ทุกครั้งที่โทเค็นปรากฏในบันทึก ภาพหน้าจอ หรือตั๋ว ห้ามส่งโทเค็นให้ฝ่ายสนับสนุน ให้ส่ง
request_idที่ลบข้อมูลสำคัญแล้ว พร้อมเวลา ชื่อเครื่องมือ และรหัสข้อผิดพลาด