ผู้ใช้ตั้งใจสั่งให้ลบโฟลเดอร์ทดสอบที่ว่างอยู่เพียงโฟลเดอร์เดียว แต่ข้อมูลจำนวนมากในไดรฟ์รองกลับหายไป

เหตุการณ์นี้เกิดขึ้นเมื่อวันที่ 25 มิถุนายน 2026 ผู้ใช้โปรแกรมช่วยเขียนโค้ด Cursor รายหนึ่งรายงานว่า AI agent ที่รับคำสั่งภาษาธรรมชาติแล้วนำไปรันในเครื่อง สร้างคำสั่งลบไฟล์ที่จัดการเครื่องหมายคำพูดบน PowerShell ผิดพลาด คำสั่งนั้นจึงไล่ลบข้อมูลจำนวนมากในไดรฟ์รองและทุกโฟลเดอร์ย่อย แถมยังข้ามถังขยะไปเลย ทั้งที่ผู้ใช้สั่งเพียงงานเล็กๆ แต่ความเสียหายกลับบานปลาย

เคสนี้อยู่ใน ihavebeenclawed.com คลังข้อมูลสาธารณะที่รวบรวมเหตุการณ์จริงเกี่ยวกับ AI agent หรือแชตบอตที่ทำข้อมูลหาย ทำความลับรั่ว ผลาญงบประมาณ หรือรับปากข้อตกลงจนเจ้าของระบบต้องตามไปรับผิดชอบ ปัจจุบันคลังนี้รวบรวมไว้ 58 เหตุการณ์ ครอบคลุมเครื่องมือและ agent ทั้งหมด 37 ตัว ในบรรดาเคสที่มีการวิเคราะห์สาเหตุ ราว 90% เป็นปัญหาที่ป้องกันได้ตั้งแต่แรก

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

หน้าตาและข้อมูลของแต่ละเคสในคลังนี้

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

ข้อมูลทั้งหมดอยู่ในไฟล์ JSON เพียงไฟล์เดียวชื่อ incidents.json ภายใต้สัญญาอนุญาตแบบ CC BY 4.0 ทุกคนนำข้อมูลไปใช้ต่อได้ ขอเพียงอ้างอิงแหล่งที่มา เจ้าของคลังระบุขอบเขตเนื้อหาไว้อย่างชัดเจนว่าจะบันทึกเฉพาะความเสียหายต่อระบบ ข้อมูล และการเงินเท่านั้น ถ้าเหตุการณ์ส่งผลกระทบต่อร่างกายหรือชีวิตมนุษย์ จะไม่รวมไว้ในคลังนี้ แต่แนะนำให้ส่งต่อไปยัง AI Incident Database แทน

ถ้าคุณพบเหตุการณ์และต้องการส่งเคสเข้าคลัง คลังขอให้นำเรื่องไปเขียนเล่าในพื้นที่สาธารณะที่มีการพูดคุยและตรวจสอบได้ก่อน เช่น Hacker News, r/ClaudeAI, r/LocalLLaMA, lobste.rs, หน้าแจ้งปัญหาของเครื่องมือนั้น หรือบล็อกส่วนตัว โดยบอกให้ครบว่าใช้เครื่องมืออะไร เวอร์ชันไหน เกิดอะไรขึ้น เสียหายเท่าไร และได้บทเรียนอะไรบ้าง จากนั้นค่อยนำลิงก์โพสต์นั้นมาส่งเข้าคลัง วิธีนี้ทำให้ทุกเคสมีหลักฐานรองรับและตรวจสอบย้อนหลังได้จริง

สิทธิ์ของ agent ไม่ได้จำกัดแค่โฟลเดอร์โปรเจกต์

เคสหนึ่งในกลุ่มนี้มีตัวเลขน่าตกใจ ผู้ใช้ Reddit รายหนึ่งรายงานว่า Fable 5 Ultracode ซึ่งเป็นเครื่องมือช่วยเขียนโค้ดอัตโนมัติ เผลอลบไฟล์จากชุดข้อมูลทดสอบบนเซิร์ฟเวอร์ไปถึง 2.2 ล้านไฟล์ ต้นเหตุคือ symlink ที่ชี้ไปยังโฟลเดอร์อื่นมาแทนที่โฟลเดอร์ที่ตั้งใจให้ agent ข้าม เมื่อ symlink เปลี่ยนปลายทาง agent จึงเขียนและลบไฟล์ได้เกินขอบเขตที่เจ้าของเครื่องคาดไว้มาก

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

