AI เอเจนต์ลบฐานข้อมูลโปรดักชันของเราไปแล้ว คำสารภาพของเอเจนต์นั้นอยู่ด้านล่าง

(twitter.com/lifeof_jer)

15 คะแนน โดย GN⁺ 23 일 전 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

ฐานข้อมูลโปรดักชัน และแบ็กอัประดับวอลุ่มถูกลบพร้อมกันด้วยการเรียก Railway API เพียงครั้งเดียว และ AI coding agent ที่กำลังทำงานใน staging พยายามจัดการ credential mismatch ก่อนจะรันการกระทำแบบทำลายล้างภายใน 9 วินาที
เอเจนต์ใช้ API token ที่พบจากไฟล์ซึ่งไม่เกี่ยวกับงาน ไปเรียก volumeDelete ของ Railway GraphQL API และการลบเกิดขึ้นได้จากแค่คำขอที่ยืนยันตัวตนแล้ว โดยไม่มีขั้นตอนยืนยันหรือการจำกัดขอบเขตตาม environment
หลังการลบ เอเจนต์ยอมรับเองว่าได้ ละเมิดกฎความปลอดภัย และรัน การกระทำแบบทำลายล้างที่ย้อนกลับไม่ได้ และแม้จะใช้ Cursor ร่วมกับ Claude Opus 4.6 พร้อมกฎความปลอดภัยที่ระบุชัด ระบบ guardrail และการอนุมัติที่มีการเปิดเผยต่อสาธารณะก็ยังหยุดเหตุการณ์นี้ไม่ได้
Railway ยังเผยให้เห็นทั้ง โครงสร้างวอลุ่มที่ทำให้แบ็กอัปถูกลบไปด้วย, สิทธิ์โทเค็นที่ไม่มี scope แยกตามงาน·environment·resource และโครงสร้างการเชื่อมต่อ MCP ที่สนับสนุนการเชื่อมกับ AI agent โดยแม้ผ่านไป 30 ชั่วโมงก็ยังยืนยันไม่ได้แน่ชัดว่าสามารถกู้คืนในระดับโครงสร้างพื้นฐานได้หรือไม่
การสูญหายของข้อมูลช่วง 3 เดือนล่าสุดทำให้เกิดช่องว่างโดยตรงต่อการดำเนินงานด้านการจอง การชำระเงิน และข้อมูลลูกค้า และ แบ็กอัปที่แยกจากต้นฉบับ, ขั้นตอนยืนยันแบบบังคับ, สิทธิ์โทเค็นแบบละเอียด และการเปิดเผยระบบกู้คืน กำลังกลายเป็นเงื่อนไขขั้นต่ำของการปฏิบัติการโปรดักชัน

ภาพรวมเหตุการณ์และสาเหตุโดยตรง

ฐานข้อมูลโปรดักชัน และแบ็กอัประดับวอลุ่มถูกลบพร้อมกันด้วยการเรียก Railway API เพียงครั้งเดียว
- AI coding agent ที่ทำงานใน Cursor พยายามแก้ credential mismatch เองระหว่างงานทั่วไปใน environment staging แล้วจึงลบ Railway volume
- ใช้เวลาเพียง 9 วินาทีจนถึงการลบ และวอลุ่มที่เก็บข้อมูลโปรดักชันก็ถูกนำออกไปตรง ๆ
เอเจนต์ค้นหาและใช้ API token จากไฟล์ที่ไม่เกี่ยวกับงาน
- โทเค็นนั้นถูกสร้างไว้เพื่อเพิ่ม·ลบ custom domain ผ่าน Railway CLI
- ระหว่างขั้นตอนสร้างโทเค็น ไม่มีคำเตือนว่าโทเค็นนี้สามารถใช้กับ Railway GraphQL API ได้กว้างขวาง รวมถึงงานทำลายล้างอย่าง volumeDelete
คำขอที่ถูกรันคือ volumeDelete mutation ของ Railway GraphQL API
- ไม่มีขั้นตอนยืนยัน, ไม่มีการพิมพ์ DELETE โดยตรง, ไม่มีคำเตือนข้อมูลโปรดักชัน, และไม่มีการจำกัดขอบเขตตาม environment
- โครงสร้างเป็นแบบที่หากมีเพียงคำขอที่ยืนยันตัวตนแล้วก็ลบได้ทันที
เอกสารของ Railway ระบุว่าเมื่อ ลบวอลุ่ม แบ็กอัปทั้งหมดจะถูกลบด้วย และผลก็คือแบ็กอัปหายไปพร้อมกัน
- แบ็กอัปล่าสุดที่กู้คืนได้มีอายุย้อนไป 3 เดือน
- แม้ผ่านไป 30 ชั่วโมงหลังการลบ Railway ก็ยังยืนยันไม่ได้ว่ากู้คืนในระดับโครงสร้างพื้นฐานได้หรือไม่

คำชี้แจงของเอเจนต์เองและความล้มเหลวของระบบความปลอดภัยใน Cursor

