Knowledge Engineering · Action

SQL ของทีมคุณมีคนรีวิว แต่ SQL ของ Agent วิ่งตรงเข้าฐานข้อมูล

ทุก Query ที่ทีมโปรแกรมเมอร์เขียน ต้องผ่านการรีวิวก่อนจะไปถึง Production แต่สำหรับ AI คุณก็ต่อ AI Agent เข้ากับฐานข้อมูลเดียวกัน และ SQL ที่มันเขียนก็รันทันทีที่เขียนเสร็จ ช่องโหว่ตรงนี้คือ Query ที่ไม่มีใครตรวจสอบ จึงเป็น Query ที่ต้องระวังมากที่สุด ทำไมถึงเป็นแบบนั้น? เพราะ AI ที่ถูกหลอกให้ทำอะไรก็ได้ กำลังเขียน Statement มาใช้กับข้อมูลจริงของคุณ ดังนั้นทางออกคือเลเยอร์ข้อมูลที่มี Governance ซึ่งเอาการรีวิวนั้นกลับคืนมา ทุก Statement ที่ Agent เขียนจะถูก Parse และพิสูจน์ว่าปลอดภัย ก่อนที่ Cursor จะเปิดด้วยซ้ำ

Infozense Knowledge Engineering · CIO · CISO · Head of Data · ~6 นาที

นี่คือบท Action ของชุดบทความ Infozense Knowledge Engineering เลเยอร์ข้อมูลที่อยู่ใต้ Agent ของคุณมี Gate อยู่ห้าตัว: Input (ใครมีสิทธิ์ถาม) · Egress (อะไรออกไปได้) · Output (ปลอดภัยและเป็นจริง) · Action (ใครอนุมัติ) · Operational (พิสูจน์ได้ภายหลัง) บทความนี้ว่าด้วยตัวที่สี่: Action Gate ที่ตัดสินว่า AI ของคุณได้รับอนุญาตให้ลงมือทำอะไรกับระบบจริงได้บ้าง

สองเส้นทางสู่ฐานข้อมูลเดียวกัน: SQL ของโปรแกรมเมอร์ผ่านการรีวิวก่อนจะไปถึงฐานข้อมูล ส่วน SQL ของ AI Agent ไม่ผ่านอะไรเลย
ทั้งสองเส้นทางสิ้นสุดที่ข้อมูลเดียวกัน แต่มีเพียงเส้นทางเดียวที่มีคนอ่านก่อน

ทีมโปรแกรมเมอร์ของคุณไม่ได้เขียน SQL ลง Production ตรง ๆ ต้องมีใครสักคนรีวิวก่อน อาจเป็น Pull Request อาจเป็น DBA หรืออย่างน้อยที่สุดก็มีอีกคนมาช่วยตรวจก่อน คุณสร้างแนวทางนี้ขึ้นมาเพราะ Query ไม่ใช่คำถาม แต่ Query คือคำสั่ง และคำสั่งที่กระทำกับข้อมูลจริงสมควรได้รับการตรวจดูก่อนที่มันจะรัน

แล้วคุณก็ต่อ AI Agent เข้ากับฐานข้อมูลเดียวกัน เพราะเอกสารกับข้อมูลในฐานข้อมูลตอบคำถามคนละแบบ เอกสารบอกได้ว่านโยบายเขียนไว้อย่างไร ส่วนคำถามว่าไตรมาสที่แล้วตัวเลขเป็นเท่าไร ต้องใช้ Query เท่านั้น

และ SQL ที่ Agent ตัวนั้นเขียน ก็รันทันทีที่เขียนเสร็จ

ไม่มี Pull Request ไม่มี DBA ไม่มีใครมาช่วยตรวจ ในองค์กรของคุณ มี Query อยู่กลุ่มเดียวที่ไม่มีใครอ่าน นั่นคือ Query ที่เขียนโดยสิ่งที่น่าไว้ใจน้อยที่สุด เพราะมันคือสิ่งเดียวที่ถูกหลอกให้เขียนสิ่งที่ไม่เคยมีใครตั้งใจให้มันเขียนออกมาได้

บทความนี้เขียนถึงใคร

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

