AI Agent ที่เชื่อมต่อฐานข้อมูลอาจช่วยตอบคำถามหรือจัดการคำสั่งซื้อ แต่ถ้าออกแบบสิทธิ์พลาด มันก็อาจทำสิ่งที่ไม่ควรทำกับข้อมูลได้ ปัญหาจึงไม่ใช่แค่คำตอบผิด แต่รวมถึงอำนาจที่ระบบเปิดให้ AI ใช้ด้วย
ประเด็นนี้มาจากคลิป Build-Time vs. Run-Time โดย Averi Kitsch และ Prerna Kakkar จาก Google ทางช่อง AI Engineer ซึ่งอธิบายเส้นแบ่งระหว่างเครื่องมือระหว่างพัฒนาและเครื่องมือที่ผู้ใช้เรียกผ่านแอปจริง รวมถึงแนวทางกำหนดสิทธิ์เข้าถึงข้อมูล ตัวอย่างธุรกิจไทยในบทความเป็นข้อเสนอของ VibeSolo สำหรับนำไปตรวจงานของตัวเอง
แยกให้ออกว่า AI กำลังช่วย “สร้าง” หรือกำลัง “ให้บริการจริง”
ผู้พูดเสนอให้แยกเครื่องมือตามการใช้งาน เพราะเครื่องมือที่เหมาะกับทีมเทคนิคอาจเปิดอิสระมากเกินไปสำหรับระบบที่ลูกค้าหรือพนักงานใช้ทุกวัน
Build Time คือช่วงสร้างและทดลองระบบ เช่น ให้ AI ช่วยสร้างฐานข้อมูล จัดการระบบฐานข้อมูล หรือเขียน SQL ตามคำถามที่ยังไม่เคยเตรียมไว้ SQL คือภาษาสำหรับสั่งงานฐานข้อมูล เครื่องมือกลุ่มนี้ทำงานย่อยได้อย่างยืดหยุ่น เช่น สร้าง ลบ แก้ไข หรือค้นข้อมูลโดยตรง
Run Time คือช่วงที่ AI อยู่ในแอปใช้งานจริง เช่น แชตบอตตรวจคำสั่งซื้อหรือผู้ช่วยจองบริการ ในกรอบที่ผู้พูดนำเสนอ เครื่องมือจึงควรทำเฉพาะงานที่กำหนดไว้ พร้อมเงื่อนไขและสิทธิ์ที่ระบบควบคุม
ผู้พูดเตือนเรื่องการนำเครื่องมือสำหรับนักพัฒนาไปใช้กับงานจริงโดยตรง เพราะความยืดหยุ่นของเครื่องมืออาจทำให้ AI เลือกการกระทำที่กระทบข้อมูลได้ ตัวอย่างในคลิปแยกเครื่องมือที่เขียน SQL เองจากเครื่องมือที่กำหนดคำสั่งไว้ล่วงหน้า
เมื่อนำมาคิดต่อกับธุรกิจไทย VibeSolo ยกตัวอย่างว่า งานวิเคราะห์การซื้อซ้ำอาจต้องการคำถามที่ยืดหยุ่น แต่แชตบอตที่ตอบว่า “ออเดอร์ของฉันอยู่ไหน” ควรใช้คำสั่งและสิทธิ์เฉพาะลูกค้ารายนั้น แทนการเปิดข้อมูลทุกคนให้ AI เลือกเอง
เลือกชนิดของเครื่องมือให้เหมาะกับความเสี่ยง
ผู้พูดแบ่งรูปแบบเครื่องมือฐานข้อมูลที่พบจากงานของทีมออกเป็น 3 กลุ่ม:
1. เครื่องมือดูแลระบบฐานข้อมูล
Control Plane Tools คือเครื่องมือดูแลโครงสร้างระบบ เช่น สร้างฐานข้อมูล จัดการระบบฐานข้อมูล หรือช่วยผู้ดูแลฐานข้อมูล ผู้พูดแนะนำให้มนุษย์ร่วมตรวจการกระทำของเครื่องมือประเภทนี้ เพราะอาจมีคำสั่งที่กระทบระบบได้
2. แปลงคำถามเป็น SQL
Natural Language to SQL คือให้ AI รับคำถามภาษาธรรมชาติแล้วสร้าง SQL เพื่อหาคำตอบ ตัวอย่างของผู้พูดคือค้นหาลูกค้าในแคลิฟอร์เนียที่ซื้อเสื้อกันหนาวในเดือนกรกฎาคม คืนสินค้าภายใน 14 วัน แล้วจัดกลุ่มตามแคมเปญการตลาดที่ได้ลูกค้ากลุ่มนั้นมา
ผู้พูดวางกลุ่มนี้ไว้สำหรับช่วยนักพัฒนาและวิเคราะห์คำถามเฉพาะหน้า ซึ่งยังไม่รู้ล่วงหน้าว่าต้องใช้คำสั่งใด เพราะ AI เป็นผู้สร้างคำสั่ง ระบบจึงยังต้องตรวจว่าสิ่งที่เรียกเหมาะกับขอบเขตงานหรือไม่
3. กำหนด SQL ไว้ล่วงหน้า
Structured SQL Tools คือเครื่องมือที่กำหนด SQL ที่อนุญาตไว้ล่วงหน้า แล้วเปิดให้ AI ส่งเฉพาะค่าที่จำเป็น เช่น วันที่ ผู้พูดเสนอรูปแบบนี้สำหรับงานใช้งานจริงที่รู้คำสั่งและต้องควบคุมการเข้าถึง
ผู้พูดยก cancel_order เป็นตัวอย่างเครื่องมือที่ผูกกับคำสั่ง SQL ที่กำหนดไว้ ในการประยุกต์ของ VibeSolo เครื่องมือยกเลิกคำสั่งซื้อควรมีเงื่อนไขของธุรกิจและตรวจสิทธิ์ผู้ใช้ในระบบด้วย
ตามที่ผู้พูดอธิบาย คำสั่งที่กำหนดไว้ช่วยจำกัดตรรกะที่ AI เรียกและลดภาระสร้างคำสั่งใหม่ ต่อมาเธออธิบายการใช้ prepared statements ซึ่งแยกค่าที่ป้อนออกจากคำสั่ง SQL และตรวจชนิดค่าป้อนเพื่อลดความเสี่ยง SQL injection หรือการแทรกข้อมูลให้กลายเป็นคำสั่งฐานข้อมูล ข้อเสนอเหล่านี้ไม่ใช่การรับรองว่าระบบปลอดช่องโหว่ทุกด้าน
อย่าให้ AI ถือกุญแจทุกดอกของฐานข้อมูล
ผู้พูดเล่าตัวอย่างเครื่องมือระหว่างพัฒนาที่เจอข้อผิดพลาด แล้ว AI เลือกให้ลบตารางและเริ่มใหม่โดยไม่มีข้อจำกัดที่หยุดการกระทำนี้ บทความอ้างถึงคำอธิบายในคลิป ไม่ได้รันการทดลองนี้ซ้ำหรือสรุปว่าเป็นเหตุการณ์ในระบบลูกค้าจริง
ในส่วนถัดมา ผู้พูดย้ำว่าความปลอดภัยของฐานข้อมูลสัมพันธ์กับสิทธิ์ที่ให้ Agent แนวทางที่เธอเสนอจึงย้ายรายละเอียดและเงื่อนไขสำคัญออกจากการควบคุมของ AI ไปไว้ในเครื่องมือและแอป
กลไกที่คลิปอธิบายมีการจำกัดสิทธิ์อ่านอย่างเดียว แยกเครื่องมืออ่านกับเขียน กำหนดชุดข้อมูลที่อนุญาต และจำกัดขนาดผลลัพธ์ ส่วนเดโม runtime ที่วางแผนฉายไม่สามารถเปิดได้ ผู้พูดจึงเล่าพฤติกรรมของเดโมจองเที่ยวบินและอธิบายจากสไลด์ต่อ ไม่ใช่ผลสาธิตที่บทความตรวจยืนยันจากการทำงานสด
เข้าใจ Confused Deputy Attack ก่อนข้อมูลธุรกิจรั่ว
ผู้พูดอธิบาย Confused Deputy Attack ว่าเป็นสถานการณ์ที่ผู้ใช้หลอกให้ Agent ใช้อำนาจของตัวเองไปเข้าถึงข้อมูลที่ผู้ใช้นั้นไม่มีสิทธิ์
ตัวอย่างสมมติในคลิปคือ Agent อ่าน ticket หรือรายการแจ้งปัญหา ไปค้นฐานข้อมูล แล้วโพสต์ผลกลับลงรายการเดิม ผู้ไม่หวังดีใส่ข้อความให้ค้นเงินเดือนพนักงานทั้งหมด หาก Agent ถือสิทธิ์ดังกล่าวและทำตามข้อความนั้น ข้อมูลก็อาจกลับไปหาคนที่ไม่ควรเข้าถึงได้ ตัวอย่างนี้ใช้แสดงรูปแบบความเสี่ยง ไม่ใช่รายงานข้อมูลรั่วที่เกิดขึ้นจริง
ผู้พูดเชื่อมกรณีนี้กับสิ่งที่เรียกว่า lethal trifecta คือการมีข้อมูลลับ เนื้อหาที่ไม่น่าเชื่อถือ และช่องทางส่งผลกลับไปยังผู้ใช้ภายนอกพร้อมกัน ในบทความนี้ใช้เป็นคำอธิบายรูปแบบความเสี่ยงตามคลิป ไม่ใช่ตัวเลขประเมินโอกาสเกิดข้อมูลรั่ว
ในการประยุกต์ของ VibeSolo ข้อความแชตลูกค้า ไฟล์แนบ อีเมล ฟอร์ม รีวิว หรือโน้ตในระบบลูกค้าเป็นตัวอย่างข้อมูลที่ควรแยกจากคำสั่งและสิทธิ์ของระบบ
แยกตัวตน 3 ชั้นให้ชัดเจน
ผู้พูดเสนอให้แยกตัวตนและสิทธิ์เป็น 3 ชั้น:
- ตัวตนผู้ใช้ ผู้ใช้ปลายทางต้องมีสิทธิ์ตามงานของตัวเอง
- ตัวตนแอปพลิเคชัน แอปอาจมีสิทธิ์กว้างกว่าเพราะต้องคุยกับหลายบริการ
- ตัวตน Agent Agent ในแอปควรเข้าถึงข้อมูลเท่าที่ผู้ใช้ปลายทางของคำขอนั้นจำเป็นต้องใช้
ตัวอย่างร้านค้าเป็นการประยุกต์ของ VibeSolo: เมื่อลูกค้าเข้าสู่ระบบ แอปจะผูกรหัสผู้ใช้จากการยืนยันตัวตนเข้ากับเครื่องมือตรวจคำสั่งซื้อโดยตรง AI จัดการข้อมูลคำถาม เช่น ช่วงเวลา โดยไม่ต้องเลือกว่ากำลังค้นข้อมูลให้ลูกค้าคนใด
ย้ายสิ่งสำคัญออกจากการควบคุมของ AI
ในตัวอย่างวิวัฒนาการของเครื่องมือ ผู้พูดเริ่มจาก AI ที่เข้าถึงข้อมูลการเชื่อมต่อฐานข้อมูลและ SQL ดิบ แล้วค่อยย้ายรายละเอียดเหล่านี้ไปไว้ใน MCP Toolbox โดยตั้งค่าการเชื่อมต่อในระบบก่อนเรียกเครื่องมือ
สิ่งที่เธอค่อยๆ ย้ายออกจากการควบคุมของ Agent ได้แก่ รายละเอียดการเชื่อมต่อ คำสั่ง SQL หลัก และข้อมูลระบุตัวบุคคล หรือ PII เช่นรหัสผู้ใช้และอีเมล จนเครื่องมือค้นหาเที่ยวบินในตัวอย่างรับเพียงวันที่
ชั้นควบคุมที่ผู้พูดอธิบายมีดังนี้:
- อ่านอย่างเดียว ตัดเครื่องมือเขียนและจำกัดการเขียนถึงระดับตัวเชื่อมฐานข้อมูลเมื่องานไม่ต้องเขียน
- ชุดข้อมูลที่อนุญาต จำกัดตารางหรือชุดข้อมูลที่เครื่องมือเข้าถึง
- ขนาดผลลัพธ์ จำกัดปริมาณข้อมูลที่ดึงแต่ละครั้ง
- SQL ที่กำหนดไว้ ใช้คำสั่งที่เตรียมไว้กับค่าป้อนที่ตรวจชนิดแล้ว
ข้อเสนอของ VibeSolo สำหรับระบบอื่นคือสำรวจว่าสามารถย้ายเงื่อนไขที่ไม่ควรให้ AI เลือกไปไว้ในแอปและนโยบายฐานข้อมูลได้อย่างไร แต่ความสามารถและการบังคับใช้ต้องตรวจจากระบบที่เลือกจริง
ออกแบบเครื่องมือให้ AI เข้าใจหน้าที่และข้อจำกัด
ผู้พูดแนะนำให้เครื่องมือเน้นผลลัพธ์ที่งานต้องการ แทนการแตกตามคำสั่ง API ย่อยทุกขั้น พร้อมตั้งชื่อและคำอธิบายที่ช่วยให้ Agent รู้ว่าจะเรียกใช้เมื่อใด
ในมุมของ VibeSolo การตั้งเครื่องมือให้สะท้อนงาน เช่น ค้นเที่ยวบินหรือเปลี่ยนการจอง ช่วยให้ตรวจขอบเขตของแต่ละงานได้ชัด ส่วนจำนวนครั้งที่เรียกเครื่องมือและความถูกต้องของลำดับยังต้องวัดในระบบจริง
คำแนะนำเรื่องคุณภาพเครื่องมือในคลิปประกอบด้วย:
- ใช้ชื่อและคำอธิบายชัดเจน โดยไม่ย้ำข้อมูลค่าป้อนที่ Agent เห็นอยู่แล้ว
- แยกเครื่องมืออ่านกับเขียน เพื่อกำหนดการยืนยันตามการกระทำ
- ส่งข้อผิดพลาดที่บอกได้ว่าลองใหม่หรือแก้ค่าป้อนได้หรือไม่
- ใช้ค่าป้อนที่เรียบง่าย แทนโครงสร้างซับซ้อน
ผูก PII กับระบบยืนยันตัวตน ไม่ใช่กับคำสั่งของ AI
ผู้พูดยกปัญหารหัสผู้ใช้เป็นตัวอย่าง แม้ SQL ถูกกำหนดไว้แล้ว แต่ถ้า Agent เลือกหรือเปลี่ยนรหัสผู้ใช้ได้ ก็ยังเสี่ยงเรียกข้อมูลผิดคน เธอจึงเสนอให้ย้ายค่าระบุตัวตนออกจากการควบคุมของ Agent
Bound Parameters คือการที่แอปยืนยันตัวตนก่อนแล้วผูกรหัสผู้ใช้เข้ากับเครื่องมือ Agent จึงไม่เห็นและไม่เลือกค่านี้เอง เครื่องมือค้นหาเที่ยวบินในตัวอย่างจึงเหลือค่าป้อนเพียงวันที่
อีกวิธีที่คลิปอธิบายคือ authenticated parameters โดยให้เครื่องมือรับโทเคนตัวตน ตรวจว่าโทเคนถูกต้อง แล้วดึงข้อมูลตัวตนที่ยืนยันแล้ว เช่นรหัสผู้ใช้ อีเมล และผู้ให้โทเคน มาใช้ในคำขอ รายละเอียดการตรวจในระบบจริงต้องเป็นไปตามวิธีของเครื่องมือที่เลือก
บทเรียนที่ VibeSolo ชวนตรวจคือแยกความต้องการที่ AI อ่านจากคำถาม ออกจากสิทธิ์ที่ระบบตรวจและบังคับใช้
แหล่งที่มา: Build-Time vs. Run-Time โดย Averi Kitsch และ Prerna Kakkar จาก Google ทางช่อง AI Engineer อัปโหลดวันที่ 9 กันยายน 2026 เวลาไทย บทความนี้สรุปคำอธิบายและสิ่งที่ผู้พูดรายงาน โดยแยกข้อเสนอของ VibeSolo ไว้ในส่วนประยุกต์ วันอัปโหลดไม่ใช่วันจัดงานหรือวันเผยแพร่บทความนี้
