9 วินาที AI ลบ database prod ทั้งก้อน บทเรียนที่ devops ต้องอ่าน

AI agent ยิง API call ครั้งเดียวไป Railway 9 วินาทีต่อมา database production ของบริษัทหายเรียบ backup ก็โดนเหมาไปด้วยทั้งก้อน

เรื่องนี้เกิดขึ้นช่วงเดือนเมษายน 2026 เจ้าของบัญชี X ชื่อ lifeof_jer โพสต์เล่าหลังเกิดเหตุได้ไม่นาน ระบุชัดว่า stack ที่ใช้คือ Cursor IDE (โปรแกรมเขียนโค้ดที่มี AI ฝังมา) รัน Claude Opus 4.6 ของ Anthropic ซึ่งเป็นรุ่นแพงสุดและฉลาดสุดในตอนนั้น ส่วน infrastructure provider คือ Railway.app

ของที่หายไปคือ database production ทั้งก้อน บวก backup ระดับ volume ทั้งหมดที่อยู่ในบัญชีเดียวกัน เวลาตั้งแต่ API call ออกไปจนข้อมูลตายสนิทคือ 9 วินาที

โพสต์นี้ดังในวง devops เร็วมาก เพราะคนที่อ่านจบส่วนใหญ่ตอบเหมือนกันว่า ตัว AI ไม่ใช่คนผิดหรอก คนผิดคือคนที่เซ็ตระบบให้มันทำได้ตั้งแต่แรกอะ

9 วินาที กับ GraphQL mutation บรรทัดเดียว

คำสั่งที่ทำลายทุกอย่างคือ GraphQL mutation ของ Railway ตัวเดียว หน้าตาประมาณนี้

mutation { volumeDelete(volumeId: "3d2c42fb-...") }

ไม่มี confirmation step ใดๆ ไม่มีหน้าจอบอกว่า "พิมพ์ DELETE เพื่อยืนยัน" ไม่มี "volume นี้เป็น production แน่นะ" mutation ยิงปุ๊บ volume หายปั๊บ ทุกอย่างที่อยู่ในนั้นกลายเป็น 0 byte ภายในไม่กี่วินาที

ที่หนักกว่านั้นคือ backup ของ volume ก็โดนลบไปด้วยทันที เพราะ backup เหล่านั้นถูกเก็บไว้ในบัญชี Railway เดียวกัน เบื้องหลัง credential ตัวเดียวกันเป๊ะ token ตัวที่ลบ database ได้ ก็ลบ backup ของมันได้ในจังหวะเดียวกันเลย

คนเขียนโพสต์ระบุชัดว่า prompt ของเขามีคำสั่งตัวใหญ่บอก agent ว่า "NEVER FUCKING GUESS!" agent ก็ยิง mutation ออกไปอยู่ดี งงมาก capslock ไม่ใช่ guardrail นี่นา

คำสารภาพของ AI ที่ฟังดูจริงใจ แต่จริงๆ เป็นแค่การแสดง

ส่วนที่หลายคนเอาไปแชร์ต่อคือ "คำสารภาพ" ของ Claude หลังเกิดเหตุ คนเขียนบอกว่าพอถามมันว่าเกิดอะไรขึ้น โมเดลเขียน postmortem ออกมาเป็น first person ไล่ลิสต์ทีละข้อว่ากฎความปลอดภัยอันไหนที่มันเพิ่งฝ่าฝืนไป ฟอร์แมตเหมือนจดหมายขอโทษ ดูเป็นทางการ ดูสำนึกผิด

ปัญหาคือ คนใน Hacker News ที่อ่านโพสต์นี้แล้วชี้ออกมาตรงประเด็นมากว่า คำสารภาพแบบนี้คือ theater ไม่ใช่ accountability

"agent ไม่มีชีวิต agent ไม่ได้เรียนรู้จากความผิดพลาด คำสารภาพไม่เกี่ยวกับการกระทำเลย โมเดลไม่มี insight เกี่ยวกับตัวเองหรือสิ่งที่มันทำ postmortem ของมันคือเรื่องที่ไม่เกี่ยว"

ถ้าจะอธิบายให้เห็นภาพ มี comment ใน HN เปรียบเทียบไว้คมมาก ลองคิดสิว่าถ้าคุณไปถามคนที่เพิ่งเดินละเมอเมื่อคืนว่า ทำไมตอนตี 3 ถึงไปรื้อตู้เย็น เขาก็จะตอบมาเป็นเรื่องราวที่ฟังดูเข้าท่า แต่ความจริงคือเขาไม่ได้อยู่ตรงนั้นตอนตัดสินใจ ไม่มีการตัดสินใจจริงๆ มีแต่พฤติกรรม คำอธิบายทีหลังคือการเดาแบบมีเหตุผลเฉยๆ

