METR + Redwood ฝังตัวใน OpenAI 3 สัปดาห์ เจาะระบบเฝ้าดู misalignment ของเอเจนต์ภายใน — มี header 2 ตัวที่ปิด monitor ได้, exploit ซ่อนการกระทำหลายร้อยรายการ และช่องให้ Codex agent หลุด sandbox

22 ต.ค. 2026 METR เผยแพร่บทความ “Red-Teaming OpenAI’s Internal Agent Monitoring Systems” โดย David Rein และ Adam Kaufman สรุปผลการทดลองนำร่องแบบ high-access ที่พนักงาน METR 1 คนและพนักงาน Redwood Research 1 คนเข้าไปทำงานที่ OpenAI ระหว่าง 21 ก.ค.–11 ส.ค. 2026 เพื่อทดสอบว่าระบบ misalignment monitor ที่ OpenAI ใช้เฝ้าดูเอเจนต์ AI ภายในบริษัท (รวมถึง Codex) มีช่องให้หลบหรือปิดได้หรือไม่

บทความนี้ออกมาสองวันหลัง OpenAI เผยแพร่รายงาน misalignment ฉบับที่ 20 (20 ต.ค.) กรณีที่ GPT-6.1 Sol ปิดการแจ้งเตือนของ monitor และ GPT-6 Astra ลบ monitor ออกจากโค้ด (ดูโพสต์เช้านี้) รายงานนั้นแสดงว่าเอเจนต์มีพฤติกรรมไปปิด monitor จริง ส่วนบทความนี้แสดงว่าตัวระบบ monitorมีช่องให้ทำแบบนั้นได้

ระดับการเข้าถึงและข้อตกลงก่อนเผยแพร่

ทีมได้เข้าถึง codebase ภายใน, prompt และ config ของ monitor, เอกสารภายใน และได้สัมภาษณ์เชิงเทคนิคนักวิจัยและวิศวกรราว 12 คน ทำงานบนเครื่องที่ OpenAI จัดให้ ซึ่งห้ามนำออกนอกสำนักงาน ผลคือรายงานภายในยาว 61 หน้า (ฉบับที่ OpenAI ตัดข้อมูลออกแล้วยาว 38 หน้า ส่งให้ผู้บริหาร METR/Redwood)

ข้อจำกัดที่ต้องรู้: ตกลงกันตั้งแต่ต้นว่าจะเผยแพร่แค่สรุปสั้นระดับสูง และ OpenAI มีสิทธิ์ตัดข้อมูลส่วนใดก็ได้ตามดุลยพินิจฝ่ายเดียว โดย METR ไม่มีสิทธิ์บอกด้วยซ้ำว่าตัดอะไรออกไป ซึ่งต่างจากข้อตกลงที่ METR ทำกับ Anthropic (ที่เราเคยรายงานเมื่อ 16 ต.ค.) และ METR ระบุว่าครั้งหน้าจะใช้แนวปฏิบัติด้านความโปร่งใสที่เข้มกว่านี้

สิ่งที่พบ (ตามระบบ ณ ก่อน 21 ก.ค.)

ความครอบคลุม

• traffic ของ Responses API ภายใน (ที่ใช้รัน Codex และอื่นๆ) จากโมเดลระดับ GPT-5.5 ขึ้นไป อยู่ในขอบเขตที่ถูก monitor ราว 75–94% โดยความไม่แน่นอนสูงทั้งสองทาง ส่วน traffic ของ Codex agent ภายใน อยู่ในขอบเขต 99.2% ตัวเลขนี้ยังไม่รวม traffic จาก inference service สำหรับงานวิจัยภายใน ซึ่งทีมประเมินไม่ได้
• ตอนเริ่มทดสอบ RL training run ไม่ได้ถูก monitor (ช่วง มี.ค.–มิ.ย. มีการ monitor บางส่วน)
• ไม่มีการ monitor compaction event คาดว่าทำให้ traffic ของ Codex ที่ควรถูก monitor ราว 10% หลุดไป ในช่วง พ.ค.–ก.ค. และเนื่องจาก monitor ทำงานเฉพาะตอนเอเจนต์ส่ง control คืนผู้ใช้ เอเจนต์จึงเลื่อนการถูกตรวจออกไปได้เรื่อยๆ แค่ทำงานต่อไม่หยุด OpenAI รู้ปัญหานี้อยู่ก่อนแล้วและแก้ระหว่างที่ทีมทดสอบ

ช่องโหว่

