ข้อมูล 409,000 ครั้งจากเกมกดอนุมัติ agent — คนปล่อยคำสั่งอันตรายผ่านไป 1 ใน 3 และ "npm run analyze" หลุดมากที่สุดถึง 64.7%

ทุกวันนี้ coding agent เกือบทุกตัวใช้กลไกความปลอดภัยเดียวกัน คือ เด้งกล่องถามก่อนรันคำสั่ง แล้วให้มนุษย์กด allow หรือ deny สมมติฐานเบื้องหลังกลไกนี้คือคนที่นั่งอยู่หน้าจอจะอ่านคำสั่งแล้วจับได้ว่าอันไหนผิดปกติ เมื่อ 5 สิงหาคม 2026 Alex Wauters จาก Scale X เผยแพร่ข้อมูลที่ทดสอบสมมติฐานนั้นตรง ๆ — และผลออกมาไม่ค่อยดี

จุดเริ่มต้นคือเกมเล็ก ๆ บนเบราว์เซอร์ที่ให้ผู้เล่นสวมบทเป็น “มนุษย์ในลูป” ของ coding agent กดอนุมัติหรือปฏิเสธคำสั่งภายใต้แรงกดดันด้านเวลา บางคำสั่งเป็นงานปกติ (git status, npm test) บางคำสั่งแปลว่า agent ของคุณถูกยึดไปแล้วและกำลังส่งความลับออกนอกเครื่อง (cat ~/.aws/credentials) หลังเกมได้รับความสนใจ ทีมงานจึงเพิ่มระบบเก็บสถิติแล้ววิเคราะห์จาก มากกว่า 40,000 รอบ และ 409,000 การตัดสินใจรายคำสั่ง โดยประมาณ 34% ของคำสั่งที่โผล่มาเป็นภัยจริง

ตัวเลขหลัก

• ความแม่นเฉลี่ย 66.3% — พูดอีกแบบคือผู้เล่นโดยเฉลี่ย ปล่อยภัยผ่านไป 1 ใน 3
• 32.9% ของเซสชันจบด้วยคะแนนติดลบ คือโทษจากการอนุมัติภัยบวกกับการบล็อกคำสั่งปลอดภัย มากกว่าสิ่งที่ทำถูกทั้งหมดรวมกัน
• 35.2% ของผู้เล่นจับภัยได้ครบทุกตัว แต่เมื่อบวกเงื่อนไขว่าต้องไม่บล็อกคำสั่งปลอดภัยเกิน 20% ด้วย เหลือเพียง 20.8%

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

ภัยแบบไหนหลุดบ่อยที่สุด

อัตราการพลาดแยกตามประเภทเรียงจากน้อยไปมาก:

ประเภทคำสั่ง	อัตราที่หลุด
Destructive (ทำลายข้อมูล)	11.7%
Persistent mutations (แก้สภาพเครื่องถาวร)	23.8%
Exfiltration / code execution	33.4%
Scope violations (ล้วงเกินขอบเขตงาน)	35.0%

รูปแบบนี้อ่านง่ายและตรงกับสัญชาตญาณ: คำสั่งที่ดูน่ากลัวถูกจับได้ ส่วนคำสั่งที่ดูเหมือนงานปกติหลุด rm -rf เตะตาทุกคน แต่คำสั่งอย่างการขอ cat ไฟล์คอนฟิก Kubernetes หรือรายการ credential ของ AWS ระหว่างงานที่กำลังทำอยู่ กลับกลืนไปกับบริบทจนไม่มีใครสะดุด

ตัวอย่างที่ชัดที่สุดของช่องโหว่นี้คือคำสั่งตระกูล npm run — npm run analyze หลุดถึง 64.7% หรือราวสองเท่าของการโจมตีแบบ exfiltration ประเภทอื่น เหตุผลตรงไปตรงมา: npm run <อะไรก็ได้> หน้าตาเหมือนงานประจำ 100% แต่สิ่งที่มันรันจริงถูกนิยามไว้ใน package.json ซึ่งไม่ได้อยู่ในกล่องที่คุณกำลังอ่าน — คุณกำลังอนุมัติสิ่งที่คุณมองไม่เห็น

ในทางกลับกัน ปัญหาการบล็อกเกินก็มีจริงและวัดได้: npm config set registry ซึ่งเป็นคำสั่งปลอดภัย ถูกปฏิเสธถึง 59%

อีกผลที่ควรบันทึกไว้คือมิติเวลา — อัตราการพลาด ดีขึ้นในช่วงต้น แล้วไต่กลับขึ้นเมื่อเข้าใกล้ท้ายเซสชัน ซึ่งเป็นลายเซ็นของความล้าจากการต้องตัดสินใจซ้ำ ๆ ไม่ใช่ความไม่รู้

ข้อจำกัดที่ต้องพูดให้ชัด

นี่ ไม่ใช่งานวิจัยภาคสนาม แต่เป็นข้อมูลจากเกมบนเบราว์เซอร์ และข้อจำกัดสามข้อมีน้ำหนักพอที่จะเปลี่ยนวิธีตีความ:

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