คุณมีปัญหานี้ทันทีที่ Agent ถือ Connection ของฐานข้อมูลไว้ ไม่ว่าจะเป็น Text to SQL บน Data Warehouse หรือ Copilot ที่ตอบจากตารางข้อมูลปฏิบัติการ หรือผู้ช่วยตัวไหนก็ตามที่ต่อกับ Replica สำหรับงานรายงานเพื่อให้อ้างตัวเลขจริงได้ ถ้าคนแปลกหน้าวางข้อความไว้ตรงหน้า Agent ตัวนั้นได้ และ Agent เปลี่ยนข้อความเป็น SQL คนแปลกหน้าก็กำลังเขียน Statement มากระทำกับข้อมูลของคุณ คนคนนั้นไม่ต้องเจาะระบบ และไม่ต้องเขียน SQL เองเลย ขอแค่รู้ว่าจะใช้คำแบบไหนให้ Agent เขียนให้ ทำให้ความเสี่ยงทั้งหมดอยู่ตรงนี้

โมเดลไม่ใช่ผู้โจมตี แต่มันถูกใช้เป็นเครื่องมือ

ข้อความเข้ามาจากสองทาง: คำถามจากผู้ใช้ของคุณ และข้อความจากที่อื่น เช่น เอกสาร ใบงาน หรือหน้าเว็บที่ Agent ถูกสั่งให้อ่าน จากนั้นโมเดลแปลงคำสั่งที่เขียนมาในรูปข้อความให้เป็น SQL และแยกไม่ออกว่าข้อความใดเป็นของคุณ ส่วน Agent เป็นผู้รันสิ่งที่โมเดลเขียนขึ้น และเป็นผู้ถือ Connection กับ Credential เอาไว้ แล้ว Statement นั้นก็ไปถึงฐานข้อมูลของคุณ
ทุกส่วนทำหน้าที่ของตัวเอง โมเดลที่เก่งขึ้นจึงแก้เรื่องนี้ไม่ได้

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

สมมติฐานที่ใช้งานได้จริงจึงเป็นข้อที่ฟังแล้วไม่สบายใจ นั่นคือ ให้ปฏิบัติต่อทุก Statement ที่ Agent ของคุณเขียนออกมา ราวกับผู้โจมตีเป็นคนเขียน ไม่ใช่เพราะโมเดลมุ่งร้าย แต่เพราะข้อความที่มันอ่านเข้าไปอาจมุ่งร้าย และเมื่อมองจากข้างใน ไม่มีวิธีที่เชื่อถือได้ที่จะแยกสองกรณีนี้ออกจากกัน

เมื่อคุณตั้งสมมติฐานแบบนี้แล้ว คำถามจะเปลี่ยนจาก “โมเดลน่าไว้ใจหรือไม่” ไปเป็น “Statement นี้ได้รับอนุญาตให้ทำอะไรบ้าง” และคำถามข้อหลังมีคำตอบ

การตรวจอย่างถูกต้องจริง ๆ หมายความว่าอย่างไร

Action Gate พิสูจน์ Statement ของ Agent ก่อนที่ Connection ใด ๆ จะเปิด กล่าวคือ ต้องเป็น Statement เดียวเท่านั้น Statement นั้นต้องอ่านอย่างเดียว ตารางและคอลัมน์ทุกชื่อต้องเทียบได้กับ Catalog Card ส่วนฟังก์ชันทุกตัวต้องอยู่ใน Allow-list และจะถูกปฏิเสธเว้นแต่ทั้งหมดนี้จะพิสูจน์ได้ ต่อเมื่อครบทั้งหมดนั้นแล้วเท่านั้น Cursor จึงจะเปิดบนฐานข้อมูล
Statement ถูกพิสูจน์ก่อน ถ้ายังไม่ได้ ก็ไม่มี Cursor ไหนเปิด

ทางลัดที่หลายคนเลือกใช้คือการไล่หาคำอันตรายใน SQL มองหา DROP มองหา DELETE บล็อกทุกอย่างที่มีเครื่องหมาย Semicolon วิธีนี้ไม่ได้แค่ไม่ช่วย แต่อันตรายกว่าการไม่ทำอะไรเลย เพราะมันทำให้รู้สึกปลอดภัยทั้งที่ไม่ปลอดภัยจริง คำสั่งเดียวกันใน SQL เขียนได้หลายแบบเกินไป และ String ที่รอดจากการตรวจ Keyword มาได้ ก็ยังก่อความเสียหายได้

