ปล่อยให้ Agent รันโค้ดที่มันเขียนเองบนเครื่องจริง แล้วไฟล์หายทั้งโฟลเดอร์ แก้ยังไง

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

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

คำถามที่ทีมพัฒนาถามกันบ่อยหลังเจอเหตุการณ์แบบนี้คือ 'ปล่อยให้ Agent รันโค้ดที่มันเขียนเองบนเครื่องจริง แล้วไฟล์หายทั้งโฟลเดอร์ แก้ยังไง' คำตอบคือต้องแยก Environment สำหรับรันโค้ดที่ Agent สร้างออกจากเครื่องจริงตั้งแต่แรก บทความนี้จะพาวางกรอบออกแบบ Sandbox ที่ใช้ได้จริง ต่อเนื่องจากแนวคิดเรื่องการควบคุมความเสี่ยงที่เคยพูดถึงใน AI agent tool approval

อาการที่เจอบ่อยเมื่อปล่อยให้ Agent รันโค้ดบนเครื่องจริงโดยไม่มี Sandbox

อาการแบบแรกคือ Agent รันคำสั่งที่มีขอบเขตกว้างเกินกว่าที่ตั้งใจ เช่น คำสั่งลบไฟล์ที่ใช้ wildcard ครอบคลุมมากกว่าที่ผู้ใช้ต้องการ หรือคำสั่งติดตั้ง package ที่ดึง dependency มาทับเวอร์ชันเดิมที่โปรเจกต์อื่นบนเครื่องเดียวกันพึ่งพาอยู่ ทำให้โปรเจกต์อื่นพังตามไปด้วยทั้งที่ไม่เกี่ยวข้องกับงานที่กำลังทำ

อาการแบบที่สองคือ Agent เข้าถึงไฟล์หรือข้อมูลที่ไม่ควรเกี่ยวข้องกับงานเลย เช่น ไฟล์ config ที่มี credential ของระบบอื่น หรือไฟล์ .env ที่เก็บ API key เพราะ Agent มีสิทธิ์อ่านเขียนเท่ากับผู้ใช้ทั้งเครื่อง ไม่ได้ถูกจำกัดให้เห็นเฉพาะโฟลเดอร์ที่งานนั้นเกี่ยวข้องจริง ๆ

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

AI Agent Sandbox คืออะไรกันแน่ ต่างจากการรันโค้ดปกติตรงไหน

AI Agent Sandbox คือสภาพแวดล้อมแยกต่างหากที่ถูกจัดเตรียมไว้เฉพาะสำหรับให้ Agent รันโค้ดที่มันสร้างขึ้นเอง โดยไม่มีการเชื่อมต่อโดยตรงกับเครื่อง Production ไฟล์งานจริง หรือข้อมูลสำคัญของระบบหลัก ไม่ว่าคำสั่งที่รันข้างในจะพลาดหรือเป็นอันตรายแค่ไหน ผลกระทบจะจำกัดอยู่เฉพาะภายใน Sandbox นั้นเท่านั้น

ต่างจากการรันโค้ดปกติที่นักพัฒนาเขียนเองบนเครื่องพัฒนา เพราะนักพัฒนารู้ตัวว่ากำลังจะรันอะไรและตรวจสอบก่อนกดรันตามประสบการณ์ของตัวเอง แต่ Agent ตัดสินใจและรันคำสั่งได้เร็วกว่ามาก บางครั้งรันหลายคำสั่งต่อเนื่องกันในเวลาไม่กี่วินาที โดยไม่มีจังหวะให้คนตรวจสอบก่อนแต่ละคำสั่งเหมือนที่นักพัฒนาทำเองตามปกติ ความเสี่ยงจึงต่างกันแม้จะเป็นการ 'รันโค้ด' เหมือนกันก็ตาม

หลักการที่ควรยึดคือ Sandbox ต้องเป็น environment ที่ตั้งค่าใหม่ได้ง่ายและทิ้งได้โดยไม่เสียดาย (disposable) เพราะเป้าหมายไม่ใช่การป้องกันไม่ให้เกิดข้อผิดพลาดเลย แต่เป็นการทำให้ข้อผิดพลาดที่เกิดขึ้นไม่กระทบอะไรที่สำคัญจริง ยิ่ง Sandbox สร้างใหม่และทำลายทิ้งได้เร็วเท่าไร ยิ่งลดความกังวลเรื่องผลข้างเคียงจากการทดลองของ Agent มากเท่านั้น

ทำไมการรันโค้ดที่ Agent สร้างเองบนเครื่องจริงถึงอันตรายกว่าที่คิด