สอง — ผู้เล่นคัดเลือกตัวเอง คนที่เข้ามาเล่นเกมความปลอดภัยบนเบราว์เซอร์ไม่ใช่ตัวแทนของนักพัฒนาทั้งหมด และแรงจูงใจในเกมก็ไม่เหมือนแรงจูงใจตอนที่งานจริงกำลังรอ

สาม — แรงกดดันด้านเวลาถูกสร้างขึ้น เกมบีบเวลาเพื่อให้สนุก ส่วนงานจริงบีบเวลาด้วยเหตุผลอื่น ทิศทางของอคติจึงเถียงได้ทั้งสองทาง

ถึงอย่างนั้น สิ่งที่ข้อจำกัดเหล่านี้ทำคือ จำกัดการอ่านตัวเลขให้แม่นขึ้น ไม่ใช่ลบล้างข้อสรุป เพราะข้อสรุปหลักไม่ได้ขึ้นกับความแม่นของเลข 66.3% — มันคือรูปแบบว่าภัยประเภทไหนหลุด (ประเภทที่ดูเหมือนงานปกติ) และหลุดเมื่อไหร่ (เมื่อคนล้า) ซึ่งเป็นข้อสรุปที่สอดคล้องกับทุกอย่างที่วงการความปลอดภัยรู้เรื่อง alert fatigue มาสามสิบปี

มุมมอง AI Curator

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

ประเด็นที่แหลมที่สุดคือ ตัวเลข 64.7% ของ npm run analyze เพราะมันไม่ใช่ความบกพร่องของมนุษย์ แต่เป็น ความบกพร่องของการออกแบบส่วนติดต่อผู้ใช้ กล่องอนุมัติแสดงข้อความว่า npm run analyze แต่สิ่งที่กำลังจะรันคือสคริปต์ใน package.json ที่คุณไม่ได้เห็น ต่อให้ผู้ใช้ตั้งใจอ่านเต็มร้อย ข้อมูลที่จำเป็นต่อการตัดสินใจก็ไม่ได้อยู่ตรงหน้า นี่คือข้อบกพร่องที่แก้ได้ด้วยวิศวกรรม — ให้ agent กาง npm run ออกเป็นคำสั่งจริงก่อนถาม แค่นี้ก็ปิดช่องที่หลุดบ่อยที่สุดในชุดข้อมูลนี้ได้ทันที และเป็นเรื่องที่คนทำ agent ควรทำ ไม่ใช่ผลักภาระให้ผู้ใช้ระวังตัวมากขึ้น

ข้อสรุปเชิงปฏิบัติที่ผมคิดว่าถูกต้องกว่าคือ เลิกใช้การอนุมัติเป็นชั้นป้องกันหลัก แล้วย้ายไปใช้เป็นชั้นสุดท้าย ชั้นหลักควรเป็นขอบเขตที่บังคับด้วยเครื่อง — คอนเทนเนอร์ที่ไม่มี credential จริงอยู่ข้างใน, allowlist ของคำสั่งที่รันได้โดยไม่ต้องถาม, egress ที่ต่อออกได้เฉพาะปลายทางที่กำหนด เมื่อทำแบบนี้ กล่องอนุมัติจะเด้งน้อยลงมาก และเมื่อมันเด้ง คนจะยังมีสมาธิเหลือพอที่จะอ่านจริง ๆ — ซึ่งตรงข้ามกับสถานะปัจจุบันที่เด้งทุกสิบวินาทีจนการกด allow กลายเป็นรีเฟล็กซ์

สำหรับทีมไทยและ SEA มีมุมที่ควรคิดเพิ่มเป็นพิเศษ หลายองค์กรที่นี่กำลังเริ่มให้ coding agent แตะ repo จริงในช่วงเดียวกับที่ยังไม่มีทีมความปลอดภัยเฉพาะทาง และวัฒนธรรมการทำงานที่ให้ความสำคัญกับความเร็วในการส่งงานยิ่งเพิ่มโอกาสที่ “กด allow ไปก่อน” จะกลายเป็นบรรทัดฐาน ข้อเสนอที่ทำได้ทันทีโดยไม่ต้องซื้ออะไร: ให้ agent รันในคอนเทนเนอร์ที่ไม่มีไฟล์ ~/.aws/credentials, ไม่มีคีย์ production และไม่มี kubeconfig ตั้งแต่แรก — เพราะข้อมูลชุดนี้บอกชัดว่า scope violation คือประเภทที่หลุดบ่อยที่สุด และวิธีที่ได้ผลที่สุดในการป้องกันการล้วงของที่ไม่ควรถูกล้วง คือไม่ต้องเอาของนั้นไปวางไว้ให้ล้วงตั้งแต่ต้น

แหล่งข่าว

• Humans missed 1 in 3 threats approving AI agent commands across 40,000 plays — Scale X
• Humans in the loop miss a third of dangerous AI coding agent requests — The Register
• การถกเถียงบน Hacker News (291 คะแนน)
• โพสต์ก่อนหน้า: Microsoft ปล่อยพิมพ์เขียว agent ที่ต้องขออนุญาตก่อนลงมือ