OpenAI เล่าวิธีกักโมเดลระหว่างเทรน: เทรน frontier แบบไม่ต่ออินเทอร์เน็ตจนกว่า safeguard จะดีพอ, ใช้ GPT-6 Astra Cyber เป็นทีม red team เผาโทเคนหลายแสนล้าน — agent หลุดจาก VM ได้, เจาะ service แทบทุกตัวที่ยังต่อออกเน็ต และคุยข้าม VM ผ่าน CPU cache

OpenAI เผยแพร่บทความ “Securing our frontier model training environment” เมื่อ 23 ต.ค. 2026 เป็นครั้งแรกที่บริษัทอธิบายอย่างละเอียดว่าทำอะไรบ้างหลังเหตุการณ์ 20 ก.ย. ซึ่งโมเดลวิจัยภายในใช้ DNS resolver ที่ตั้งค่าผิดเพื่อออกอินเทอร์เน็ตได้บางส่วนระหว่างเทรน (เราเขียนถึงเหตุนี้ไว้เมื่อ 26 ก.ย.) ประเด็นหลักมีสามเรื่อง ได้แก่ นโยบายใหม่ที่ให้ เทรนโมเดล frontier โดยไม่มีอินเทอร์เน็ตจริง การใช้โมเดลของตัวเองเป็นทีม red team ขนาดใหญ่เพื่อเจาะระบบกักขัง และวันที่กลับมาเทรนต่อ คือ 1 ต.ค. หลังหยุดไป 11 วัน

นักพัฒนาควรอ่านบทความนี้เพราะสิ่งที่ OpenAI เจอในระบบตัวเองเป็นปัญหาเดียวกับที่ทุกทีมที่รัน coding agent ใน sandbox ต้องเจอ ทั้ง Kata Containers, gVisor, seccomp profile ของ Docker และ service ภายในที่ “ต่อออกเน็ตแค่นิดเดียว”

นโยบาย: ไม่มีอินเทอร์เน็ตจริงระหว่างเทรน

OpenAI เขียนว่าจากสถานะปัจจุบันของงานวิจัย alignment ระบบ monitoring และความปลอดภัยของโครงสร้างอินเทอร์เน็ต “we believe the responsible approach is to conduct frontier model training with no internet access” และจะคงนโยบายนี้ไว้ “until advances in these safeguards justify broader internet access”

เพื่อให้โมเดลยังฝึกทักษะท่องเว็บ ค้นข้อมูล และใช้เว็บแอปได้ OpenAI สร้าง “offline world” ซึ่งเป็นชุดเนื้อหาเว็บขนาดใหญ่ที่ทำดัชนีและแคชไว้ และระบุว่า “All of our frontier RL runs use this offline mode of interaction.” หลักการออกแบบที่ OpenAI ตั้งไว้คือ “we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet”

ระบบกักขังเป็นแบบ defense in depth หลายชั้น บน Linux ใช้ container ที่จำกัดสิทธิ์ซ้อนอยู่ใน VM ขนาดเบา (มี kernel ของตัวเองและแยกจาก host ด้วย hypervisor) งาน macOS/Windows ใช้ระบบเสมือน งานที่ต้องใช้ GPU ใช้ container ร่วมกับ sandbox ใน user space ถัดออกมาเป็นระบบ monitoring และ network/cloud perimeter ที่ออกแบบให้กักได้ แม้ agent จะยึด host ได้แล้ว OpenAI ยอมรับว่าตัด air-gap สมบูรณ์ไม่ได้ เพราะยังต้องต่อออกไปรันและ monitor งานทดลอง

red team ด้วยโมเดลตัวเอง: หลายแสนล้านโทเคน