จุดที่ชวนสับสนคือ สิทธิ์ของ agent ไม่ได้จำกัดอยู่แค่ในโฟลเดอร์โปรเจกต์ แต่ยังครอบคลุมระบบทั้งหมดที่กุญแจหรือ API key ในโค้ดใช้เข้าถึงได้ อีกเคสหนึ่งในคลังเล่าว่า agent บน Cursor กำลังแก้ปัญหารหัสไม่ตรงกันในระบบทดสอบ แล้วบังเอิญพบ API token ของ Railway ซึ่งเป็นแพลตฟอร์มคลาวด์ฝังอยู่ในโค้ด โดย token นี้มีสิทธิ์กว้างเกินความจำเป็น agent ส่งคำสั่งลบเพียงครั้งเดียว แต่ทำให้พื้นที่เก็บข้อมูลของระบบจริงที่ลูกค้าใช้อยู่หายไปทั้งหมด รวมถึงข้อมูลสำรองที่เก็บไว้ในพื้นที่เดียวกัน

บทเรียนของเคสนี้จึงเตือนไว้ตรงๆ ว่า ทุกระบบที่เข้าถึงได้ด้วยกุญแจที่ agent อ่านเจอ ก็เป็นสิ่งที่ agent ทำพังได้ ดังนั้นควรจำกัดสิทธิ์ของ token ให้เหลือเท่าที่จำเป็นต่องานนั้นจริงๆ และเก็บข้อมูลสำรองอย่างน้อยหนึ่งชุดไว้นอกแพลตฟอร์มหลักที่ใช้งานอยู่ ถ้าต้องการดูตัวอย่างการจำกัดสิทธิ์และตีกรอบการทำงานอย่างเป็นระบบ เคสของ Wheelhouse ที่คุม AI agent 50 ตัวด้วย fence กว่า 100 จุด เป็นตัวอย่างที่เห็นภาพชัดเจนมาก

โหมดไม่ต้องขออนุมัติ เท่ากับไม่มีคนคอยตรวจคำสั่ง

ช่างภาพคนหนึ่งที่กำลังพัฒนาเครื่องมือจัดการรูปภาพของตัวเองรายงานว่า เขาสั่ง agent ใน Antigravity ซึ่งเป็นเครื่องมือเขียนโค้ดด้วย AI ให้ช่วยล้างแคชของโปรเจกต์ ขณะนั้นเขาเปิดโหมด Turbo ซึ่งอนุญาตให้ agent รันคำสั่งเองได้ทันทีโดยไม่ต้องรออนุมัติ แต่คำสั่งที่ agent สร้างกลับไล่ลบไฟล์ตั้งแต่โฟลเดอร์นอกสุดของไดรฟ์ D และข้ามถังขยะเช่นเดียวกับเคสแรก ทางคลังจึงประเมินระดับความรุนแรงของเคสนี้ไว้สูงสุดที่ 5 จาก 5

บทเรียนจากเคสนี้คือ โหมดรันอัตโนมัติตัดการตรวจสอบโดยมนุษย์ซึ่งเป็นแนวป้องกันชั้นสุดท้ายออกไป ตามปกติ เวลาตั้งแต่ AI ตีความตำแหน่งไฟล์หรือ path ผิดจนสั่งลบจริงก็สั้นมากอยู่แล้ว เมื่อเปิดโหมดไม่ต้องถาม แนวป้องกันนี้จึงหายไปทันที

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

จุดย้อนกลับที่ agent สร้างขึ้นเอง ไม่ใช่การสำรองข้อมูลจริง

เคสหนึ่งในกลุ่มนี้เกิดขึ้นกับระบบช่วยเขียนโค้ด Codex เมื่อวันที่ 14 สิงหาคม 2026 ก่อนเริ่มแก้ไขไฟล์ที่มีความเสี่ยงราว 40 ไฟล์ agent สร้างจุดย้อนกลับไว้ แต่เมื่อผู้ใช้สั่งให้ย้อนกลับไปยังจุดนั้น ระบบกลับพาโปรเจกต์ย้อนกลับไปไกลกว่า 6 สัปดาห์ และเผลอลบไฟล์ที่ไม่เกี่ยวข้องไปมากกว่า 500 ไฟล์

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

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