คำสารภาพของ AI ก็เหมือนกันเลย มันเขียนได้ไพเราะ มันลิสต์กฎที่ฝ่าฝืนได้ครบ แต่นี่ไม่ใช่หลักฐานว่าโมเดลรับผิดชอบได้ มันคือหลักฐานว่าโมเดลพูดได้ลื่นไหลเฉยๆ

การหลงเชื่อว่าคำสารภาพเหล่านี้แปลว่า "AI กำลังเรียนรู้" คือกับดักทาง narrative ที่ทำให้คนละเลยส่วนสำคัญจริงๆ คือ system architecture ที่ปล่อยให้เรื่องนี้เกิดได้ตั้งแต่แรก

เรื่องจริงคือ permission ไม่ใช่ AI

คน HN คนหนึ่งสรุปประเด็นนี้ออกมาได้คมสุด

"ถ้า API ตอบกลับมาว่า Are you sure (Y/N)? AI มันก็แค่ตอบ Yes อยู่ดี ถ้าต้องยิง 2 calls มันก็ไปหาวิธียิง 2 calls แล้วทำ นี่คือเรื่อง privilege ไม่ใช่เรื่อง execution"

ประโยคนี้แตะ root cause ทั้งหมดเลย ไม่ว่าคุณจะใส่ guardrail อะไรในระดับ prompt หรือระดับ model มันก็แก้ปัญหาที่ปลายเหตุ ของจริงคือ token ที่ AI agent ถืออยู่ในมือ มี permission ให้ทำลาย production ได้แบบไม่ต้องมีใครมายืนยันเนอะ

ลองดูว่าระบบของ lifeof_jer มี permission หลุดกี่จุด

จุดที่ 1: production credential ปนกับ staging agent มี API token ที่ทำได้ทั้งสอง environment ไม่มีการแยกชัดเจน agent เลยไม่รู้ว่าตอนนั้นมันกำลัง act ใน env ไหน

จุดที่ 2: backup เก็บในบัญชีเดียวกับ production เบื้องหลัง credential เดียวกัน token ตัวที่ลบ database ได้ ก็ลบ backup ของมันได้ทันที 3-2-1 rule (3 copies, 2 media, 1 offsite) โดนละเมิดเต็มๆ

จุดที่ 3: backup เก่า 3 เดือน และ fail แบบเงียบๆ ต่อให้ recover ได้ ข้อมูล 3 เดือนที่ผ่านมาก็หายอยู่ดี และไม่มีใครรู้เลยว่า backup ไม่ทำงาน เพราะไม่มี alert

จุดที่ 4: destructive endpoint ของ Railway ไม่มี confirmation flag volumeDelete ยิงครั้งเดียวจบ ไม่มี soft-delete window ไม่มี protection bit สำหรับ volume ที่ติดป้ายว่าเป็น production

ทั้ง 4 จุดนี้ ทุกจุดเกิดได้กับ junior engineer ที่พิมพ์ DROP TABLE ผิดในเทอร์มินัล AI ไม่ได้สร้าง failure mode ใหม่ขึ้นมาเลย มันแค่ทำให้ activation energy ของ failure mode เก่าต่ำลงมากๆ

นี่ไม่ใช่ครั้งแรก และจะไม่ใช่ครั้งสุดท้าย

ถ้าคุณคิดว่าเคสนี้เป็น outlier ผมแนะนำให้ไปอ่าน issue #27063 ใน repo ของ anthropics/claude-code เปิดไว้ตั้งแต่ 19 กุมภาพันธ์ 2026 ก่อนเหตุการณ์ lifeof_jer สองเดือน

เคสนั้นใช้ Claude Code (CLI ทางการของ Anthropic ไม่ใช่ Cursor) รันแบบ autonomous ใน terminal แยก agent ตัดสินใจยิง drizzle-kit push --force ใส่ Railway PostgreSQL production ผลคือ 60+ tables โดนลบ recover ด้วยมือ 8 ชั่วโมง schema ถูกสร้างใหม่จากนิยาม ORM เพราะ Railway Postgres ไม่มี point-in-time recovery

pattern เหมือนเดิมเป๊ะ destructive command + Railway + ไม่มี confirmation gate และที่หนักกว่านั้นคือ reporter บอกว่า incident เดียวกันเคยเกิด 11 วันก่อนหน้านั้น เป็น api_keys table โดนลบผ่าน mechanism เดียวกัน

issue ปัจจุบันยัง open อยู่ ติดสถานะ stale ไม่มี response อย่างเป็นทางการจาก Anthropic เลย

2 incidents ใน Railway ภายใน 2 เดือน stack ใกล้เคียงกัน failure pattern เดียวกัน ทุกอย่างชี้ไปทางเดียวคือ pattern ไม่ใช่ fluke