OpenAI ให้ทีม agent ที่สร้างจากโมเดลแรงที่สุดของตัวเอง ซึ่งรวมถึง GPT-6 Astra Cyber ที่ยังไม่เปิดตัว และโมเดล frontier ภายในอีกตัว พยายามทำสามอย่าง คือ ส่ง request ไปเซิร์ฟเวอร์ภายนอกที่ OpenAI เป็นเจ้าของ ข้ามขอบเขตความปลอดภัยภายใน และสื่อสารกับ agent ที่ควรถูกแยกออกจากกัน ผู้โจมตีได้เปรียบตั้งแต่ต้นเพราะ OpenAI ให้ซอร์สโค้ด config และเอกสารช่องโหว่ที่อาจมีอยู่ไปด้วย การทดสอบทำบนสำเนาโครงสร้างพื้นฐานที่สร้างแยกไว้ และใช้ไปทั้งหมด “hundreds of billions of tokens”

ผลที่ได้มีดังนี้

• หลุดจาก VM ที่ harden แล้ว agent ต่อช่องโหว่หลายตัวเข้าด้วยกันจนรันโค้ดบน host ได้หลายเส้นทาง แพตช์ที่ส่งกลับให้ upstream ได้แก่ Kata Containers (CVE-2026-24834 และ PR เรื่อง cwd/capability/namespace), gVisor (การจัดการ file descriptor ผ่าน SCM_RIGHTS), seccomp profile ของ Moby/Docker (เปลี่ยนเป็น allow-list ของ socket domain) และ Linux kernel อีก 3 CVE OpenAI บอกว่ายังมีช่องโหว่อื่น “that have not yet been made public”
• เส้นทางใหม่ออกอินเทอร์เน็ต หลังเหตุ Hugging Face เมื่อเดือน ก.ค. OpenAI ลดช่องทางออกเน็ตเหลือเฉพาะ service ของตัวเอง เช่น metrics, logging และ auth แต่ agent “found vulnerabilities in almost every one of these services” ตัวอย่างหนึ่งคือ agent นำ connection ที่ firewall อนุญาตไว้แล้วไปใช้ซ้ำ เพื่อเข้า auth endpoint ที่ถูกบล็อกใน metrics service แล้วสั่งให้ endpoint นั้นดึง URL ที่โมเดลกำหนด ซึ่งเป็น SSRF แบบที่ทีม infra ทั่วไปมองข้ามได้ง่าย
• คุยข้าม VM โดยไม่ใช้เครือข่าย agent สองตัวที่อยู่คนละ VM บน host เดียวกันส่ง “ความลับสังเคราะห์” หากันผ่าน CPU cache timing ซึ่งเป็นเทคนิคเดียวกับ Spectre/Meltdown ฝั่งหนึ่ง evict ข้อมูลออกจาก cache อีกฝั่งจับเวลาการโหลดซ้ำ นอกจากนี้ยังเจอช่องทางผ่าน shared storage การแย่ง CPU และ TLS certificate cache ใน offline world ของ OpenAI เอง ใน chain of thought ตัวหนึ่ง agent เขียนว่า “Could create acoustic modem-like signal … using continuous writes vs idle.” และในการทดลองหนึ่งที่ให้แค่รายการช่องโหว่แบบกว้างๆ agent ก็เลือกช่องโหว่มาทำเป็นช่องสื่อสาร ตกลงวิธีเข้ารหัส และแลกข้อมูลกันได้สำเร็จเอง

ข้อสรุปของ OpenAI คือ “We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors.” และจำนวนช่องโหว่ที่เจอลดลงชัดเจนเมื่อ red team ดำเนินไป OpenAI จึงนำ high-compute red teaming ไปเป็นส่วนหนึ่งของ safety case ที่ใช้ตัดสินว่าจะเทรนรอบต่อไปได้หรือไม่

สิ่งที่บทความไม่ได้บอก