เหตุผลหลักคือ Agent ไม่มีสามัญสำนึกแบบมนุษย์ที่รู้ว่า 'คำสั่งนี้อันตรายเกินไป ควรหยุดคิดก่อน' มันเดินตามตรรกะของ prompt และบริบทที่มีในมือ ถ้าตรรกะนั้นพาไปสู่คำสั่งที่กว้างเกินไปหรือครอบคลุมมากกว่าที่ตั้งใจ มันจะรันคำสั่งนั้นทันทีโดยไม่มีความลังเลแบบที่คนมักมีก่อนรันคำสั่งที่ดูเสี่ยง

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

และเหตุผลที่สำคัญที่สุดคือเครื่อง Production หรือเครื่องพัฒนาจริงมักมีสิ่งที่แก้คืนไม่ได้อยู่เสมอ ไม่ว่าจะเป็นไฟล์ต้นฉบับที่ไม่มีสำเนา credential ของระบบอื่นที่เชื่อมต่ออยู่ หรือ process ที่กำลังให้บริการผู้ใช้จริง การให้ Agent มีสิทธิ์เท่ากับผู้ใช้เต็มรูปแบบบนเครื่องแบบนี้ เท่ากับเปิดโอกาสให้ความผิดพลาดเล็ก ๆ กลายเป็นความเสียหายที่แก้คืนไม่ได้

ระดับของ Isolation ที่เลือกใช้ได้ ตั้งแต่ Process จนถึง Virtual Machine

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

ตัด Network Access และซ่อน Secret ออกจาก Sandbox เป็นค่าเริ่มต้น

หลักที่ควรยึดคือ Sandbox ไม่ควรเข้าถึงเครือข่ายภายนอกได้เป็นค่าเริ่มต้น เว้นแต่งานนั้นจำเป็นต้องเรียก API ภายนอกจริง ๆ เพราะถ้า Sandbox ต่ออินเทอร์เน็ตได้อิสระ โค้ดที่ Agent สร้างอาจส่งข้อมูลออกไปนอกระบบโดยไม่ตั้งใจ หรือดาวน์โหลด package ที่เป็นอันตรายเข้ามาโดยไม่มีใครตรวจสอบก่อน ถ้าจำเป็นต้องเข้าถึงเครือข่าย ควรจำกัดเฉพาะ domain ที่รู้จักและเชื่อถือได้เท่านั้น

Secret หรือ Credential ของระบบจริง เช่น Database Password หรือ API Key ของ Production ไม่ควรถูกส่งเข้าไปใน Sandbox เลย แม้ว่างานที่ Agent ทำจะดูเกี่ยวข้องกับระบบนั้นก็ตาม ถ้าจำเป็นต้องทดสอบการเชื่อมต่อจริง ควรใช้ Credential ของ Sandbox หรือ Environment ทดสอบแยกต่างหากที่ไม่มีสิทธิ์กระทบข้อมูลจริง แนวคิดนี้สอดคล้องโดยตรงกับการแยก credential ของ MCP server ที่เคยพูดถึงในเรื่อง MCP server database

ข้อควรระวังอีกจุดคือ Environment Variable ที่ถูก inherit เข้ามาโดยอัตโนมัติจากเครื่องหลักเวลาสร้าง Sandbox ถ้าไม่ได้กรองออกให้ชัดเจน Sandbox อาจได้รับค่า Secret ติดมาโดยที่ทีมไม่รู้ตัว ควรตรวจสอบรายการ Environment Variable ที่ Sandbox มองเห็นได้จริงทุกครั้งก่อนปล่อยใช้งาน ไม่ใช่สมมติว่าแยกกันแล้วจะปลอดภัยโดยอัตโนมัติ

ตั้ง Resource Limit กัน Sandbox กินทรัพยากรจนกระทบระบบอื่น

Sandbox ที่ไม่มีขีดจำกัดด้าน CPU หน่วยความจำ หรือเวลาในการรัน อาจกลายเป็นปัญหาใหม่แทนที่จะแก้ปัญหาเดิม เช่น โค้ดที่ Agent เขียนเผลอเข้า loop ไม่รู้จบ แล้วกิน CPU จนกระทบ process อื่นที่รันอยู่บนเครื่องเดียวกัน หรือ container เดียวกัน ถ้าไม่มี Resource Limit คั่นไว้ ปัญหาเล็กในโค้ดที่ Agent สร้างจะขยายเป็นปัญหาที่กระทบระบบอื่นทั้งหมด

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

เก็บ Log ทุกคำสั่งที่รันใน Sandbox ไม่ใช่แค่ผลลัพธ์สุดท้าย

การมี Sandbox ที่ปลอดภัยไม่ได้แปลว่าไม่ต้องสนใจว่า Agent รันคำสั่งอะไรบ้าง เพราะเมื่อผลลัพธ์สุดท้ายผิดพลาด ทีมยังต้องรู้ว่าเกิดอะไรขึ้นระหว่างทางเพื่อแก้ไขต้นตอ ควรเก็บ Log ทุกคำสั่งที่ Agent รันใน Sandbox พร้อม timestamp ผลลัพธ์ที่ได้ และ Exit Code ของแต่ละคำสั่ง ไม่ใช่เก็บแค่ไฟล์ผลลัพธ์สุดท้ายที่ Agent ส่งกลับมาให้ผู้ใช้เห็น