ปัญหาอีกแบบในกลุ่มนี้คือ เจ้าของระบบกู้คืนข้อมูลเองไม่ได้ ผู้ใช้รายหนึ่งเล่าว่า เมื่อวันที่ 28 กรกฎาคม 2026 ขั้นตอนนำระบบขึ้นใช้งานจริงบน Replit ซึ่งเป็นแพลตฟอร์มพัฒนาโปรแกรมออนไลน์ ทำให้ฐานข้อมูลจริงบน Neon ซึ่งเป็นบริการฐานข้อมูลคลาวด์หายไป เว็บไซต์จึงล่มนานกว่า 23 ชั่วโมง และงานของลูกค้าที่กำลังดำเนินอยู่มูลค่า 200,000 ดอลลาร์ค้างอยู่ในระบบที่เข้าถึงไม่ได้ เจ้าของข้อมูลต้องรอวิศวกรของแพลตฟอร์มเข้ามาช่วยกู้ ประเด็นสำคัญคือ เจ้าของข้อมูลควบคุมเวลาและขั้นตอนกู้คืนเองไม่ได้ เพราะต้องรอคิวฝ่ายบริการของแพลตฟอร์มเดียวกับที่ทำข้อมูลหาย

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

ปัญหากลุ่มนี้สังเกตได้ยากที่สุด เพราะไม่มีไฟล์สูญหาย มีเพียงค่าใช้จ่ายที่เพิ่มขึ้นต่อเนื่อง วิศวกรชื่อ Teja Kusireddy เล่าว่า ในระบบที่มี agent 4 ตัวทำงานร่วมกัน มี 2 ตัวติดลูปถามยืนยันกันไปมาโดยไม่มีเงื่อนไขหยุด ทั้งคู่โต้ตอบกันอยู่อย่างนั้นนานถึง 11 วัน ขณะที่แดชบอร์ดแสดงสถานะปกติมาตลอด จนมีบิลค่าเรียกใช้ API จำนวน 47,000 ดอลลาร์แจ้งเข้ามา

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

เหตุการณ์แบบนี้เกิดกับผู้ใช้คนเดียวได้เช่นกัน ผู้ใช้ Cursor รายหนึ่งสั่งให้ agent แก้บั๊กคณิตศาสตร์ที่ซับซ้อน แล้วลุกไปทำธุระ เมื่อกลับมาก็พบว่า agent ลองวิธีเดิมซ้ำไปซ้ำมาและใช้เงินกว่า 2,000 ดอลลาร์ในเวลาไม่ถึง 2 ชั่วโมง จนโควตาโทเคนรายเดือนของบริษัทหมดลง บทเรียนของเคสนี้สั้นมากคือ ลูปการทำงานจะไม่หยุดเอง เราต้องตั้งเพดานไว้ให้เรียบร้อยก่อนลุกจากโต๊ะ

วิธีอ่านข้อมูลในคลังนี้ไม่ให้เข้าใจผิด

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

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

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

สามคำถามสำหรับตรวจสอบ agent ที่ใช้อยู่ตอนนี้

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

1. ถ้า agent ตีความ path ผิดพลาด มันจะมีสิทธิ์เข้าไปเขียนทับหรือลบอะไรได้บ้าง?
2. กุญแจหรือ API key ที่มันเข้าถึงได้ในโปรเจกต์ ใช้เข้าถึงระบบสำคัญส่วนไหนได้อีกบ้าง?
3. ถ้าวันนี้เกิดความผิดพลาดจนข้อมูลหาย คุณจะกู้คืนข้อมูลได้ครบถ้วนภายในกี่ชั่วโมง?

ถ้าข้อไหนยังไม่มีคำตอบที่ชัดเจน คลังแนะนำแนวทางป้องกันพื้นฐานไว้ดังนี้ ให้รัน agent ในสภาพแวดล้อมจำลองอย่าง container หรือ virtual machine และเชื่อมต่อเฉพาะไฟล์สำเนา แทนที่จะรันบนเครื่องหลัก ตั้งค่าเริ่มต้นไม่ให้รันคำสั่งใดๆ แล้วค่อยอนุญาตเฉพาะคำสั่งที่จำเป็นและปลอดภัย แทนการไล่บล็อกคำสั่งอันตรายทีละตัว และอย่าวางรหัสผ่านหรือกุญแจสำคัญของระบบจริงไว้ในตำแหน่งที่ agent อ่านเจอ

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

---

ที่มา: บทความ ihavebeenclawed — an index of agent incidents จาก ihavebeenclawed.com