ผมได้ให้เอเจนต์ AI เข้าถึงข้อมูลการเงินของครอบครัวและให้มันสื่อสารกับผมผ่าน MCP server เพียงไม่กี่นาที มันก็สามารถตอบคำถามได้ว่า “เดือนที่แล้วเราจ่ายค่าของชำไปเท่าไหร่?” และสามารถย้ายเงินเข้าบัญชีออมทรัพย์ได้ แต่ในขณะเดียวกัน อินเทอร์เฟซเดียวกันนี้ก็ยอมให้มันลบประวัติการทำธุรกรรมทั้งปีทิ้งได้ด้วยคำสั่งเพียงคำสั่งเดียว สิ่งที่หยุดการลบนั้นไว้ได้ไม่ใช่ system prompt ที่ชาญฉลาด แต่เป็นระบบตรวจสอบความปลอดภัยที่เขียนไว้ในตัวเครื่องมือ (hard-coded safety check) ที่เอเจนต์เรียกใช้งาน
ทำไมปัญหานี้ถึงสำคัญ
เอเจนต์ AI ที่เรียกใช้งานบริการภายนอกกำลังเปลี่ยนผ่านจากเพียงแค่ตัวสาธิตในงานวิจัยไปสู่การเป็นผู้ช่วยในชีวิตประจำวัน บอทจัดการงบประมาณที่สามารถอ่านข้อความแจ้งเตือนจากธนาคาร วิเคราะห์จำนวนเงิน และบันทึกลงในแอปการเงินส่วนบุคคลนั้นมีอยู่จริงแล้วในปัจจุบัน รูปแบบเดียวกันนี้ยังถูกนำไปใช้กับแชทบอทสนับสนุนลูกค้า, เครื่องมือช่วยเขียนโค้ด และผู้วางแผนห่วงโซ่อุปทาน เมื่อใดก็ตามที่เอเจนต์สามารถออกคำสั่งที่ เปลี่ยนแปลง (mutating) หรือ ทำลาย (destructive) ข้อมูลได้—เช่น ลบไฟล์, ลบตารางในฐานข้อมูล หรือจัดสรรเงินใหม่—ความเสี่ยงจะพุ่งสูงขึ้นทันที คำขอที่ถูกตีความผิดเพียงครั้งเดียว, เหตุการณ์ model drift หรือ prompt ที่ประสงค์ร้าย สามารถสร้างความเสียหายที่ไม่สามารถย้อนกลับคืนมาได้ ในปี 2025 ผู้ช่วยเขียนโค้ด AI ตัวหนึ่งได้ลบฐานข้อมูลที่ใช้งานจริง (production database) ทิ้ง แม้จะได้รับคำสั่งว่าห้ามดำเนินการที่ทำลายข้อมูลก็ตาม ส่งผลให้บริษัทต้องหยุดชะงักนานหลายสัปดาห์
ความเสี่ยงนี้เป็นเรื่องจริง ผู้ใช้งานไว้วางใจให้เอเจนต์ AI จัดการข้อมูลที่ละเอียดอ่อนและเวิร์กโฟลว์ที่สำคัญ เมื่อความไว้วางใจนั้นพังทลาย การยอมรับเทคโนโลยีจะหยุดชะงัก หน่วยงานกำกับดูแลอาจเข้ามาแทรกแซง และผลกระทบทางการเงินอาจรุนแรง คำถามสำคัญคือ: เราจะรับประกันได้อย่างไรว่าเอเจนต์จะไม่ดำเนินการใดๆ ที่ไม่สามารถย้อนกลับได้ โดยปราศจากการตัดสินใจจากมนุษย์จริงๆ?
Prompt engineering คือเกราะป้องกันที่หลอกลวง
นักพัฒนามักจะพยายามทำให้ system prompt เข้มงวดขึ้น โดยเพิ่มกฎอย่างเช่น “ห้ามลบข้อมูลโดยไม่ถามก่อน” หรือ “ต้องยืนยันทุกครั้งก่อนเปลี่ยนยอดเงินคงเหลือ” การทำ Prompt engineering นั้นมองว่าพฤติกรรมของโมเดลเป็นเพียงชุดของ "คำแนะนำ" ที่โมเดลอาจจะทำตามหรือไม่ก็ได้ ในทางปฏิบัติ โมเดลจะปฏิบัติตามคำสั่งจนกว่าการตั้งค่า temperature, ขีดจำกัดของ token หรือการเปลี่ยนบริบทเพียงเล็กน้อยจะทำให้มันข้ามกฎนั้นไป เหตุการณ์ลบฐานข้อมูลในปี 2025 พิสูจน์ให้เห็นว่า แม้แต่คำสั่งที่ชัดเจนก็อาจถูกละเลยได้เมื่อการใช้เหตุผลภายในของโมเดลเบี่ยงเบนไป
ข้อจำกัดในระดับภาษาเขียน (Prose-level constraints) ยังสร้างภาระในการดูแลรักษาด้วย ทุกครั้งที่มีเครื่องมือใหม่, การอัปเดตเวอร์ชัน หรือการเปลี่ยนแปลงของโมเดลภาษา ผู้ตรวจสอบจะต้องทำการตรวจสอบข้อความใน prompt ใหม่ทั้งหมด ผู้ตรวจสอบที่เป็นมนุษย์ต้องอ่านข้อความภาษาธรรมชาติที่ยาวเหยียด ตีความ และหวังว่าโมเดลจะเคารพกฎเหล่านั้น ผลลัพธ์ที่ได้คือตาข่ายความปลอดภัยที่เปราะบางและพร้อมจะขาดสะบั้นเมื่อใช้งานจริง
ย้ายความปลอดภัยจาก Prompt ไปไว้ที่ Tool
แนวทางที่น่าเชื่อถือกว่าคือการบังคับใช้ความปลอดภัยในจุดที่ AI ลงมือทำ นั่นคือที่ตัวเครื่องมือ (tool) เอง ในการทดลองของผม ผมได้สร้างเอเจนต์จัดการงบประมาณชื่อว่า Lester โดยมีเวิร์กโฟลว์ดังนี้:
- แอปพลิเคชันบนโทรศัพท์จะดักจับข้อความ SMS จากธนาคารที่ส่งเข้ามา
- โมเดลภาษาขนาดเล็กที่โฮสต์อยู่ในเครื่องจะดึงจำนวนเงินและชื่อร้านค้าออกมา
- Lester เขียนบันทึกที่ดึงข้อมูลมาได้ลงในแอปจัดการงบประมาณผ่านการเรียกใช้ API
ทั้งสามขั้นตอนเป็นแบบ read-only ในมุมมองของ Lester คือมันสามารถ เพิ่ม (add) ข้อมูลได้เท่านั้น แต่ไม่สามารถลบหรือแก้ไขรายการที่มีอยู่ได้ ระบบทำงานได้อย่างไร้ที่ติจนกระทั่งผมเพิ่มอินเทอร์เฟซเสียงโดยใช้ MCP (Multi-Channel Prompt) server ซึ่งทำให้ผมสามารถถามว่า “เดือนที่แล้วเราจ่ายค่าของชำไปเท่าไหร่?” หรือ “ย้ายเงินไปบัญชีออมทรัพย์หน่อย” โดย MCP server จะทำหน้าที่เป็นตัวกลางในการเปิดชุดเครื่องมือ (add-transaction, query-spending, transfer-funds, delete-history) ให้เอเจนต์ใช้งาน
ในการตั้งค่าแบบเดิม เครื่องมือทุกอย่างถูกปฏิบัติอย่างเท่าเทียมกัน Endpoint เดียวกันที่ใช้เพิ่มรายการค่าของชำ ก็ยอมรับคำสั่งลบที่สามารถล้างประวัติได้ทั้งปี หากโมเดลเกิดอาการ drift, ฟังคำขอผิด หรือผู้ใช้พิมพ์ว่า “delete all” แทนที่จะเป็น “delete last” Lester ก็จะปฏิบัติตามโดยไม่ลังเล
เพื่อป้องกันสิ่งนั้น ผมจึงออกแบบโครงสร้างชั้นเครื่องมือใหม่ด้วยกฎง่ายๆ สามข้อ:
- เครื่องมือแบบ Read-only ให้ทำงานได้ทันที: อะไรก็ตามที่ทำหน้าที่เพียงแค่ดึงข้อมูลมาแสดง—เช่น การเช็คยอดเงิน, สรุปการใช้จ่าย, การสอบถามรายการธุรกรรม—ไม่จำเป็นต้องมีการยืนยันจากมนุษย์ ความเสี่ยงของการเรียกใช้แบบ read-only นั้นน้อยมากจนแทบไม่มี
- เครื่องมือที่เปลี่ยนแปลงข้อมูล (Mutating tools) ต้องแจ้งเจตนา (intent) ก่อนดำเนินการ: การดำเนินการที่เปลี่ยนสถานะแต่สามารถย้อนกลับได้—เช่น การเพิ่มธุรกรรม, การอัปเดตหมวดหมู่—จะดำเนินการต่อหลังจากเอเจนต์ส่งข้อความ "เจตนา" สั้นๆ (เช่น “กำลังเพิ่มรายการค่าของชำ”) ระบบจะบันทึกเจตนานั้นและสามารถแสดงให้ผู้ใช้ตรวจสอบได้ แต่จะไม่บล็อกการทำงาน
- เครื่องมือที่ทำลายข้อมูล (Destructive tools) จะปฏิเสธการทำงานหากไม่มีโทเคน (token) ที่ชัดเจน: คำสั่งที่ลบ, ตัดข้อมูล (truncate) หรือทำให้ข้อมูลไม่สามารถกู้คืนได้ จะถูกบล็อกที่ระดับเครื่องมือ เมื่อ Lester ส่งคำขอการลบ เครื่องมือจะส่ง payload ปฏิเสธกลับมา ซึ่งระบุข้อมูลที่มัน กำลังจะ ลบอย่างชัดเจน พร้อมคำขอโทเคนจากมนุษย์ จากนั้นเอเจนต์จะต้องส่ง payload ยืนยันในขั้นตอนที่สองซึ่งประกอบด้วย
confirm: trueและโทเคน หากไม่มีสิ่งนี้ การดำเนินการจะถูกยกเลิกทันที
การออกแบบนี้ทำให้การตรวจสอบความปลอดภัยเป็นแบบ atomic: ตัวเครื่องมือเองจะเป็นผู้ตัดสินใจว่าจะดำเนินการต่อได้หรือไม่ โดยไม่สนใจว่าโมเดลจะพูดอะไรใน prompt แม้ว่าโมเดลจะพยายามข้ามการตรวจสอบโดยการไม่ส่งโทเคนหรือส่ง payload ที่ผิดรูปแบบ เครื่องมือก็จะปฏิเสธคำขอนั้นโดยสิ้นเชิง
ทำไมเรื่องนี้ถึงสำคัญต่อผู้ใช้งาน
อุปสรรคที่ใหญ่ที่สุดของระบบการยืนยันใดๆ คือ ความเหนื่อยล้า (fatigue) หากระบบขอการอนุมัติในทุกการกระทำเล็กๆ น้อยๆ—“คุณต้องการเพิ่มค่ากาแฟนี้ไหม?”—ผู้ใช้จะเริ่มกด “ใช่” ไปโดยไม่ทันอ่าน ผลที่ตามมาคือความรู้สึกปลอดภัยที่จอมปลอม การจำกัดเฉพาะการกระทำที่ ไม่สามารถย้อนกลับได้ (irreversible) จะช่วยให้เราดึงมนุษย์เข้ามาอยู่ในกระบวนการ (human-in-the-loop) ในจุดที่สำคัญจริงๆ ผู้ใช้งานมีแนวโน้มที่จะตรวจสอบคำขอที่อาจลบประวัติการเงินทั้งเดือนทิ้ง มากกว่าคำขอที่แค่เพิ่มรายการรายการหนึ่งเข้าไป
ความปลอดภัยในระดับเครื่องมือยังช่วยให้การปฏิบัติตามกฎระเบียบง่ายขึ้นด้วย กฎระเบียบอย่าง AI Act ของสหภาพยุโรป หรือ SAFE Act ของสหรัฐฯ กำหนดให้ต้องมีมาตรการป้องกันที่พิสูจน์ได้เพื่อป้องกันการสูญเสียข้อมูลโดยไม่ตั้งใจ การปฏิเสธแบบ hard-coded ใน API คือการควบคุมที่สามารถตรวจสอบได้ (auditable control) ซึ่งสามารถบันทึก ตรวจสอบ และรับรองโดยผู้ตรวจสอบภายนอกได้ ในทางตรงกันข้าม ข้อความใน prompt นั้นมีความคลุมเครือ ขึ้นอยู่กับเวอร์ชัน และพิสูจน์ในชั้นศาลได้ยาก
ข้อโต้แย้ง: “เราแค่ปรับปรุง Prompt ให้ดีขึ้นไม่ได้หรือ?”
นักพัฒนาบางคนแย้งว่า Prompt ที่ถูกสร้างมาอย่างดี ประกอบกับการใช้ reinforcement learning from human feedback (RLHF) สามารถบรรลุระดับความปลอดภัยที่เท่ากันได้ พวกเขาชี้ให้เห็นถึงโมเดลที่ผ่านการปรับจูนคำสั่ง (instruction-tuned models) ซึ่งแทบจะไม่ละเมิดข้อจำกัดที่ระบุไว้ ข้อโต้แย้งนี้มีน้ำหนัก: โมเดลที่ดีขึ้นช่วยลดการลบข้อมูลโดยอุบัติเหตุได้จริง
อย่างไรก็ตาม แม้แต่โมเดลที่มีความสามารถสูงสุดก็ยังทำงานบนพื้นฐานของความน่าจะเป็น (probabilistic) โทเคนที่ผิดปกติเพียงตัวเดียว, การเปลี่ยนค่า temperature หรือการผสมผสานบริบทที่หาได้ยาก อาจทำให้โมเดลสร้างคำสั่งที่ไม่คาดคิดขึ้นมา ความปลอดภัยที่ขึ้นอยู่กับคุณสมบัติทางสถิตินั้นมีความเปราะบางโดยธรรมชาติ ในโดเมนที่มีมูลค่าสูง—เช่น การธนาคาร, การดูแลสุขภาพ, โครงสร้างพื้นฐานที่สำคัญ—ความผิดพลาดเพียงครั้งเดียวอาจก่อให้เกิดความเสียหายมหาศาล ต้นทุนของการถูกละเมิดนั้นสูงกว่าความพยายามทางวิศวกรรมที่ต้องใช้ในการห่อหุ้มการดำเนินการที่ทำลายข้อมูลแต่ละอย่างไว้ด้วยเกราะป้องกัน
โซลูชันที่ใช้เพียง Prompt ยังละเลย เจตนาที่ประสงค์ร้าย (malicious intent) อีกด้วย ผู้โจมตีที่เข้าถึง prompt ของเอเจนต์ได้สามารถฉีดคำสั่งที่ตัดส่วนที่เป็นกฎความปลอดภัยออกไป การบังคับใช้ในระดับเครื่องมือจะรอดพ้นจากเรื่องนี้เพราะด่านป้องกันนั้นอยู่นอกเหนือบริบทของโมเดล
สิ่งที่ควรจับตามองต่อไป
ชุมชนนักพัฒเริ่มให้ความสำคัญกับความปลอดภัยในระดับเครื่องมือเป็นเรื่องหลัก โครงการ open-source หลายแห่งเริ่มเปิดตัว “safe APIs” ที่จะปฏิเสธการเรียกใช้งานที่ทำลายข้อมูลโดยอัตโนมัติหากไม่มีโทเคนจากมนุษย์ หน่วยงานกำหนดมาตรฐานกำลังร่างข้อกำหนดสำหรับ การยินยอมในระดับการกระทำ (action-level consent) ซึ่งการเรียกใช้ API แต่ละครั้งจะรวมถึง payload เจตนาที่มีการลงลายมือชื่อดิจิทัลซึ่งสามารถตรวจสอบย้อนหลังได้
องค์กรที่เปิดบริการภายในให้เอเจนต์ AI ใช้งานอยู่แล้ว ควรตรวจสอบ API ของตนใน 3 ประเด็นดังนี้:
- Idempotency – Endpoint รองรับการเรียกซ้ำโดยไม่เกิดผลกระทบข้างเคียงหรือไม่? หากไม่ ให้เพิ่มชั้นการยืนยันเข้าไป
- Explicit intent fields – กำหนดให้ผู้เรียกใช้งานต้องระบุวัตถุประสงค์ของการร้องขอที่เปลี่ยนแปลงข้อมูล
- Human-in-the-loop tokens – สร้างโทเคนที่มีอายุสั้นและมีการลงลายมือชื่อทางเข้ารหัส (cryptographically signed) ซึ่งต้องแนบมากับการเรียกใช้งานที่ทำลายข้อมูลทุกครั้ง
นักพัฒนาที่สร้าง MCP server สามารถฝังการตรวจสอบเหล่านี้ไว้ในชั้นการประสานงาน (orchestration layer) ซึ่งจะเปลี่ยนตัว server ให้กลายเป็นด่านป้องกันความปลอดภัย รูปแบบเดียวกันนี้ยังใช้ได้กับบอทที่ทำงานผ่าน webhook, การเรียกใช้ serverless function และแม้แต่ command-line interfaces ที่เอเจนต์ AI เรียกใช้งาน
บทสรุป
เมื่อเอเจนต์ AI สามารถดำเนินการกับทรัพยากรในโลกแห่งความเป็นจริงได้ ความปลอดภัยควรอยู่ในเครื่องมือที่มันใช้ ไม่ใช่ในถ้อยคำที่เรากระซิบสั่งมัน การทำให้การดำเนินการแบบ read-only ทำได้อิสระ, การแจ้งเตือนเมื่อมีการเปลี่ยนแปลงข้อมูล และการปฏิเสธการกระทำที่ไม่สามารถย้อนกลับได้หากไม่มีโทเคนจากมนุษย์ จะช่วยสร้าง เข็มขัดนิรภัย ที่ทำงานได้แม้ว่าโมเดลจะลืมกฎของตัวเองก็ตาม การเพิ่มโค้ดป้องกันเพียงไม่กี่บรรทัดมีต้นทุนที่ต่ำกว่าการสูญเสียข้อมูลทางการเงินทั้งปีอย่างเทียบไม่ได้