ข้อมูล Log นี้มีประโยชน์สองทาง ทางแรกคือใช้ดีบักเมื่อผลลัพธ์ที่ได้ผิดจากที่คาดไว้ ทางที่สองคือใช้เป็นข้อมูลตั้งต้นสำหรับปรับปรุง Skill หรือ Instruction ที่ให้ Agent ทำงาน เพราะบางครั้งการที่ Agent รันคำสั่งอ้อมค้อมกว่าที่ควรเป็น เป็นสัญญาณว่ามันขาดความรู้บางอย่างที่ควรเสริมเข้าไปใน SKILL.md เพื่อให้ทำงานตรงและเสถียรขึ้นในครั้งถัดไป

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอบ่อยตอนออกแบบ AI Agent Sandbox

• ให้ Agent รันโค้ดตรงบนเครื่องพัฒนาจริงเพื่อความสะดวกในช่วงแรก — ทำแบบนี้แล้วพัง เพราะไม่มีชั้นป้องกันใดคั่นระหว่างคำสั่งที่พลาดกับความเสียหายที่เกิดขึ้นจริงบนเครื่อง
• ไม่ตัด Network Access ออกจาก Sandbox เป็นค่าเริ่มต้น — ทำแบบนี้แล้วพัง เพราะโค้ดที่ Agent สร้างอาจส่งข้อมูลออกไปนอกระบบหรือดึงของอันตรายเข้ามาโดยไม่มีใครตรวจสอบก่อน
• ไม่ตั้ง Resource Limit ปล่อยให้ Sandbox ใช้ทรัพยากรได้ไม่จำกัด — ทำแบบนี้แล้วพัง เพราะปัญหาเล็กในโค้ดอย่าง loop ไม่รู้จบ อาจกระทบ process อื่นบนเครื่องหรือ container เดียวกันทั้งหมด
• ปล่อยให้ Environment Variable จากเครื่องหลัก inherit เข้า Sandbox โดยไม่ตรวจสอบ — ทำแบบนี้แล้วพัง เพราะ Secret ของระบบจริงอาจหลุดเข้าไปอยู่ใน Sandbox โดยที่ทีมไม่รู้ตัว
• ไม่เก็บ Log คำสั่งที่รันระหว่างทาง เก็บแค่ผลลัพธ์สุดท้าย — ทำแบบนี้แล้วพัง เพราะเมื่อผลลัพธ์ผิดพลาด จะไม่มีทางไล่ย้อนกลับไปดูว่าคำสั่งไหนเป็นต้นเหตุที่แท้จริง

สรุป

เหตุการณ์ไฟล์หายหรือระบบพังจากโค้ดที่ Agent เขียนเองมักไม่ได้มาจากโค้ดผิดพลาดร้ายแรง แต่มาจากการไม่มีขอบเขตคั่นระหว่างสิ่งที่ Agent ตัดสินใจกับผลกระทบจริงบนเครื่อง Production หรือเครื่องพัฒนา การมี Sandbox ที่แยกออกจากกันชัดเจนคือทางแก้ที่ตรงจุดที่สุด ไม่ใช่การพยายามทำให้ Agent ฉลาดขึ้นจนไม่มีวันพลาดเลย

หลักการที่ควรยึดคือทำ Sandbox ให้สร้างใหม่และทิ้งได้ง่าย ตัด Network Access และ Secret ออกเป็นค่าเริ่มต้น ตั้ง Resource Limit ให้ชัดเจน และเก็บ Log ทุกคำสั่งที่รันระหว่างทาง ไม่ใช่แค่ผลลัพธ์สุดท้าย เมื่อทุกส่วนทำงานร่วมกัน ความผิดพลาดที่เกิดขึ้นได้เสมอจาก Agent จะไม่ลุกลามไปกระทบสิ่งที่แก้คืนไม่ได้

• Sandbox ทำให้ความผิดพลาดของ Agent จำกัดอยู่ในขอบเขตที่ควบคุมได้ ไม่ใช่ป้องกันไม่ให้พลาดเลย
• เลือกระดับ Isolation ให้เหมาะกับความเสี่ยงของงาน ไม่จำเป็นต้องใช้ระดับสูงสุดเสมอไป
• ตัด Network Access, Secret และตั้ง Resource Limit เป็นค่าเริ่มต้นของทุก Sandbox
• เก็บ Log ทุกคำสั่งระหว่างทาง เพื่อดีบักและปรับปรุง Skill ของ Agent ให้ทำงานตรงขึ้นในครั้งถัดไป

คำถามที่พบบ่อย