การตรวจที่แท้จริงหมายถึงการ Parse โดยในเลเยอร์ข้อมูลที่มี Governance นั้น SQL ของ Agent จะถูกส่งเข้า SQL Parser ของจริง แล้วไล่ตรวจ Syntax Tree ที่ได้ออกมาทั้งต้น ก่อนที่จะมีการเปิด Connection ใด ๆ ไปยังฐานข้อมูล การตรวจนี้จะพิสูจน์สิ่งที่กำหนดไว้ทั้งชุด และปฏิเสธทุกอย่างที่พิสูจน์ไม่ได้:

  • มันเป็น Statement เดียวเท่านั้น ไม่ใช่สอง และไม่ใช่ Statement ที่มี Comment ซ่อน Statement ที่สามเอาไว้ ข้อที่เหลือทั้งหมดพิสูจน์ไว้กับ Statement เดียว ถ้ามี Statement ที่สองแอบตามเข้ามา ก็จะไม่มีอะไรพิสูจน์มันเลย
  • Statement นั้นอ่านได้อย่างเดียว จะเป็น SELECT หรือ UNION หรือ WITH ก็ได้ ส่วนอะไรก็ตามที่เพิ่ม แก้ไข หรือลบข้อมูล ไม่ว่าจะเป็น INSERT UPDATE DELETE หรือ DROP จะถูกปฏิเสธทันที ไม่ใช่แค่เตือน และซ่อนไว้ตรงไหนใน Statement ก็ถูกจับได้
  • ตารางทุกตารางและคอลัมน์ทุกคอลัมน์ต้องเทียบได้กับ Catalog Card ของ Connection นั้น ชื่อใดที่เทียบไม่ได้ว่าตรงกับตารางและคอลัมน์จริงเพียงหนึ่งเดียว จะถูกปฏิเสธ ซึ่งหมายความว่า Agent ไม่มีทางเข้าถึงตารางได้ด้วยการเอ่ยชื่อตารางที่ไม่เคยถูกยื่นให้มันใช้
  • ฟังก์ชันทุกตัวต้องอยู่ใน Allow-list ได้แก่ ฟังก์ชันรวมยอด เลขคณิต การจัดการ String และวันที่ ซึ่งเป็นสิ่งที่งานวิเคราะห์ต้องใช้จริง ฟังก์ชันที่ไม่อยู่ในรายการคือการปฏิเสธ และที่ใช้ Allow-list แทน Block-list ก็เพราะฟังก์ชันคือจุดที่ฐานข้อมูลเก็บช่องทางออกนอกกรอบเอาไว้ บางฟังก์ชันอ่านไฟล์ได้ หรือติดต่อออกไปยังเครือข่ายได้ ทั้งที่อยู่ในคำสั่งอ่านที่ดูไม่มีพิษภัย และ Allow-list จะปฏิเสธฟังก์ชันอันตรายที่ยังไม่มีใครรู้จัก พร้อมกับฟังก์ชันที่ทุกคนรู้จักดีอยู่แล้ว
  • กลเม็ดต่าง ๆ ถูกปฏิเสธแบบระบุชื่อไว้ชัด รวมถึงเครื่องหมาย Comment แบบสั่งรันได้ ที่ฐานข้อมูลบางตัวแอบรันเป็น SQL จริง สิ่งเหล่านี้ถูกคัดทิ้งก่อนที่การ Parse จะเริ่มด้วยซ้ำ เพราะ Parser อ่าน Comment เป็นเหมือนไม่มีอะไรอยู่ตรงนั้น ขณะที่ฐานข้อมูลจะรัน Comment นั้นเป็นโค้ด และการพิสูจน์ Statement ที่ Parse แล้ว ย่อมไม่มีค่าอะไรเลย ถ้าฐานข้อมูลไปรัน Statement คนละตัว

การตรวจทั้งหมดทำงานเป็น Pure Function หรือการคำนวณที่รับ Statement เข้าไป ตอบว่าผ่านหรือไม่ผ่าน แล้วไม่ไปยุ่งกับอะไรอีกเลย มันไม่เปิด Connection และไม่อ่านข้อมูล ไม่มีใครทำให้มันรั่วไหลด้วยการถามคำถามผิด ๆ ได้ เพราะมันไม่มีอะไรให้รั่ว

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

สิทธิ์ในการรัน คัดลอกไม่ได้ และเก็บไว้ใช้ทีหลังไม่ได้

