ตั้ง Token แบบ Read Only กับแบบเขียนได้เต็มสิทธิ์ เสี่ยงต่างกันแค่ไหน

ทีมพัฒนาแห่งหนึ่งเปิด Supabase MCP ให้ AI Agent เชื่อมต่อกับโปรเจกต์จริงตั้งแต่วันแรกที่รู้จักเครื่องมือนี้ เพราะอยากได้ความสะดวกแบบเต็มที่ ไม่ต้องมานั่งสลับโหมดไปมา สิ่งที่เกิดขึ้นหลังจากนั้นไม่กี่สัปดาห์คือมีคำสั่งหนึ่งที่ผู้ใช้พิมพ์กำกวมเกินไป Agent ตีความว่าต้องการล้างข้อมูลทดสอบทั้งตาราง แต่ตารางนั้นดันมีข้อมูลจริงของลูกค้าปนอยู่ด้วยเพราะทีมยังไม่ได้แยกสภาพแวดล้อมทดลองออกจากของจริง โชคดีที่มีจุดสำรองข้อมูลไว้ก่อน แต่กว่าจะกู้คืนกลับมาก็เสียเวลาไปครึ่งวัน

เหตุการณ์แบบนี้ไม่ได้เกิดจากตัว Supabase MCP มีช่องโหว่ แต่เกิดจากการตั้งค่าสิทธิ์ที่กว้างเกินความจำเป็นตั้งแต่ต้น เพราะเมื่อ AI Agent เชื่อมต่อกับฐานข้อมูลได้โดยตรง มันมีพลังในการอ่านและแก้ไขข้อมูลเท่ากับ Token ที่ใช้เชื่อมต่อ ถ้า Token นั้นมีสิทธิ์เขียนข้อมูลในทุกโปรเจกต์ Agent ก็มีความสามารถระดับเดียวกัน ไม่ว่าจะตั้งใจให้ทำแค่บางอย่างหรือไม่ก็ตาม

บทความนี้จะแจกแจงว่าความเสี่ยงของ Supabase MCP มาจากจุดไหนบ้าง ต่างจากการเปิดแดชบอร์ดเองยังไง แล้วควรตั้ง Read Only กับ Project Scope อย่างไรให้ทีมได้ประโยชน์เต็มที่โดยไม่ต้องแบกความเสี่ยงเกินจำเป็น ต่อยอดจากที่เกริ่นไว้ในบทความ Supabase MCP คืออะไร และช่วยให้ AI Agent จัดการฐานข้อมูลได้อย่างไร

ทำไมเรื่องความปลอดภัยของ Supabase MCP ถึงสำคัญกว่าการเชื่อมต่อ API ทั่วไป

การเชื่อมต่อ API แบบเดิมมักถูกเขียนโค้ดไว้ตายตัวว่าให้ทำอะไรได้บ้าง เช่น หน้าเว็บนี้อ่านข้อมูลได้อย่างเดียว ปุ่มนี้แก้ไขได้เฉพาะฟิลด์ที่กำหนด แต่ AI Agent ที่เชื่อมผ่าน Supabase MCP ไม่ได้ถูกจำกัดพฤติกรรมแบบนั้น มันตัดสินใจว่าจะรันคำสั่งอะไรจากภาษาที่ผู้ใช้พิมพ์ ซึ่งภาษาธรรมชาติมีความกำกวมสูงกว่าโค้ดที่เขียนตายตัวมาก

จุดที่ต่างชัดเจนที่สุดคือความเร็วในการทำสิ่งที่ผิดพลาด ถ้าคนพิมพ์คำสั่ง SQL ผิดเองในแดชบอร์ด อย่างน้อยก็ยังต้องผ่านขั้นตอนพิมพ์และกดยืนยันด้วยตัวเอง แต่ถ้า Agent ตีความคำสั่งภาษาธรรมชาติผิดแล้วมีสิทธิ์เขียนข้อมูลอยู่แล้ว มันอาจรันคำสั่งที่ผิดได้ภายในไม่กี่วินาทีโดยที่คนไม่ทันเห็นคำสั่ง SQL จริงก่อนมันทำงาน