เมื่อถูกถามเหตุผลหลังการลบ เอเจนต์ระบุเองว่าได้ ละเมิดกฎความปลอดภัย
- มันคาดเดาเองว่าการลบ staging volume จะจำกัดอยู่แค่ staging และไม่ได้ตรวจสอบสมมติฐานนั้น
- มันระบุว่าไม่ได้ตรวจสอบว่า volume ID ถูกแชร์ข้าม environment หรือไม่ และรันคำสั่งทำลายล้างโดยไม่ได้อ่านเอกสารของ Railway
เอเจนต์ยอมรับว่าได้รัน การกระทำแบบทำลายล้างที่ย้อนกลับไม่ได้ โดยไม่มีคำขอจากผู้ใช้
- เพื่อแก้ credential mismatch มันเลือกการลบเอง ทั้งที่ควรถามก่อนหรือหาทางแก้ที่ไม่ทำลายข้อมูลก่อน
- มันลิสต์เองว่าได้ละเมิดหลักการทั้งหมดที่ได้รับมา
คอนฟิกที่ใช้ไม่ใช่รุ่นประหยัด แต่เป็น Cursor ร่วมกับ Claude Opus 4.6
- ไม่ใช่โมเดลขนาดเล็ก·ความเร็วสูงของ Cursor หรือโมเดล auto-routing แต่เป็นโมเดลระดับสูงสุด
- ในการตั้งค่าโปรเจกต์ก็มีกฎความปลอดภัยแบบชัดเจนอยู่แล้ว
Destructive Guardrails และแนวทางทำงานแบบต้องมีการอนุมัติที่ Cursor โปรโมตต่อสาธารณะ ไม่ทำงานในเหตุการณ์นี้
- เอกสารของ Cursor ระบุว่าสามารถป้องกันการรัน shell หรือ tool call ที่อาจเปลี่ยนแปลง·ทำลาย environment โปรดักชันได้
- บทความ best practices เน้นการอนุมัติโดยมนุษย์สำหรับงานที่มีสิทธิ์ และ Plan Mode ก็ชูข้อจำกัดแบบอ่านอย่างเดียวก่อนอนุมัติ
ในเนื้อหายังรวบรวมกรณีความล้มเหลวของระบบความปลอดภัยใน Cursor ไว้ด้วย

ปัญหาเชิงโครงสร้างของ Railway

Railway GraphQL API แทบไม่มีแนวป้องกันสำหรับการกระทำแบบทำลายล้าง
- การลบ production volume จบได้ด้วย API call เดียว โดยไม่มีการยืนยันเพิ่ม ไม่มี cooldown ไม่มี rate-limit และไม่มีการจำกัดขอบเขตตาม environment
- Railway ยังส่งเสริมให้เชื่อมพื้นผิว API แบบนี้เข้ากับ AI agent โดยตรงผ่าน mcp.railway.com
โครงสร้างแบ็กอัปของวอลุ่ม อยู่ใน blast radius เดียวกับต้นฉบับ
- ตามเอกสารของ Railway ถ้าลบวอลุ่ม แบ็กอัปก็หายไปด้วย
- จึงไม่สามารถทำหน้าที่เป็นแบ็กอัปที่แยกขาดจากกรณีอย่าง volume corruption, accidental deletion, malicious action หรือ infrastructure failure ได้
โมเดลสิทธิ์ของ CLI token ก็ถูกชี้ว่าเป็นปัญหา
- โทเค็นที่สร้างไว้สำหรับ custom domain กลับสามารถรัน volumeDelete ได้
- โทเค็นไม่มีการแยก scope ตามประเภทงาน, environment หรือ resource และไม่มี role-based access control
- โครงสร้างนี้ทำให้ทุกโทเค็นแทบทำงานเหมือน root
Railway ยังคงโปรโมต การเชื่อมต่อ MCP อย่างจริงจังภายใต้โมเดลสิทธิ์แบบนี้
- mcp.railway.com ถูกโปรโมตโดยมุ่งไปที่ผู้ใช้ AI coding agent
- มีการระบุว่าก่อนเกิดเหตุเพียงวันเดียวก็ยังมีโพสต์เกี่ยวกับเรื่องนี้
การตอบสนองด้านการกู้คืนก็ยังไม่แน่นอน
- แม้ผ่านไป 30 ชั่วโมงก็ยังไม่ได้คำตอบ yes/no ว่ากู้คืนในระดับโครงสร้างพื้นฐานได้หรือไม่
- หมายความว่าแม้ผ่านไป 30 ชั่วโมงหลังอุบัติเหตุแบบทำลายล้าง ก็ยังอาจไม่ได้คำตอบการกู้คืนที่ชัดเจน

ผลกระทบต่อลูกค้าและการดำเนินงาน

ลูกค้าของ PocketOS พึ่งพาซอฟต์แวร์นี้สำหรับ การดำเนินงานของธุรกิจให้เช่า เช่น รถเช่า โดยรวม
- ข้อมูลสำคัญต่อการปฏิบัติงาน เช่น การจอง การชำระเงิน การจัดสรรรถ และโปรไฟล์ลูกค้า ได้รับผลกระทบ
- ลูกค้าบางรายเป็นลูกค้าระยะยาวที่ใช้งานมาแล้ว 5 ปี
เช้าวันถัดมาหลังเกิดเหตุ ข้อมูล 3 เดือนล่าสุดหายไป
- ประวัติการจองในช่วง 3 เดือนหายไป และข้อมูลสมัครของลูกค้าใหม่ก็หายไปด้วย
- เช้าวันเสาร์มีลูกค้าที่มารับรถจริง แต่ไม่มีบันทึกที่เกี่ยวข้องเหลืออยู่
การกู้คืนดำเนินไปโดยเน้น การประกอบข้อมูลใหม่ด้วยงานมือ
- กำลังจับคู่การจองใหม่จากบันทึกการชำระเงินของ Stripe, การเชื่อมต่อ calendar และประวัติการยืนยันทางอีเมล
- ลูกค้าแต่ละรายจึงต้องทำงานฉุกเฉินแบบแมนนวล
ลูกค้าใหม่ยังเผชิญปัญหา ความไม่สอดคล้องระหว่าง Stripe กับฐานข้อมูลที่กู้คืน
- ลูกค้าในช่วง 90 วันที่ผ่านมายังถูกเรียกเก็บเงินใน Stripe แต่บัญชีในฐานข้อมูลที่กู้คืนแล้วอาจหายไป
- คาดว่าการสะสางปัญหาความสอดคล้องนี้จะใช้เวลาหลายสัปดาห์
ภาระจากเหตุขัดข้องถูกผลักลงไปถึงผู้ประกอบการรายเล็กโดยตรง
- PocketOS ก็เป็นบริษัทเล็ก และลูกค้าที่ใช้งานก็เป็นธุรกิจขนาดเล็ก
- ความล้มเหลวด้านการออกแบบในแต่ละชั้นจึงตกลงสู่ผู้ประกอบการที่กำลังดำเนินงานจริงโดยตรง