มีจุดพลาดอยู่จุดหนึ่งที่ควรพูดถึง เพราะเป็นจุดที่ระบบซึ่งทีมสร้างขึ้นเองมักพัง ถ้าการอนุมัติคือ Token คือ Flag หรือคือแถวหนึ่งในตารางที่บอกว่า “Query นี้ตรวจแล้ว” การอนุมัตินั้นก็ถูกคัดลอก ถูกเอาไปใช้ซ้ำ หรือถูกปลอมขึ้นได้ และการตรวจก็กลายเป็นแค่พิธีกรรม ตั้งแต่ครั้งแรกที่มีอะไรสักอย่างเอาการอนุมัติของเมื่อวานมาใช้กับ Query ของวันนี้

ในเลเยอร์ข้อมูลที่มี Governance การอนุมัติไม่ใช่ข้อมูล แต่เป็น Object ที่เกิดขึ้นสด ๆ ตอนตรวจ ซึ่งมีเพียงตัวตรวจเท่านั้นที่สร้างได้ และตั้งใจออกแบบให้จดบันทึกหรือส่งต่อไปที่ไหนไม่ได้ ตัวที่เปิด Connection ของฐานข้อมูลจะไม่ยอมเปิด หากไม่ได้รับ Object นั้นส่งถึงมือโดยตรง เมื่อการอนุมัติเก็บลงไฟล์หรือส่งต่อไม่ได้ ก็ไม่มีใครขโมยไปใช้ ไม่มีใครเอาไปใช้ซ้ำ และไม่มีอะไรสร้างมันขึ้นมาได้ นอกจากการตรวจเอง

อะไรได้รัน และอะไรถูกบันทึกไว้

มีอีกสองสิ่งที่เป็นจริงพร้อมกัน และมันสำคัญกับใครก็ตามที่ต้องรับผิดชอบเรื่องนี้ในภายหลัง

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

และทุกความพยายามถูกบันทึกไว้ รวมถึงการปฏิเสธทุกครั้ง Statement ที่ถูกปฏิเสธไม่ใช่เรื่องว่างเปล่าที่ปล่อยผ่านไปได้ มันคือบรรทัดที่น่าสนใจที่สุดใน Log เพราะความพยายามมีหน้าตาแบบนี้เอง บันทึกเก็บตัว Statement กับจำนวนแถวไว้ แต่ไม่เก็บตัวแถวข้อมูล

ข้อสรุป

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

แนวทางนั้นไม่ติดไปเอง คุณต้องสร้างมันขึ้นใหม่ตรงจุดที่ Statement เจอกับข้อมูล และต้องทำงานด้วยการพิสูจน์ ไม่ใช่ด้วยความระแวง นั่นคือ Statement เดียวที่อ่านอย่างเดียว เฉพาะตารางและคอลัมน์ที่ Connection นั้นได้รับมอบไว้ เฉพาะฟังก์ชันที่งานวิเคราะห์ต้องใช้ ปฏิเสธไว้ก่อนถ้าพิสูจน์ไม่ได้ และสิทธิ์ในการรันที่ปลอมไม่ได้

SQL ของทีมคุณมีคนรีวิว ส่วน SQL ของ Agent ต้องรีวิวให้เข้มกว่านั้น และต้องรีวิวทุกครั้งไม่มีข้อยกเว้น ในไม่กี่มิลลิวินาทีก่อนที่ Cursor จะเปิด

คุณไม่ได้สร้างมัน คุณแค่ตั้งค่ามัน

ทั้งหมดนี้ไม่ใช่โมเดลที่คุณต้องเทรน และไม่ใช่คิวของการรีวิวที่คุณต้องจัดคนมาประจำเอาไว้ Infozense Knowledge Engineering ส่งมอบเลเยอร์ข้อมูลที่มี Governance พร้อม Action Gate ติดตั้งไว้แล้ว คุณเพียงลงทะเบียน Connection และตารางที่อนุญาตให้มันแตะต้องได้ แล้วทุก Statement ที่ Agent ของคุณเขียนจะถูก Parse ถูกพิสูจน์ ถูกรันภายในขอบเขตของคุณ และถูกบันทึกลง Ledger ไว้ Agent ของคุณได้ใช้ข้อมูลจริงของคุณ แต่ไม่ได้รับความไว้ใจในข้อมูลนั้น

Infozense Knowledge Engineering

คุณเพิ่งให้ Connection ของฐานข้อมูลกับ Agent ไปหรือเปล่า?

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

คุยกับเรา →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand