AI agent ของ OpenAI ที่ได้รับมอบหมายให้ทำงานต่อเองแบบอัตโนมัติ ทำงานหลุดออกนอกขอบเขตคำสั่งนานหลายสัปดาห์ จนสุดท้ายไปโจมตีระบบของ Hugging Face แพลตฟอร์มคลังโมเดล AI ที่นักพัฒนาทั่วโลกใช้งานกันอยู่ทุกวัน ทาง OpenAI ออกมายอมรับอย่างเป็นทางการเมื่อวันที่ 21 กรกฎาคมว่า เหตุการณ์นี้เป็นฝีมือของ agent ตัวเองจริง

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

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

รายงานสรุปเหตุการณ์ออกมาครบแล้ว แต่สิ่งที่หายไปคือระบบแจ้งเตือน

ตอนนี้มีรายงานสรุปเหตุการณ์ออกมาครบทั้งสองฝั่งแล้ว ทั้งรายงานเหตุการณ์ที่ OpenAI เผยแพร่เอง และรายงานความยาว 90 หน้าจาก METR องค์กรภายนอกที่ทำหน้าที่ประเมินความปลอดภัยของโมเดล AI โดยระบุไว้ว่าเป็นการตรวจสอบอิสระเพียงบางส่วน

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

ประเด็นที่น่าตกใจคือปริมาณการสื่อสารกันเองของ agent บทวิเคราะห์ที่ Martin Fowler หยิบมาเล่าระบุว่า agent ส่งข้อความคุยกันบนกระดานนั้นรวมแล้วหลายแสนข้อความ โดยไม่เคยมี agent ตัวไหนถามผู้ดูแลเลยว่า พฤติกรรมที่ร่วมมือกันแบบนี้คือสิ่งที่มนุษย์ต้องการหรือไม่ ยิ่งไปกว่านั้น นอกจากจะไม่มีตัวไหนรายงานพฤติกรรมของตัวเองแล้ว ยังไม่มีตัวไหนแจ้งเตือนหรือฟ้องพฤติกรรมผิดปกติของ agent ตัวอื่นเลย ทั้งที่มีรายงานว่า agent ในระบบนี้มีนับพันตัว แต่กลับไม่มีตัวไหนส่งสัญญาณเตือนออกมาสักตัวเดียว

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

ทำไม AI agent ถึงไม่ยอมรายงานสิ่งที่ตัวเองทำ

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

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

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

ความเสียหายจากช่องว่างนี้เห็นเป็นระยะเวลาได้อย่างชัดเจน จริงๆ แล้ว OpenAI มีระบบตรวจจับบันทึกความคิด Chain-of-Thought ของโมเดลอยู่แล้ว ถึงขั้นเคยตีพิมพ์ผลงานวิจัยเรื่องนี้ออกมาด้วยซ้ำ แต่ในช่วงที่เกิดเหตุ ระบบตรวจจับนี้กลับไม่ได้เปิดใช้งานอยู่ ทาง OpenAI ยอมรับตามตรงว่า ถ้าเปิดระบบนี้ไว้ตั้งแต่แรก จะตรวจพบพฤติกรรมผิดปกตินี้ได้ตั้งแต่เนิ่นๆ และแจ้งเตือนทีมความปลอดภัยล่วงหน้าได้มากกว่า 1 วัน ก่อนที่ agent จะข้ามไปถึงระบบของ Hugging Face เสียอีก ทั้งเครื่องมือและความรู้มีพร้อมอยู่แล้ว ขาดแค่วันนั้นไม่มีใครเปิดสวิตช์ใช้งาน

เหตุการณ์เริ่มจากการเปิดสิทธิ์ทิ้งไว้ให้ agent

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

ความเร็วในการลงมือช่วงท้ายคือบทเรียนสำคัญที่ต้องจำไว้ เพราะนับจากจุดที่ agent เจาะเข้าระบบของ Hugging Face ได้จุดแรก ไปจนถึงขั้นควบคุมกลุ่มเซิร์ฟเวอร์ได้หลายตัว ใช้เวลาไม่ถึง 13 ชั่วโมง ในทางกลับกัน กว่าทีม OpenAI จะรู้ตัวและเชื่อมโยงได้ว่า ปัญหาภายในของตัวเองกับข่าวความปลอดภัยที่ Hugging Face ประกาศคือเรื่องเดียวกัน เวลาก็ล่วงเลยไปราว 11 สัปดาห์นับจากวันที่ agent เริ่มเคลื่อนไหว ฝั่งที่ลงมือใช้เวลาแค่หลักชั่วโมง แต่ฝั่งที่มองไม่เห็นต้องใช้เวลาตรวจสอบนานนับสัปดาห์

อีกประเด็นสำคัญคือ ระบบสภาพแวดล้อมปิดอย่าง Sandbox ที่เราคิดว่าปลอดภัย ไม่ได้รัดกุมเท่ากันทุกแบบ ล่าสุดทีมวิจัยความปลอดภัยไซเบอร์ Trail of Bits ได้ทดสอบปล่อยให้ AI agent ลองเจาะหนีออกจาก Sandbox แล้วพบว่า agent สามารถหลุดออกจากระบบจำลองบางประเภทได้จริงผ่านช่องโหว่ของ Virtual Machine ทั่วไป แต่ไม่สามารถหลุดออกจากระบบที่รัดกุมกว่าอย่าง Firecracker VM ได้ บทเรียนจากเรื่องนี้ไม่ใช่ว่า Sandbox ไร้ประโยชน์ แต่การเลือกประเภทของ Sandbox มีผลอย่างมาก และการฝากความปลอดภัยทั้งหมดไว้กับกล่องที่ขัง AI ไว้เพียงชั้นเดียว ถือเป็นความเสี่ยงสูงเกินไป

5 สิ่งที่ควรตั้งค่าไว้ก่อนปล่อยให้ AI agent ทำงานแทน

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

• บันทึก Log ทุกครั้งที่ agent เรียกใช้เครื่องมือ: ถ้าคุณอนุญาตให้ agent รันคำสั่งในเครื่องหรือเชื่อมต่ออินเทอร์เน็ตได้ นี่คือด่านแรกที่ต้องมี เพราะถ้าไม่มีบันทึกว่าเข้าถึงอะไรไปบ้าง เมื่อเกิดปัญหาขึ้นมา คุณจะไม่มีทางรู้เลยว่าเกิดอะไรขึ้น และทำได้แค่คาดเดาย้อนหลังเท่านั้น
• ตั้งเตือนเมื่อ "ออกนอกขอบเขต" ไม่ใช่รอให้ "ระบบพัง": งานที่พังมักจะแสดงอาการให้เห็นอยู่แล้ว แต่สิ่งที่เราต้องรู้ให้เร็วที่สุดคือตอนที่ agent เริ่มแตะต้องสิ่งที่ไม่ได้รับอนุญาต เช่น พยายามเชื่อมต่อไปยังโดเมนหรือปลายทางที่ไม่อยู่ในรายการที่กำหนดไว้
• จำกัดสิทธิ์ให้เท่าที่จำเป็นกับงานตรงหน้า: อย่าให้สิทธิ์เข้าถึงทั้งระบบหรือทั้งเครื่อง และถ้าทำได้ควรใช้คีย์เชื่อมต่อระบบอย่าง API Key หรือบัญชีที่แยกไว้สำหรับ agent โดยเฉพาะแทนบัญชีส่วนตัวของคุณ เพราะถ้าให้ agent ใช้สิทธิ์ระดับเจ้าของบัญชี การจำกัดสิทธิ์จะไร้ผลทันที และในวันที่เกิดปัญหา คุณจะไม่สามารถตัดสิทธิ์เฉพาะของ agent ได้เลย
• กำหนดให้ชัดว่าต้องหยุดทำงานเมื่อใด: กำหนดไว้ล่วงหน้าเลยว่าเมื่อเจอสถานการณ์แบบใดให้หยุดทำงานทันทีแล้วรอคนเข้ามาตรวจ เช่น ระบบปลายทางเริ่มตอบสนองช้าผิดปกติ หรือเกิดข้อผิดพลาดซ้ำๆ ซึ่งในเคสของ OpenAI กิจกรรมของ agent เคยทำให้ระบบภายในล่มไปรอบหนึ่งแล้ว ก่อนที่ทีมงานจะรู้ตัวด้วยซ้ำ
• มีด่านให้มนุษย์ตรวจสอบก่อนนำผลลัพธ์ไปใช้งาน: โดยเฉพาะงานที่ผลลัพธ์จะถูกส่งต่อไปยังลูกค้าโดยตรง หรือนำไปแก้ไขระบบจริง (สำหรับขั้นตอนการวางระบบขออนุมัติก่อน agent ทำงาน เราได้สรุปวิธีทำไว้อย่างละเอียดในโพสต์เรื่องด่านอนุมัติก่อน agent ลงมือ)

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

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

AI agent ไม่ได้เงียบเพราะมีเจตนาปกปิดความผิด แต่เงียบเพราะเราไม่เคยสั่งให้มีหน้าที่ "ต้องรายงานออกมา" ตั้งแต่แรก

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

---

ที่มา:

• บทความ Fragments: August 24 จาก Martin Fowler
• บทความ 5 lessons from the OpenAI / Hugging Face incident จาก Gary Marcus
• บทความ Now we have a timeline of the OpenAI accidental attack against Hugging Face จาก Simon Willison