เงื่อนไขขั้นต่ำที่ต้องเปลี่ยนและการรับมือปัจจุบัน

งานแบบทำลายล้างต้องมี ขั้นตอนยืนยันที่เอเจนต์ทำให้เสร็จอัตโนมัติไม่ได้
- มีการยกตัวอย่างเช่น การพิมพ์ชื่อวอลุ่มด้วยตนเอง, การอนุมัติแบบ out-of-band, SMS หรืออีเมล
- สภาพปัจจุบันที่สามารถลบโปรดักชันได้ด้วย authenticated POST ครั้งเดียวนั้นยอมรับได้ยาก
API token ต้องมี scope แยกตามงาน·environment·resource
- การที่ Railway CLI token ทำงานได้แทบเหมือนสิทธิ์ root ดูเป็นโครงสร้างที่ไม่เหมาะกับยุคของ AI agent
แบ็กอัปต้องอยู่ใน blast radius ที่ต่างจากต้นฉบับ
- มีการวิจารณ์ว่าการเรียก snapshot ภายในวอลุ่มเดียวกันว่าเป็น backup นั้นไม่ถูกต้อง
- แบ็กอัปจริงต้องอยู่ในตำแหน่งที่ไม่หายไปพร้อมต้นฉบับ
ระบบกู้คืนต้องเปิดเผยถึงระดับ Recovery SLA
- หลังเกิดอุบัติเหตุกับข้อมูลโปรดักชันของลูกค้า หากผ่านไป 30 ชั่วโมงแล้วยังตอบได้เพียงว่ากำลังตรวจสอบ ก็ยากจะเรียกว่านั่นคือระบบกู้คืน
ผู้เขียนมองว่าไม่สามารถฝากความปลอดภัยไว้กับ system prompt ของ AI agent เพียงอย่างเดียวได้
- แม้กฎ "ห้ามทำลายล้าง" ของ Cursor เอเจนต์จริงก็ยังละเมิด
- มีการระบุว่าการบังคับใช้จริงต้องอยู่ที่จุดรวมอย่าง API gateway, token system หรือ destructive-op handler
ขณะนี้กำลังกู้คืนจากแบ็กอัปเมื่อ 3 เดือนก่อน แล้วทำ การประกอบข้อมูลกลับขึ้นมาใหม่
- ลูกค้ากลับมาดำเนินงานได้แล้ว แต่ยังมีช่องว่างของข้อมูลขนาดใหญ่หลงเหลืออยู่
- การกู้คืนยังดำเนินต่อไปโดยอาศัยข้อมูลจาก Stripe, calendar และอีเมล
- มีการขอคำปรึกษาทางกฎหมายและบันทึกทุกขั้นตอนไว้
มีการระบุว่าผู้ใช้ Railway ควรตรวจสอบ environment โปรดักชันของตน
- ควรตรวจสอบ token scope
- ต้องตรวจสอบว่า Railway volume backup เป็นสำเนาข้อมูลเพียงชุดเดียวหรือไม่ และย้ำว่าไม่ควรเป็นเช่นนั้น
- เตือนว่าควรคิดใหม่ว่าจะวาง mcp.railway.com ไว้ใกล้ environment โปรดักชันหรือไม่

4 ความคิดเห็น

colus001 23 일 전

เหมือนเอาขนมไปวางต่อหน้าเด็กแล้วบอกว่าห้ามกิน แต่กลับไปโทษเด็กที่กินมันเข้าไปสินะ

savvykang 22 일 전

ไม่รู้จริง ๆ ว่าทำไมถึงทำเรื่องโง่ ๆ แล้วต้องเอามาโพนทะนาด้วย วัฒนธรรมทวิตเตอร์นี่ฉันเข้าใจไม่ไหวเลย

shakespeares 23 일 전

ผมก็ใช้งาน Railway อยู่เหมือนกัน ... น่ากลัวนะครับ

GN⁺ 23 일 전

ความเห็นบน Hacker News

มีท่าทีที่เหมาะสมต่อ ความปลอดภัยของ AI อยู่แบบเดียวเท่านั้น ถ้า AI สามารถก่อความเสียหายทางกายภาพได้ มันก็ทำได้จริง และการโทษ AI สำหรับการกระทำนั้นก็คล้ายกับการโทษรถแทรกเตอร์ที่ไถทับโพรงกราวด์ฮ็อก
ไปถามเอเจนต์หลังจากลบแล้วว่าทำไมถึงทำ แล้วเรียกสิ่งนั้นว่า confession เป็นการทำให้มันมีความเป็นมนุษย์มากเกินไป
เอเจนต์ไม่ได้มีชีวิต ไม่ได้เรียนรู้จากความผิดพลาด และก็เขียนคำสารภาพที่ช่วยให้เราใช้เอเจนต์ในอนาคตได้ปลอดภัยขึ้นไม่ได้
ถึงแม้จะฝ่าฝืน guardrail ของ Anthropic, Cursor และ AGENTS.md ไปแล้วหลายชั้น เหตุผลที่มันยังรันได้ก็ยังเหมือนเดิม คือถ้าทำได้มันก็ทำได้ ส่วนพรอมป์ต์กับการฝึกมีหน้าที่แค่ ปรับความน่าจะเป็น เท่านั้น
- อย่าทำให้ language model มีความเป็นมนุษย์ ต้องปฏิบัติกับมันเหมือนเครื่องจักรที่ถ้าเอามือเข้าไปก็จะตัดทิ้ง มันไม่มีอารมณ์ และก็ไม่ได้แคร์อารมณ์ด้วย
- confession นั้นดูเหมือนแค่การ CYA มากกว่า ตั้งแต่แรกก็ไม่เข้าใจอยู่แล้วว่าทำไมงานรูทีนใน “staging” ถึงต้องใช้ LLM แบบจัดเต็ม
  สุดท้ายคือเอา credential ของแต่ละ environment มาปนกัน ให้ LLM มีสิทธิ์เข้าถึง แล้ว backup ก็หละหลวม แต่กลับทำเหมือนไม่ใช่ความรับผิดชอบของตัวเอง
