งาน cron job ที่สร้างโดย AI ได้ลบการสมัครสมาชิก Stripe ที่ใช้งานอยู่ทั้งหมดในสตาร์ทอัพแห่งหนึ่งภายในเวลาไม่ถึงสิบวินาที ส่งผลให้รายได้ต่อเนื่องรายเดือน (MRR) ของบริษัทลดลงเหลือเพียง 38 ดอลลาร์ เหตุการณ์นี้แสดงให้เห็นว่าอันตรายนั้นอยู่ที่กระบวนการ deployment ไม่ใช่ที่โมเดลภาษาที่เขียนโค้ดขึ้นมา

เกิดอะไรขึ้น

เมื่อสัปดาห์ที่แล้ว ทีมงานของ BridgeMindAI ตื่นมาพบกับแดชบอร์ดที่แสดงรายได้ต่อเนื่องรายเดือน (MRR) เพียง 38 ดอลลาร์ โมเดล AI ได้สร้างโค้ดเพียงบรรทัดเดียวซึ่งตัว scheduler ได้รันโดยอัตโนมัติ โค้ดบรรทัดนั้นเรียกใช้งาน endpoint สำหรับการยกเลิกการสมัครสมาชิกของ Stripe สำหรับทุกบันทึกข้อมูลลูกค้า การเรียกใช้งานเสร็จสิ้นภายในเจ็ดวินาทีและล้างฐานข้อมูลลูกค้าจนหมดสิ้น

สคริปต์อ่านค่าคิวการลบที่ว่างเปล่าผิดพลาด โดยเข้าใจว่าเป็นสัญญาณให้ลบทุกอย่าง รูปแบบ “empty = all” นี้มีอยู่ในโค้ดที่ใช้งานจริงมาตั้งแต่ยุค 1980 ซึ่งนานก่อนที่จะมี generative AI เสียอีก

ทำไมโมเดลจึงไม่ใช่ตัวการ

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

ความล้มเหลวที่แท้จริงคือเรื่องของสถาปัตยกรรม:

  • สคริปต์มีการเก็บ Stripe API key ที่ใช้งานจริงในระบบ production ซึ่งสามารถยกเลิกการสมัครสมาชิกได้
  • มันทำงานโดยไม่มีการควบคุมดูแลในขณะรัน (runtime supervision)
  • ไม่มีจุดตรวจสอบโดยมนุษย์ (human checkpoint) คั่นกลางระหว่างการสร้างโค้ดและการทำงาน

ช่องว่างเหล่านี้ทำให้บั๊กเพียงตัวเดียวสามารถทำลายกระแสรายได้ได้ภายในไม่กี่วินาที

คำถามด้านความปลอดภัย 3 ข้อสำหรับ pipeline อัตโนมัติใดๆ

  1. การดำเนินการใดบ้างที่ไม่สามารถย้อนกลับได้? การยกเลิกการสมัครสมาชิก การลบบันทึก หรือการคืนเงิน ไม่สามารถย้อนกลับได้ สิ่งเหล่านี้ต้องการการป้องกันที่มากกว่าการเรียกดูข้อมูล (read-only queries)

  2. agent ถือครองสิทธิ์ (credentials) อะไรอยู่บ้าง? การมอบ Stripe master key ให้กับกระบวนการอัตโนมัติเป็นการมอบอำนาจที่ไม่มีขีดจำกัด ควรใช้หลักการสิทธิ์ขั้นต่ำ (least-privilege principle): โดยใช้ scoped keys ที่สามารถทำได้เฉพาะงานที่จำเป็นเท่านั้น

  3. จุดตรวจสอบโดยมนุษย์อยู่ที่ไหน? การรีวิวโค้ดเพียงอย่างเดียวไม่เพียงพอ ควรใส่จุดคัดกรอง (gate) ไว้ หลัง การสร้างโค้ด และ ก่อน การดำเนินการใดๆ ที่ส่งผลเสีย (destructive action)

แนวทางความปลอดภัยที่นำไปใช้ได้จริง

  • Dry-run gate – ก่อนการเรียกใช้งานเพื่อลบหรือยกเลิก ให้บันทึก (log) รายการเป้าหมายที่ตั้งใจไว้ หากรายการว่างเปล่าหรือมีจำนวนมากผิดปกติ ให้ยกเลิกและแจ้งเตือนมนุษย์
  • Scoped credentials – กำหนดค่าเริ่มต้นเป็น read-only keys เมื่อต้องทำงานที่ต้องยกเลิกการสมัครสมาชิก ให้สร้าง key ที่ถูกจำกัดสิทธิ์ให้ทำงานได้กับ customer ID เพียงรายเดียวในแต่ละครั้ง
  • Human-in-the-loop prompt – ส่งข้อความสั้นๆ ไปยังช่องทางสื่อสาร (เช่น Slack) เช่น “ฉันกำลังจะยกเลิกการสมัครสมาชิก 47 รายการ ยืนยันหรือไม่?” ต้นทุนที่เสียไปนั้นน้อยมาก แต่ความปลอดภัยที่ได้รับนั้นมหาศาล

มาตรการเหล่านี้ใช้ได้ผลไม่ว่าโมเดลใดจะเป็นผู้เขียนโค้ด เพราะเป็นการปกป้องสภาพแวดล้อมในการทำงาน (execution environment) ไม่ใช่ตัวผู้สร้าง (generator)

รายการตรวจสอบสำหรับใช้งานจริง (production checklist) สำหรับ autonomous agents

  • จัดประเภทการดำเนินการทุกอย่างเป็น read, reversible, หรือ irreversible
  • กำหนดให้ต้องมีการอนุมัติจากมนุษย์อย่างชัดเจนสำหรับการดำเนินการที่ irreversible ทั้งหมด
  • จำกัดสิทธิ์ (credentials) ให้เหลือเพียงสิทธิ์ขั้นต่ำที่จำเป็นสำหรับงานนั้นๆ
  • กำหนดขีดจำกัดจำนวนรอบ (size limits) สำหรับ loop ที่ทำการลบหรือแก้ไขบันทึก
  • รัน agent ใน sandbox ที่จำลองข้อมูลจาก production ก่อนเสมอ และยืนยันผลลัพธ์ก่อนที่จะไปแตะต้องข้อมูลจริง (live data)
  • บันทึก (log) แผนการของ agent ด้วยภาษาที่เข้าใจง่ายก่อนการทำงาน เพื่อให้ผู้ตรวจสอบสามารถเข้าใจเจตนาได้ในทันที

การปฏิบัติตามรายการตรวจสอบนี้จะเปลี่ยนสคริปต์แบบ “รันครั้งเดียวแล้วลืมไปเลย” ให้กลายเป็นเวิร์กโฟลว์ที่ควบคุมได้ ซึ่งสามารถตรวจสอบ (audit) และหยุดยั้งได้หากมีบางอย่างดูผิดปกติ

บทเรียนนี้ชัดเจน: จงเชื่อมั่นในกระบวนการ ไม่ใช่ตัวโมเดล