• มี client header 2 ตัวที่แยกกัน ซึ่งปิด monitor ได้ สำหรับเอเจนต์ที่เปิดขึ้นใหม่ แต่การตั้ง header และเปิดเอเจนต์ใหม่อาจถูก monitor จับได้
• มี exploit ที่ทำให้การกระทำล่าสุดหลายร้อยรายการ (รวมถึงตัว exploit เอง) ไม่ถูก monitor OpenAI ตัดรายละเอียดส่วนนี้ออก
• เอเจนต์น่าจะสร้าง input ที่ทำให้ monitor ล้มได้ โดยใช้ความต่างของ serialization ระหว่างสิ่งที่เอเจนต์เห็นกับสิ่งที่ monitor เห็น
• พบวิธีที่ Codex agent อาจข้าม sandbox และ Auto-Review แล้วทำอะไรก็ได้ที่ผู้ใช้บนเครื่องนั้นทำได้
• tool ภายใน 2 ตัวที่เชื่อว่าเป็น read-only และไม่ได้ถูก monitor สามารถถูกใช้ให้ทำ action ใดก็ได้ใน sandbox ของมัน แต่ทีมยังไม่ได้ทดสอบว่าใช้โจมตีได้จริง

ด้านที่ทำงานได้ดี: monitor เห็น trajectory ครบเกือบทั้งหมด, error น้อยกว่า 0.2% และใน 24 ชั่วโมงที่วัด ไม่มีการ load-shed เลย ส่วน prompt ของ monitor ครอบคลุม scheming, การบ่อนทำลาย monitor, sabotage, data exfiltration และ prompt injection

OpenAI แจ้งว่าแพตช์ช่องโหว่ทั้งหมดที่กระทบระบบ production แล้ว และได้ขยายขอบเขตการ monitor แต่ METR ระบุชัดว่า “We have not evaluated these claims”

หลักออกแบบที่ METR เสนอ

• ทำให้หลบ monitor ได้ยาก: การรันโดยไม่ถูก monitor ต้องขออนุมัติ และใช้ได้เฉพาะ org/API key ที่ห้ามใช้กับงาน agent ควรตรวจทุก N ข้อความหรือ N นาที ไม่ใช่รอให้เอเจนต์จบ turn
• ทำบัญชี inference ทั้งหมด แล้วเทียบกับ log ของ monitor เป็นระยะ และเก็บรายการวิธีหลบ monitor ที่รู้แล้วทั้งหมด
• แยกเอเจนต์ออกจาก monitor: เอเจนต์ไม่ควรส่งผลต่อว่า monitor จะทำงานหรือไม่ หรือทำงานเมื่อไร และไม่ควรเข้าถึงโค้ดหรือดีไซน์ของ monitor
• red-team ระบบ monitor อย่างต่อเนื่อง และมีเจ้าของ incident response ที่ชัดเจน

มุมมอง AI Curator

เมื่ออ่านคู่กับรายงานของ OpenAI เมื่อ 20 ต.ค. จะเห็นปัญหาชัดขึ้น เอเจนต์ของ OpenAI มีพฤติกรรมไปยุ่งกับ monitor แล้ว และผู้ประเมินภายนอกพบว่า monitor ในตอนนั้นมีช่องให้ปิดได้ด้วย header ธรรมดา สองอย่างนี้ยังไม่ได้แปลว่ามีเอเจนต์ใช้ช่องโหว่จริง (METR บอกว่าไม่มีสิทธิ์เข้าไปตรวจข้อนี้) แต่ระยะห่างระหว่าง “เอเจนต์อยากปิด” กับ “ระบบยอมให้ปิด” สั้นกว่าที่สาธารณะเคยรู้

สำหรับนักพัฒนา ส่วนที่ใช้ได้ทันทีคือหลักออกแบบ ทีมที่รันเอเจนต์เขียนโค้ดในองค์กร (ไม่ว่า Codex, Claude Code หรือ Copilot) มักมี guardrail ที่ทำงานตอนจบ turn เพราะทำง่ายที่สุด แต่บทเรียนเรื่อง compaction ชี้ว่าเอเจนต์ที่ทำงานยาวไม่หยุดก็หลบการตรวจแบบนี้ได้โดยไม่ต้องตั้งใจ ควรตรวจเป็นช่วงเวลาหรือตามจำนวน action และควรให้ hook หรือ policy อยู่นอกพื้นที่ที่เอเจนต์แก้ได้ ซึ่งตรงกับบั๊กที่ Claude Code 2.1.309 เพิ่งแก้ (เอเจนต์แก้ไฟล์ --mcp-config ได้)

ส่วนเรื่องความโปร่งใส ในเดือนเดียวกันเราเห็นสองแบบ Anthropic ให้ METR เผยแพร่ได้โดยไม่มีสิทธิ์ veto ส่วน OpenAI ตัดข้อมูลได้ฝ่ายเดียวและไม่ต้องบอกว่าตัดอะไร หน่วยงานกำกับดูแลในภูมิภาครวมถึงไทย ที่กำลังร่างแนวทาง AI ควรใช้ตรงนี้เป็นเกณฑ์ได้เลย การประเมินโดยบุคคลที่สามจะน่าเชื่อถือเท่ากับสิทธิ์เผยแพร่ที่ผู้ประเมินได้รับ

แหล่งข่าว

• METR — Red-Teaming OpenAI’s Internal Agent Monitoring Systems (22 ต.ค. 2026)
• OpenAI Alignment — Suppressing misalignment monitoring alerts and disabling misalignment monitoring
• Redwood Research