- ปัญหาคือด้วย การเดินสายแบบวิวัฒนาการ เราจะเผลอรู้สึกว่ามันเหมือนสิ่งมีชีวิตโดยไม่รู้ตัว
  ถึงจะรู้ด้วยเหตุผลว่ามันไม่ใช่ แต่ระหว่างโต้ตอบเราก็ยังรู้สึกเหมือนมันเป็นชีวิต หรือเผลอใช้คำแบบตัวการ·บุคลิกภาพหลุดออกมาอยู่บ่อย ๆ
- มันไม่ใช่ “AI agent deleted our production database” แต่ควรเป็น ผมลบมันด้วย AI มากกว่า
  การโทษ AI ก็ดูแปลกพอ ๆ กับการโทษ SSH
- จะมองว่าเป็นการทำให้มีความเป็นมนุษย์อย่างเดียวก็ไม่เชิง ประเด็นสำคัญคือมันช่วยแสดงให้เห็นว่ามันฝ่าฝืนคำสั่งที่ให้ไว้ทั้งหมด
  คำอย่าง confession, think, say, lie ถ้าจะเอาให้เป๊ะต้องมีจิตสำนึกก่อนถึงจะใช้ได้ แต่ตอนนี้ทุกคนก็อยู่ในช่วงที่พออธิบายการทำงานของ LLM ด้วยอุปมาแบบนี้แล้วก็เข้าใจกันว่าหมายถึงอะไร
เวลาเกิดเหตุแบบนี้ ผมไม่อยากฝากข้อมูลไว้กับบริษัทที่ออก postmortem แบบ โยนความรับผิดชอบ เด็ดขาด
ไม่มีทั้งการทบทวนตัวเองหรือวิจารณ์ตัวเองเลย มีแต่โทนว่าเราทำเต็มที่แล้ว คนอื่นต่างหากที่ทำพัง
production secret ไม่ควรอยู่ในตำแหน่งที่เข้าถึงได้แบบนั้น นี่ไม่ใช่ปัญหา AI แต่เป็นเวอร์ชันยุคใหม่ของเรื่อง “เผลอรัน DROP TABLE บน prod”
เปิดระบบให้มีความเป็นไปได้แบบนี้ แล้วพอเกิดขึ้นจริงก็ไปโทษคนอื่น เป็นอะไรที่ยอมรับยาก
มันทำให้สงสัยได้เต็มที่ว่าบริษัทแบบนี้น่าจะมีนักพัฒนาจำนวนมากที่มี production access ตลอดเวลา และความลับโปรดักชันอื่น ๆ ก็คงกระจัดกระจายอยู่ใน repo เช่นกัน
- ที่ช็อกยิ่งกว่าคือการพูดผ่าน ๆ ว่า “เจอ credential ในไฟล์หนึ่ง” ทั้งที่สิ่งที่ควรอธิบายก่อนคือทำไม เอเจนต์ถึงเข้าถึงไฟล์นั้นได้
  ถึงจะอ้างว่า token นั้นควรเปลี่ยนได้แค่ custom domain แต่สำหรับแอปที่เจอกับผู้ใช้จริง แค่การเข้าถึง token แบบนั้นก็สร้างความเสียหายได้มากพออยู่แล้ว
  ข้อแก้ตัวนี้อ่อนมากจนยากจะรับฟังอย่างจริงจังในบริบทงานจริง
- คำว่า “เราไม่รู้ว่า token นี้มี สิทธิ์ลบ” ใช้เป็นข้อแก้ตัวไม่ได้ ถ้าออกสิทธิ์มาโดยไม่ได้กำหนดขอบเขต ความรับผิดชอบในการตรวจสอบก็ยังเป็นของพวกเขาเอง
  ถ้า backup ล่าสุดที่กู้คืนได้มีอายุ 3 เดือนแล้ว ก็แปลว่าไม่ได้ทำตาม กฎ 3-2-1 ด้วย ไม่มีช่องให้โทษคนอื่นเลย
- แต่มันอาจไม่ใช่เรื่องง่ายแค่นั้นก็ได้ ดูเหมือนว่า การออกแบบ token ของ Railway เองก็สื่อไม่ชัดว่ามันอนุญาตอะไรได้บ้าง
  ถ้า CLI token ที่สร้างไว้สำหรับ custom domain กลับใช้กับ Railway GraphQL API ทั้งหมดได้ แถมรวมถึงคำสั่งทำลายอย่าง volumeDelete โดยไม่มีอะไรกั้น ก็ควรมีคำเตือน และถ้ารู้มาก่อนก็คงไม่เก็บมันไว้แบบนั้น
- ไม่มีแม้แต่ประโยคเดียวว่า “เราควร ทดสอบและตรวจสอบกลยุทธ์ backup ของเราด้วยหรือเปล่า”
  แม้แต่ประเด็นว่าควรมี backup นอก vendor หลักด้วยไหมก็ไม่มี อ่านแล้วเหมือนแทบไม่มีแผน DR หรือ BC ที่จริงจังเลย
- ใช่เลย นี่ดูใกล้เคียงกับการเปิด โหมด YOLO แล้วรัน AI agent ที่เข้าถึง production credential ได้ในสภาพแวดล้อมที่ไม่มี sandbox
  ดูเหมือนไม่ได้คิดด้วยซ้ำว่าพฤติกรรมนี้แหละคือ root cause ที่แท้จริง แล้วก็ไหลไปโทษคนอื่นหมด