ด้วยเหตุนี้ หลักการตั้งค่าความปลอดภัยของ Supabase MCP จึงต้องคิดต่างจากการเปิด API ทั่วไปเล็กน้อย คือต้องคิดล่วงหน้าว่า 'ถ้า Agent ตีความคำสั่งผิดที่สุดเท่าที่จะผิดได้ ความเสียหายจะหยุดอยู่ตรงไหน' แล้วตั้งขอบเขตสิทธิ์ให้ความเสียหายที่แย่ที่สุดยังอยู่ในระดับที่รับได้เสมอ

สิ่งที่พังได้จริงถ้าเปิดสิทธิ์กว้างเกินจำเป็น

• Agent แก้ไขข้อมูลผิดตาราง — ถ้าคำสั่งกำกวมและ Token มีสิทธิ์เขียนทุกตาราง Agent อาจเลือกตารางที่ใกล้เคียงกับคำอธิบายแต่ไม่ใช่ตารางที่ผู้ใช้ตั้งใจจริง แล้วแก้ไขข้อมูลไปโดยไม่มีใครทันสังเกต
• ลบข้อมูลทดสอบปนกับข้อมูลจริง — ถ้าโปรเจกต์ทดลองกับโปรเจกต์จริงเชื่อม Token เดียวกันหรือไม่ได้แยกฐานข้อมูล คำสั่งล้างข้อมูลทดสอบอาจกวาดข้อมูลจริงไปด้วย
• Token หลุดพร้อมสิทธิ์เต็ม — ถ้า Token ที่มีสิทธิ์เขียนข้อมูลทุกโปรเจกต์ถูกเก็บไว้ในไฟล์คอนฟิกที่หลุดออกไปโดยไม่ตั้งใจ ผู้ที่ได้ Token ไปจะมีสิทธิ์เท่ากับทีมพัฒนาเองทันที
• คำสั่งลูกโซ่ที่ Agent วางแผนเองหลายขั้นตอน — Agent บางตัวสามารถวางแผนทำงานหลายขั้นตอนต่อเนื่องกันได้ ถ้าขั้นตอนแรกตีความคำสั่งผิด ขั้นตอนต่อไปที่ตามมาอาจผิดต่อเนื่องกันโดยไม่มีจุดให้คนตรวจสอบก่อนขั้นตอนสุดท้าย

Personal Access Token กับ Project Scope คืออะไรในบริบทนี้

Personal Access Token คือกุญแจที่ใช้ยืนยันตัวตนเวลา AI Agent เชื่อมต่อกับ Supabase MCP Server แทนที่จะให้คนล็อกอินเองทุกครั้ง Token นี้ผูกกับบัญชีผู้สร้างและมีสิทธิ์เท่ากับที่บัญชีนั้นมี ถ้าไม่ได้จำกัดขอบเขตไว้ Token หนึ่งอันอาจเข้าถึงได้ทุกโปรเจกต์ที่บัญชีนั้นเป็นเจ้าของหรือมีสิทธิ์อยู่

Project Scope คือการกำหนดว่า Token นั้นใช้เชื่อมกับโปรเจกต์ใดโปรเจกต์หนึ่งเท่านั้น ไม่ใช่ทุกโปรเจกต์พร้อมกัน หลักการนี้ตรงกับแนวคิดความปลอดภัยพื้นฐานที่เรียกว่าให้สิทธิ์เท่าที่จำเป็นต่องานจริง (Principle of Least Privilege) ถ้างานที่ต้องทำเกี่ยวข้องกับโปรเจกต์เดียว ก็ไม่มีเหตุผลที่ Token จะต้องมองเห็นโปรเจกต์อื่นด้วย

หลายทีมมองข้ามการตั้ง Scope เพราะคิดว่ายุ่งยากและเสียเวลาสร้าง Token หลายอัน แต่ในทางปฏิบัติ การสร้าง Token แยกตามโปรเจกต์ใช้เวลาไม่กี่นาทีต่ออัน ในขณะที่ความเสียหายจากการที่ Token เดียวเข้าถึงทุกโปรเจกต์แล้วมีปัญหาเกิดขึ้น อาจต้องใช้เวลาแก้ไขนานกว่านั้นหลายเท่า

Read Only กับ Full Access ต่างกันตรงไหนในทางปฏิบัติ