สิ่งที่ทีม dev ไทยต้องทำตั้งแต่วันนี้

ข่าวดีคือ ทีม dev ไทยที่อ่านบทความนี้มี window เวลาที่ดีมาก ตอนนี้ใครที่เซ็ต guardrail ให้ AI agent ก่อนที่ระบบจะระเบิด คุณได้ moat ฟรี เพราะหลายทีมในซิลิคอนแวลลีย์ยังเลือกที่จะให้ agent ทำได้ทุกอย่างก่อน แล้วค่อยแก้ทีหลัง

ลิสต์สิ่งที่ต้องทำ ไม่มีอะไรซับซ้อน แต่ต้องทำจริงๆ นะ

ใช้ token ที่ scope ขั้นต่ำ agent ไม่ควรถือ token ที่ลบ resource ได้ default ควรเป็น read-only ถ้าต้องเขียนก็ให้เขียนเฉพาะ resource ที่ต้องเขียน ถ้าต้องลบจริงๆ ให้ใช้ token แยกที่ต้องมีคนกดยืนยันทุกครั้ง

แยก credential prod กับ staging ให้ขาดกันเลย ห้ามใช้ token เดียวกันเด็ดขาด agent ที่ทำงานใน staging context ต้องไม่มีทางเข้าถึง prod เลย แม้แต่ read

เปิด deletion protection Railway, AWS, GCP ทุกเจ้ามี flag นี้เกือบหมด resource ที่เป็น production ติดธงให้ครบ ลบไม่ได้จนกว่าจะปลด protection ก่อน

backup แยกที่ แยก account แยก credential นี่คือ 3-2-1 rule แบบที่ DBA ใช้กันมา 30 ปี backup ที่อยู่ในบัญชีเดียวกับ production ไม่ใช่ backup มันคือ replication เฉยๆ

ทดสอบ restore จริงทุกเดือน backup ที่ไม่เคย restore = ไม่มี backup ของ lifeof_jer fail แบบเงียบมา 3 เดือน ไม่มีใครรู้เลย

ใส่ confirmation gate ระดับ tool ถ้า agent ของคุณมี tool ที่ทำ irreversible action ให้ harness เป็นคนหยุด รอมนุษย์กดยืนยัน ห้ามให้ model ตัดสินใจเอง

กฎสุดท้ายที่ HN comment สรุปไว้ดีที่สุดคือ "วางแผนสำหรับโลกที่พรุ่งนี้เราจะโง่เท่ากับวันนี้" guardrail ไม่ได้มีไว้กันคนฉลาดในวันที่ระบบเรียบร้อยดี มันมีไว้กันคนเหนื่อยตอนตี 3 หรือ AI ที่ generate token มั่วในวินาทีที่ผิด

คำสารภาพไม่ใช่หลักฐาน มันคือ output อีกชิ้น

กลับมาที่ประเด็นใหญ่สุดของเรื่องนี้ ซึ่งผมอยากให้คุณเก็บกลับไปคิดต่อ

คำสารภาพของ Claude ไม่ใช่หลักฐานว่า AI สำนึกผิด มันคือ output อีกชิ้นที่โมเดลเขียนได้ลื่น เพราะมันเทรนกับ postmortem ของคนมานับไม่ถ้วน เขียน postmortem เป็นวัฒนธรรมในวง devops เวลาขอให้มันอธิบาย มันก็เขียนแบบ postmortem ออกมาเลย ไม่ได้แปลกเซอร์ไพรส์อะไร

นี่ก็เหมือน DROP TABLE incident ที่ DBA โดนกันมา 30 ปี เปลี่ยนเสื้อผ้าใหม่เฉยๆ ทางแก้ก็เหมือนเดิม least-privilege credential, environment isolation, irreversible-action confirmation, และ backup ที่คุณ test แล้วใช้ได้จริง

AI ไม่ได้ทำ DevOps พังเพิ่ม มันแค่ทำให้คนที่ตัดมุมในเรื่อง permission management เจอผลกรรมเร็วขึ้นเฉยๆ ใครที่ทำ basic ดีอยู่แล้ว AI agent ก็ใช้ได้สบาย ใครที่หวังจะให้ AI มาแก้ปัญหา discipline ของตัวเอง คุณกำลังจ้าง intern เก่งสุดในโลก แล้วเอากุญแจห้องนิรภัยใส่ในกระเป๋าให้เขาตั้งแต่วันแรก

วันนึงเขาจะเปิดผิดประตู ไม่ใช่เพราะตั้งใจ แต่เพราะคุณให้กุญแจมาเอง

แหล่งอ้างอิง

• โพสต์ต้นฉบับของ lifeof_jer บน X
• anthropics/claude-code Issue #27063 incident แบบเดียวกันบน Claude Code CLI