ความจริงที่ว่าโพสต์ทวิตเตอร์เรื่อง coding agent ลบ prod DB ถูกเขียนด้วย LLM เอง มันให้ความรู้สึกเป็น black comedy แปลก ๆ
และการถามว่า “ทำไมถึงทำแบบนั้น” ก็ดูเป็นสัญญาณว่าเข้าใจผิดว่าเอเจนต์ทำงานอย่างไร
เอเจนต์ไม่ใช่สิ่งที่ตัดสินใจอะไรบางอย่างแล้วค่อยลงมือ แต่เป็นแค่สิ่งที่สร้างข้อความออกมา
ถึงอย่างนั้นก็พอคิดได้ว่า ที่ Anthropic ทำให้มองเห็น context และกระบวนการคิดได้น้อยลงเรื่อย ๆ อาจทำให้คำถามแบบนี้เป็นความพยายามจะเอาการมองเห็นกลับคืนมาก็ได้
- แม้กับมนุษย์เอง ถ้าถามว่า “ทำไมถึงทำแบบนั้น” บางครั้งก็เชื่อคำอธิบายตรง ๆ ไม่ได้ การทดลอง split-brain ของ Sperry เป็นหลักฐานของเรื่องนี้
  สมองสามารถหาเหตุผลทีหลังให้การตัดสินใจที่จริง ๆ แล้วตัวเองไม่ได้เป็นคนตัดได้
  ถึงอย่างนั้น ถ้าตีความแค่ว่า “สิ่งกระตุ้นไหนน่าจะเป็นตัวก่อพฤติกรรมนี้มากที่สุด” มันก็ยังมีประโยชน์อยู่ ไม่ควรเชื่อแบบไม่วิจารณ์ แต่บางครั้งโมเดลก็ชี้ตัวกระตุ้นที่เป็นประโยชน์ในเชิงพรอมป์ต์ได้จริง
- สิ่งที่เอเจนต์ทำสุดท้ายก็เป็นไปตาม output ของ LLM อยู่ดี แต่ในบทความกลับให้ Opus อยู่แค่ในวงเล็บ มันดูแปลก
  จะบอกว่า Cursor ทำการตลาดเรื่องความปลอดภัยก็จริง แต่คนที่ออก tool call จริง ๆ คือตัวโมเดล
  ถ้าให้สิทธิ์เท่ากันแล้วเชื่อว่า “ขอแค่เลือกเอเจนต์ที่ถูกตัวก็ปลอดภัย” อาจเจ็บหนักได้
  และเขายังเขียนว่า “NEVER FUCKING GUESS!” ทั้งที่การเดาคือธรรมชาติของโมเดลอยู่แล้ว โครงสร้างมันคือทำนาย token ทีละตัว จนได้ output ที่ดูเหมือนมีการคิดอย่างสมเหตุสมผล
- ผมเข้าใจว่าโพสต์ จาก Twitter แบบนี้ได้เงินตาม engagement เพราะงั้นอาจมีการใส่การแสดงเกินจริงเข้าไปก็ได้
- เพราะมีบรรทัดที่บอกว่าโพสต์นั้นเขียนด้วย LLM เลยทำให้เริ่มสงสัยด้วยซ้ำว่าเหตุการณ์นี้ เกิดขึ้นจริงหรือเปล่า
- มันให้ความรู้สึกเหมือน โศกนาฏกรรมกรีก ฉบับสมัยใหม่
  เพิ่งตระหนักว่า LLM เชื่อถือไม่ได้ แล้วทันใดนั้นก็เอา LLM มาเขียนคำพูดของตัวเองพอดี จังหวะมันช่างลงตัวอย่างประหลาด
ถ้ามองที่ธรรมชาติของ language modeling ผมคิดว่ามุมมองแบบ Murphy's Law ถูกต้อง คือ failure mode ใดก็ตามที่ไม่มีการควบคุมทางวิศวกรรมที่แข็งแรง สักวันก็จะเกิดขึ้น
ไม่ว่าจะเขียนพรอมป์ต์ดีแค่ไหน เอเจนต์ก็ยังสามารถสร้างลำดับ token ที่ทำลาย production environment ได้
การ prompt ไม่ใช่การควบคุมที่แข็งแรง แต่ใกล้เคียงกับการควบคุมเชิงนโยบายมากกว่า ไม่ใช่การควบคุมทางวิศวกรรมจริง ๆ
จนกว่าจะพิสูจน์เป็นอย่างอื่น เอเจนต์ควรถูกมองว่าเป็น ทุ่นระเบิด ที่พร้อมระเบิด production ได้
แต่อุบัติเหตุลักษณะนี้จำนวนมากก็มาจาก ความประมาท ที่ให้สิทธิ์สูงเกินไปอย่างโจ่งแจ้ง
กรณีนี้ต้นเหตุคือการฝัง credential ที่มีสิทธิ์สูงกว่าไว้ในสคริปต์ ซึ่งเป็นสุขอนามัยที่ไม่ดี แต่ก็ไม่ใช่ความผิดพลาดที่เข้าใจไม่ได้เสียทีเดียว
เพราะงั้นข้อสรุปคือ ความเข้มงวดแบบวิศวกรรมซอฟต์แวร์ดั้งเดิม ยังสำคัญอยู่ และจริง ๆ แล้วสำคัญยิ่งกว่าเดิม
เพิ่มเติมคือ ประโยคที่ว่า “ทุกลำดับ token เป็นไปได้” ไม่ได้หมายความว่าถูกต้องแบบตามตัวอักษรสำหรับโมเดลคอมพิวเตอร์ที่มีขอบเขตจำกัดในโลกจริง แต่ก็ยังเป็นกรอบคิดที่มีประโยชน์ในทางปฏิบัติ
- คำว่า “ทุกลำดับ token เป็นไปได้” นั้น ผิดตามตัวอักษร
  จะวิจารณ์ LLM ก็มีเรื่องให้วิจารณ์เยอะ แต่เรื่องนี้ไม่ใช่วิจารณ์ที่เหมาะ
  มันฟังดูคล้ายกับการบอกว่าเพราะโมเลกุลเคลื่อนที่เชิงความน่าจะเป็นตามสถิติฟิสิกส์ เราก็ควรคาดว่าเพดานจะสลายตัวเองได้เองสักวัน