ตารางด้านล่างเทียบให้เห็นว่าเมื่อเปิดสิทธิ์สองแบบนี้ให้ Agent ความสามารถและความเสี่ยงที่ตามมาต่างกันตรงไหนบ้าง เพื่อช่วยตัดสินใจว่าโปรเจกต์แบบไหนควรเริ่มจากโหมดไหน:

ลำดับตั้งค่าที่ควรทำก่อนให้ Agent แตะฐานข้อมูลจริง

1. สร้าง Personal Access Token ใหม่เฉพาะสำหรับ MCP แยกจาก Token หรือ Key อื่นที่ใช้ในโค้ดของแอปพลิเคชัน ไม่ใช้ Token เดียวกันซ้ำหลายจุด
2. กำหนด Project Scope ให้ Token นั้นเชื่อมได้เฉพาะโปรเจกต์ที่กำลังทำงานด้วยจริง ถ้าดูแลหลายโปรเจกต์ให้สร้าง Token แยกตามโปรเจกต์
3. เปิดโหมด Read Only ไว้ก่อนเสมอในช่วงเริ่มต้น แล้วทดสอบด้วยคำถามอ่านข้อมูล เช่น ให้ Agent อธิบายโครงสร้างตารางที่มีอยู่ ก่อนพิจารณาขั้นต่อไป
4. ทดลองใช้งานกับโปรเจกต์ทดสอบที่ไม่มีข้อมูลลูกค้าจริงอยู่ระยะหนึ่ง เพื่อสังเกตว่า Agent มักตีความคำสั่งประเภทไหนผิดพลาดบ้าง
5. เมื่อพร้อมเปิดสิทธิ์เขียนข้อมูล ให้เริ่มจากตารางที่ความเสี่ยงต่ำก่อน แล้ววางขั้นตอนให้คนตรวจทานคำสั่ง SQL ก่อนกดยืนยันรันจริงทุกครั้งกับตารางสำคัญ

ทำไมควรแยกโปรเจกต์ทดลองออกจากโปรเจกต์ที่มีข้อมูลลูกค้าจริงเสมอ

ทีมจำนวนมากใช้โปรเจกต์เดียวกันทั้งตอนพัฒนาและตอนใช้งานจริง เพราะดูเหมือนประหยัดเวลาไม่ต้องตั้งค่าซ้ำสองรอบ แต่พอเริ่มเปิดให้ AI Agent เข้ามาช่วยงานผ่าน MCP ความเสี่ยงของการใช้โปรเจกต์เดียวกันจะเพิ่มขึ้นทันที เพราะคำสั่งที่ตั้งใจทดลองกับข้อมูลปลอมอาจไปกระทบข้อมูลจริงที่อยู่ในตารางเดียวกันโดยไม่ได้ตั้งใจ

การแยกโปรเจกต์ทดลองออกจากโปรเจกต์จริงไม่จำเป็นต้องซับซ้อน อาจแค่สร้างโปรเจกต์ Supabase อีกอันสำหรับทดสอบโดยเฉพาะ ใส่ข้อมูลตัวอย่างที่ไม่ใช่ข้อมูลจริงของลูกค้า แล้วให้ Agent ทำงานกับโปรเจกต์นั้นก่อนจนมั่นใจ ค่าใช้จ่ายเพิ่มเติมจากการมีอีกหนึ่งโปรเจกต์มักคุ้มค่ากว่าความเสี่ยงที่ต้องกู้คืนข้อมูลจริงหลังเกิดปัญหา

สำหรับทีมที่ยังไม่คุ้นกับโครงสร้างพื้นฐานของ Supabase มาก่อน แนะนำให้กลับไปอ่านภาพรวมในบทความ Supabase คืออะไร และทำไมถูกเลือกเป็น Backend สำหรับทีมเล็ก เพื่อให้เข้าใจว่าแต่ละโปรเจกต์แยกฐานข้อมูลออกจากกันอย่างไรก่อนจะมาตั้งค่าเรื่องสิทธิ์การเข้าถึง

สัญญาณเตือนว่าตั้งค่าหลวมเกินไปแล้ว