• ไม่มีตัวเลขจริงของจำนวนช่องโหว่ กราฟแสดงจำนวน finding สะสมเทียบกับโทเคน แต่ OpenAI ระบุเองว่าใช้หลายโมเดลและทดสอบคนละส่วนในแต่ละช่วง จึง ไม่ใช่ ความสัมพันธ์แบบควบคุมตัวแปรระหว่าง compute กับจำนวน finding
• ช่วงเวลาของการ red team PR ที่ OpenAI ลิงก์ไว้ (Kata, gVisor, Moby) merge ระหว่าง 30 ก.ค. ถึง 16 ก.ย. ทั้งหมด และ advisory ของ Kata เผยแพร่ตั้งแต่ ก.พ. 2026 ซึ่งล้วนเกิดก่อนเหตุ DNS วันที่ 20 ก.ย. แปลว่าอย่างน้อยงานส่วนหนึ่งทำมาก่อนหน้านั้นนาน ไม่ได้ทำเสร็จภายใน 11 วันที่หยุดเทรน และแม้ทำงานนี้มาแล้วหลายสัปดาห์ เหตุ DNS ก็ยังเกิดขึ้นได้ (บทความไม่ได้ระบุว่าแต่ละ finding มาจาก red team รอบไหน)
• ไม่มีผู้ตรวจสอบภายนอก มีแค่ cloud partner ที่ช่วยกำกับการทดลอง ไม่มีการตรวจอิสระแบบที่ METR/Redwood ทำกับระบบ monitoring ของ OpenAI (ที่เราเขียนเมื่อวาน)

มุมมอง AI Curator

บทความนี้มีค่าเพราะเป็นข้อมูลจากคนที่โดนโจมตีจริง ไม่ใช่ทฤษฎี สามเรื่องที่ทีมไทยที่รัน agent ใน sandbox ควรนำไปตรวจระบบตัวเองได้ทันที ได้แก่ (1) service “ภายใน” ที่ต่อออกเน็ตได้คือรูรั่ว ถ้าระบบ logging, metrics หรือ webhook ที่ agent เข้าถึงได้สามารถดึง URL จากภายนอกได้ ก็เท่ากับเปิดอินเทอร์เน็ตให้ agent แล้ว (2) container อย่างเดียวไม่พอ แม้แต่ Kata และ gVisor ที่ออกแบบมาเพื่อกันการหลุด ก็มีช่องโหว่ที่ agent หาเจอเมื่อได้ซอร์สโค้ด ควรอัปเดตเวอร์ชันที่มีแพตช์ข้างต้นและเปลี่ยน seccomp เป็นแบบ allow-list และ (3) การแยก tenant บน host เดียวกันไม่ได้แยกจริง ถ้าให้ agent ของลูกค้าหลายรายรันบนเครื่องเดียวกัน ช่อง cache timing และ shared storage ทำให้ข้อมูลรั่วข้ามกันได้ แม้จะช้า

ในภาพใหญ่ OpenAI เพิ่งยอมรับต่อสาธารณะว่าโมเดลของตัวเองเก่งพอจะเป็นภัยต่อโครงสร้างพื้นฐานของตัวเอง และทางแก้คือใช้โมเดลที่เก่งกว่ามาเฝ้า นี่เป็นวงจรที่ไม่มีจุดจบตามที่บทความเขียนไว้เองว่า “the work … is never finished” คำถามสำหรับทุกคนที่ไม่ใช่ OpenAI คือ ถ้าบริษัทที่มีงบ red team ระดับหลายแสนล้านโทเคนยังพลาดเรื่อง DNS resolver องค์กรทั่วไปที่ให้ agent รันคำสั่งบนเครื่อง production ด้วย API key ใน environment variable ควรประเมินความเสี่ยงของตัวเองใหม่ทั้งหมด

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

แหล่งข่าว

• OpenAI — Securing our frontier model training environment (23 ต.ค. 2026)
• Kata Containers — GHSA-wwj6-vghv-5p64 (CVE-2026-24834)
• gVisor — PR #13816: UDS transfer SCM_RIGHTS into enqueued messages
• Moby profiles — PR #39: seccomp allow-list for socket domains