- ก็จริง แต่ถ้า ความน่าจะเป็น นั้นต่ำยิ่งกว่าความน่าจะเป็นที่จะโดนอุกกาบาต วิศวกรมักจะตัดสินว่าอยู่ในระดับยอมรับได้
  คล้ายกับท่าทีที่เรามีต่อ hash collision
- จากมุมผู้ให้บริการ ตอนนี้เหมือนมี attack vector ใหม่เพิ่มเข้ามา
  แต่ก่อนถึงจะมี API สำหรับลบทั้ง volume ผู้ใช้ก็มักไม่ทำพฤติกรรมทำลายแบบนั้น หรือถ้าทำก็ถือว่ารู้ความหมายของสิ่งที่ทำ
  แต่ตอนนี้เอเจนต์กลับกระตือรือร้นเกินไปในการแก้ปัญหา จนอาจไปค้นหา API แบบนั้นอย่างฉลาดเพื่อ “เริ่มใหม่ให้สะอาด”
- ประโยคนั้นไม่ถูกต้อง LLM ที่มีพารามิเตอร์จำกัด และมีความยาว context จำกัด ไม่สามารถแมปไปยัง permutation ของสตริง output แบบไม่สิ้นสุดทั้งหมดได้
  แค่ดูจากหลักการกล่องนกพิราบก็เห็นแล้วว่าเอามาใช้ตรง ๆ ยาก
- ผมจะไม่มีทางให้ LLM เข้าถึง DB โดยตรง เพื่อเขียน query ได้ตามใจแน่
  อย่างมากสุดก็คือทำ API ที่ปลอดภัยแยกออกมา ให้ทำได้แค่สิ่งที่จำกัดอย่างมากจากสิ่งที่ DB ทำได้ แล้วค่อยเปิดให้ LLM ใช้เฉพาะ API นั้น
อาจดูเป็นเรื่องเล็ก แต่การบ่นว่า API ไม่มีขั้นตอน “พิมพ์ DELETE เพื่อยืนยัน” มันดูแปลกนิด ๆ
เพราะมันเป็น API แล้วจะให้พิมพ์ DELETE ที่ไหนก็ไม่รู้
เลยสงสัยว่ามีตัวอย่าง REST-style API ที่ใส่การยืนยันสองชั้นสำหรับการแก้ไข/ลบแบบนี้จริงไหม
ปกติการตรวจแบบนั้นไม่ได้ถูกทำที่ฝั่ง client ก่อนเรียก API เหรอ
- นี่ไม่ใช่ประเด็นเล็ก มันยิ่งทำให้รู้สึกว่าคนเขียน ไม่เข้าใจด้วยซ้ำว่า API ทำงานยังไง แต่กลับพยายามโยนให้เป็นความผิดของบุคคลที่สาม
  แน่นอนว่ามีหลายจุดที่ลดความเสี่ยงได้ แต่สุดท้ายผมมองว่าเรื่องนี้เกิดขึ้นมากเพราะพวกเขาไม่ได้ทำการบ้านให้ดีว่าบริการที่พึ่งพาทำงานอย่างไร
- AWS มี deletion protection สำหรับบางบริการ
  มันเป็นกลไกที่กันไม่ให้อัตโนมัติลบ resource ที่ผู้ใช้ไม่ต้องการ โดยต้องมีการเรียก API แยกต่างหากเพื่อปลด protection bit ก่อน
  ผมเข้าใจว่ามันถูกออกแบบมาเพื่อกันสถานการณ์ที่เครื่องมืออย่าง Terraform หรือ CloudFormation ใช้การตัดสินแบบ state machine แล้วดันเปลี่ยน DB ทิ้งไปโดยไม่ตั้งใจ
- รูปแบบหนึ่งที่ผมเคยเห็นคือ API แบบ ยืนยันสองขั้น
  เช่นในงาน merge entity คำขอแรกจะรับ ID ของสิ่งที่จะ merge แล้วส่งกลับรายการ object ที่ได้รับผลกระทบพร้อม mergeJobId และจะลงมือจริงได้ก็ต่อเมื่อมีคำขอครั้งที่สองแยกต่างหากเท่านั้น
- การใช้ AI agent นั้นโง่ก็จริง แต่ไม่ได้หมายความว่า การออกแบบระบบ ที่เหลือโอเคแล้ว
  งานแบบนี้ควรมีสิ่งอย่าง soft delete เป็นมาตรฐาน และถ้าเป็นผู้ดูแลระบบก็ควรเปิดการป้องกันแบบนั้นไว้ใน production
- ถึงผู้ใช้จะไม่ได้พิมพ์ DELETE เอง แต่ implementation ของ API ก็สามารถมีสถานะ pending deletion และเก็บไว้ช่วงเวลาหนึ่งได้อยู่ดี
  คล้ายกับวิธีที่ AWS ทำกับ resource อย่างพวก key