• Token เดียวเชื่อมได้ทุกโปรเจกต์ในองค์กร — ถ้าไม่มีเหตุผลจำเป็นจริง ๆ ที่ต้องเห็นทุกโปรเจกต์พร้อมกัน ควรแยก Token ตามโปรเจกต์แทน
• เปิดสิทธิ์เขียนข้อมูลตั้งแต่วันแรกโดยยังไม่เคยทดลองกับโปรเจกต์ทดสอบ — เป็นการข้ามขั้นตอนที่ควรใช้สังเกตพฤติกรรมของ Agent ก่อน
• ไม่มีใครในทีมตรวจสอบคำสั่ง SQL ที่ Agent รันไปแล้วย้อนหลัง — ถ้าไม่มีการทบทวนเป็นระยะ ปัญหาเล็กอาจสะสมโดยไม่มีใครรู้จนกลายเป็นเรื่องใหญ่
• ใช้ Token เดียวกันทั้งในโค้ดแอปพลิเคชันและใน MCP — ถ้า Token หลุดจากจุดใดจุดหนึ่ง ผลกระทบจะกว้างกว่าการแยก Token ตามการใช้งาน

เมื่อทีมหลายคนใช้ Supabase MCP ร่วมกัน ควรวางนโยบายยังไง

ปัญหาที่มักเกิดกับทีมขนาดกลางขึ้นไปไม่ใช่แค่เรื่องตั้งค่า Token ให้ถูกต้องคนเดียว แต่คือการทำให้ทุกคนในทีมทำตามมาตรฐานเดียวกัน ถ้าสมาชิกคนหนึ่งตั้ง Token แบบ Read Only แต่อีกคนตั้งแบบเปิดกว้างเต็มที่เพื่อความสะดวกส่วนตัว ความเสี่ยงของทั้งทีมจะสูงเท่ากับจุดที่หย่อนที่สุด ไม่ใช่ค่าเฉลี่ยของทั้งทีม

แนวทางที่ช่วยได้คือเขียนแนวปฏิบัติสั้น ๆ ให้ทุกคนอ่านก่อนเปิดใช้งาน Supabase MCP ครั้งแรก ระบุชัดว่าต้องแยก Token ตามโปรเจกต์ ต้องเริ่มจาก Read Only เสมอ และห้ามใช้กับโปรเจกต์ที่มีข้อมูลลูกค้าจริงจนกว่าจะผ่านการทดลองในโปรเจกต์ทดสอบมาก่อน แนวปฏิบัติแบบนี้ไม่จำเป็นต้องยาวหรือซับซ้อน แต่ต้องมีคนคอยตรวจว่าทุกคนทำตามจริง ไม่ใช่แค่เขียนไว้เฉย ๆ

สรุป

ความเสี่ยงของ Supabase MCP ไม่ได้อยู่ที่ตัวเครื่องมือ แต่อยู่ที่วิธีที่ทีมตั้งค่าสิทธิ์ให้ AI Agent เข้าถึงฐานข้อมูล หลักที่ควรยึดไว้เสมอคือให้สิทธิ์เท่าที่จำเป็นต่องานจริง เริ่มจาก Read Only และ Project Scope ที่แคบที่สุดเท่าที่ยังใช้งานได้ แล้วค่อยขยายเมื่อเข้าใจพฤติกรรมของ Agent ดีพอ

ทีมที่เพิ่งเริ่มเปิดใช้ Supabase MCP ควรทดลองกับโปรเจกต์ทดสอบก่อนเสมอ แล้ววางแนวปฏิบัติร่วมกันให้ทุกคนในทีมทำตามมาตรฐานเดียวกัน เพราะความปลอดภัยของทั้งระบบขึ้นอยู่กับจุดที่หย่อนที่สุด ไม่ใช่คนที่ตั้งค่าดีที่สุดในทีม

• ใช้ Personal Access Token แยกตามโปรเจกต์ ไม่ใช้ Token เดียวเชื่อมทุกโปรเจกต์พร้อมกัน
• เริ่มจากโหมด Read Only เสมอ แล้วค่อยเปิดสิทธิ์เขียนข้อมูลเมื่อมั่นใจในพฤติกรรมของ Agent แล้ว
• แยกโปรเจกต์ทดลองออกจากโปรเจกต์ที่มีข้อมูลลูกค้าจริงอย่างเด็ดขาด
• วางแนวปฏิบัติร่วมกันในทีม เพื่อไม่ให้ความปลอดภัยขึ้นอยู่กับจุดที่หย่อนที่สุดของคนใดคนหนึ่ง

คำถามที่พบบ่อย