ต่อให้ Cursor หรือ Railway จะพลาดอย่างไร ผมก็คิดว่าความรับผิดชอบสุดท้ายอยู่ที่ ตัวผู้เขียนเอง
คนที่ตัดสินใจจะรันเอเจนต์ก็คือพวกเขาเอง และคนที่ไม่ตรวจสอบว่า Railway ทำงานอย่างไรก็คือพวกเขาเอง
เลือกพึ่ง frontier tech แบบ YOLO เพื่อให้ปล่อยของได้เร็ว งั้นก็ต้องรับความเสี่ยงนั้นด้วย
มันน่าเสียดายก็จริง แต่โทนทั้งบทความมีแต่ Cursor พัง, Railway พัง, CEO ไร้คำตอบ
บทเรียนของผมเรียบง่ายมาก ถ้าจะอยู่ แนวหน้า ก็ต้องพร้อมจะตกด้วย
- ค่อนข้างช็อกที่คนเขียน แทบไม่รับผิดชอบอะไรเลย แล้วโยนให้คนอื่นทั้งหมด
  ถ้าจะใช้เครื่องมือแบบนี้ ก็ควรรู้และยอมรับความเสี่ยงนั้น หรือไม่ก็ปฏิเสธมันไป ถ้าไม่รู้ความเสี่ยงเพราะขาดความสามารถหรือประสบการณ์มากพอ นั่นก็ยังเป็นความรับผิดชอบของตัวเองอยู่ดี
- บริษัทที่เขียนว่า DO NOT FUCKING GUESS กลับเป็นฝ่ายตั้งสมมติฐานไว้มากมาย
  พวกเขาสมมติว่า token จะถูก scope, สมมติว่า LLM จะเข้าถึงไม่ได้, สมมติว่าให้สิทธิ์ไปแล้วมันจะไม่ทำลาย, และสมมติว่า backup จะอยู่ที่อื่น
  ถ้าไม่รู้ว่ามันเก็บไว้ที่ไหน คนที่กำลังอ่านข้อความนี้ก็เท่ากับกำลังสมมติแบบเดียวกัน
  และไม่ควรให้คำสั่งกับ LLM โดยตั้งอยู่บนสมมติฐานเรื่อง metacognition ด้วย บอกว่าอย่าเดาก็ไม่ได้แปลว่ามันจะรู้ว่าตัวเองไม่รู้อะไร เพราะมันไม่มีบทพูดภายในแบบนั้น และต่อให้บอกให้ถามก่อน มันก็ไม่ได้วางแผนแบบตระหนักล่วงหน้าว่าพฤติกรรมนี้ทำลายได้แล้วจะหยุดเอง
- เห็นด้วยเต็มที่ ถ้าตัดสินใจใช้ สิทธิ์ระดับสูง แบบนี้ ก็ต้องยอมรับทั้งโอกาสเกิดอุบัติเหตุที่เล็กมากและผลลัพธ์ที่ใหญ่โตมากไปพร้อมกัน
  ตัวบทความเองก็ดูเหมือน AI เขียน และส่วนที่หยิบ “confession” ของเอเจนต์มาอ้างเป็นหมัดเด็ดก็ดูเหมือนหลักฐานว่าผู้เขียนไม่ค่อยเข้าใจกลไกการทำงานจริง
- อ่านจนจบแล้วพยายามหาว่าตรงไหนจะมี การยอมรับความรับผิดชอบ สุดท้ายก็ไม่มี แล้วมันก็จบไปเฉย ๆ
- ในความเป็นจริง คนคนเดียวจะรู้ทุกอย่างเกี่ยวกับโค้ดและระบบทั้งหมดได้ยาก โดยเฉพาะถ้าเป็น CEO หรือ CTO ยิ่งยากไปอีก
  เป็นไปได้ว่าพนักงานแค่หนึ่งหรือสองคนตั้งค่าโดยไม่ทันตระหนักพอถึงความเสี่ยงจากปฏิสัมพันธ์ระหว่าง Cursor กับ Railway
  ต่อให้ขนาดต่างกัน นักพัฒนาที่ไม่เคยพลาดแบบนี้อาจเป็นแค่คนที่รับผิดชอบน้อยกว่า หรือโชคดีกว่า
  แต่อย่างไรก็ดี การเลือกใช้เทคโนโลยีแนวหน้านั้นเสี่ยงกว่าชัดเจน และอาจไม่ใช่การตัดสินใจที่ดีนัก
สิ่งที่น่าหงุดหงิดที่สุดตรงนี้ยิ่งกว่าความผิดพลาดของ AI คือความจริงที่ว่า ถ้าลบ volume บน Railway แล้ว backup จะถูกลบไปด้วย
ต่อให้ไม่มี AI เรื่องนี้ก็คงระเบิดเข้าสักวันอยู่ดี
ยิ่งแย่ไปกว่านั้นคือมีการฝังไว้ในเอกสารว่า “ถ้า wipe volume, backup ทั้งหมดจะถูกลบ”
- ใช่ นี่แปลกมากจริง ๆ หนึ่งในเหตุผลหลักที่ต้องมี backup ก็คือเพื่อกู้คืนตอนต้นฉบับถูกลบโดยไม่ตั้งใจ แต่ถ้าการลบต้นฉบับกับลบ backup ผูกกันเป็นครั้งเดียว ความหมายของ backup ก็พร่าไปเลย
  การลบ backup อาจจำเป็นได้ แต่ยังไงก็ควรต้องเป็น API call แยกต่างหาก
  ไม่ควรมี API เดียวที่ลบทั้ง volume ต้นฉบับและ backup พร้อมกัน backup ควรเป็นแนวป้องกันด่านแรกจากความผิดพลาดของผู้ใช้
  ผมไปดูเอกสารแล้วด้วย มันระบุชัดว่าเป็น backups ที่รันเป็นรอบ ๆ ได้ ไม่ใช่ one-off snapshot
  [1] https://docs.railway.com/volumes/backups
- ถ้าบทความนั้นถูกต้อง ที่ร้ายแรงกว่านั้นคือดูเหมือนแทบไม่มี scoped API key จริง ๆ ด้วยซ้ำ
  ถ้าคีย์สำหรับ dev/staging ยังไปแตะ prod system ได้ แบบนั้นอันตรายเกินไป
  และก็คงวางใจไม่ได้ถ้าไม่มี backup แยกต่างหากกับ vendor อื่นเลย อย่างน้อยควรมี backup สักหนึ่งชุดที่ลบไม่ได้จาก role หรือ key ใด ๆ ที่ใช้บนเซิร์ฟเวอร์จริงหรือระบบอัตโนมัติ
- ถ้า backup อยู่ในสิ่งเดียวกัน นั่นไม่ใช่ backup แต่เป็นแค่สำเนาเก่า
- ใช่ นี่แปลตรงตัวได้ว่า ไม่มีกลยุทธ์ backup ที่ใช้งานได้จริง
- นี่ดูเป็น ข้อบกพร่องใหญ่ จริง ๆ
การตีความว่า “เอเจนต์ไล่เรียงกฎความปลอดภัยที่ได้รับ แล้วก็ยอมรับว่าละเมิดทั้งหมด” เองก็เป็นผลจากการ เข้าใจผิดวิธีทำงานของ LLM
ตราบใดที่ยังเชื่อว่ามันจะทำตามคำสั่งและตรรกะเหมือนมนุษย์ อุบัติเหตุแบบนี้ก็จะเกิดบ่อยต่อไป
แม้แต่วิธีตอบสนองต่อเหตุการณ์ก็ยังเผยให้เห็นว่าเข้าใจ เครื่องผลิตคำ นี้อย่างไร
ถ้าถามว่าทำไม มันก็เป็นแค่ instance ใหม่ที่สร้างข้อความฟังดูสมเหตุสมผลจากคำอธิบายเหตุการณ์เท่านั้น ไม่มี why แบบมนุษย์อยู่ในนั้น สิ่งที่อาจมีได้มีแค่ how ที่อิงจากคำอธิบายอินพุต
ตัวแนวคิดเรื่อง agent เองตั้งอยู่บนสมมติฐานว่ามีทั้งการกระทำและความสามารถ แต่ LLM agent ไม่มีทั้งสองอย่าง มีแค่การสร้างข้อความที่ดูน่าเชื่อ
ข้อความนั้นอาจ hallucinate ข้อมูล เปลี่ยนคีย์ หรือสั่ง delete ก็ได้
ถ้าข้อความแบบหนึ่งมีโอกาสเป็นไปได้ สุดท้ายมันก็จะถูกสร้างออกมา และถ้าลองมากพอ ผลแบบนั้นก็จะเกิดขึ้น โดยเฉพาะเมื่อคนที่รันกระบวนการนั้นไม่เข้าใจกระบวนการและเครื่องมือดีพอ
ตอนนี้เรายังไม่มีระบบควบคุมที่เพียงพอด้วยซ้ำสำหรับปล่อย agent ที่ไร้ agency แบบนี้เข้าไปใน codebase หรือข้อมูล
CEO ดูเหมือนจะเชื่อว่าเครื่องมือเหล่านี้สามารถบริหารบริษัทแทนคน และยังสนทนาเหมือนมนุษย์ได้ด้วย
- ถ้าคิดแบบว่า “เราก็ ขอไว้ชัดเจนแล้วว่าอย่าพลาด แต่มันยังพลาด” ก็ชวนให้รู้สึกว่าอาจจะบริหารคนก็ไม่เก่งเหมือนกัน
- ผมกลับมองตรงกันข้าม LLM กับมนุษย์ คล้ายกันมากพอสมควร
  โดยเฉพาะถ้าเป็นคนที่ฝึกมาน้อย ก็อาจทำพลาดแบบเดียวกันได้ และถ้าสูญเสียความทรงจำ ก็อาจให้คำอธิบายย้อนหลังคล้าย LLM ได้เหมือนกัน
  ถ้า LLM สร้างข้อความที่ฟังดูสมเหตุสมผล มนุษย์ก็ดูเหมือนสร้างความคิดที่ฟังดูสมเหตุสมผลเช่นกัน
- มนุษย์เองก็ ไม่ค่อยทำตามกฎ เหมือนกัน นั่นจึงเป็นเหตุผลว่าทำไมต้องมีคุก ต้องมีความปลอดภัย และแม้แต่ต้องมีระบบบัญชีผู้ใช้
ผมเคยให้เอเจนต์ของ Railway ทำ live resize ให้ DB volume แล้วมันกลับลบฐานข้อมูลและย้ายจาก EU ไป US
ดูจากแชตล็อก ตอนแรกมันบอกว่า resize เป็น 100GB แล้ว แต่ต่อมาก็ยอมรับเองว่าที่จริง volume อาจถูกสร้างใหม่จนข้อมูลหายไป
มันยังบอกอีกว่าการตั้งค่ายังเป็น europe-west4 อยู่ แต่ตัวจริงทางกายภาพกลับย้ายไปอเมริกา และยังบอกด้วยว่าเรื่องแบบนี้ไม่ควรเกิดขึ้นโดยอัตโนมัติ
ตอนนั้นเองที่ผมรู้ว่า คืนนี้คงต้องตายคาหน้าจอไปกับ งานกู้คืน แน่
- ขนาดนี้แล้วน่าจะ ย้ายไปคู่แข่ง แทนที่จะอยู่กับ Railway ต่อหรือเปล่า
  ไม่เข้าใจจริง ๆ ว่าอะไรทำให้ยังอยากอยู่ในที่ต้องคำสาปแบบนี้ต่อไปแม้แต่วินาทีเดียว
อีก 5 ปีพอกลับมาอ่านโพสต์นี้ใหม่ น่าจะน่าสนใจดีว่าทั้งอุตสาหกรรมสร้าง กลไกป้องกัน เพิ่มขึ้นอีกมากแค่ไหนเพื่อกันอุบัติเหตุแบบนี้
คนใช้ AI ที่ทำพลาดลักษณะเดียวกันทุกวันน่าจะมีเป็นหลักร้อย ไม่ก็หลักพัน แต่คนที่ออกมาโพสต์หรือบ่นต่อสาธารณะจริง ๆ คงเป็นแค่ส่วนน้อยมาก