Copilot มี sandbox แล้ว แต่ AI บนเครื่องคุณอาจยังเข้าถึงไฟล์ได้กว้าง

GitHub เปิด local sandboxing ให้ใช้ทั่วไปวันที่ 7 ตุลาคม โดยไม่คิดเงินเพิ่ม แปลว่าผู้ใช้ Copilot จำกัดสิทธิ์ AI บนเครื่องได้โดยไม่ซื้อส่วนเสริมครับ ครอบคลุม Copilot CLI แอป Copilot และเซสชัน VS Code ที่ใช้ Agent Host ตามประกาศ GitHub

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

สรุป 30 วินาที: เกิดอะไรขึ้น

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

ใน CLI ซึ่งเป็นโปรแกรมที่ใช้งานผ่านหน้าพิมพ์คำสั่ง ให้ใช้ /sandbox enable เพื่อเปิด จากนั้นใช้ /sandbox status ตรวจเซสชันปัจจุบัน ส่วนแอป Copilot ใช้ /sandbox on สำหรับเซสชันที่กำลังทำงาน คำสั่งของสองช่องทางจึงใช้แทนกันไม่ได้ ตามคู่มือใช้งาน

แล้วเปิดแล้วถือว่าปลอดภัยหมดหรือยัง? เอกสาร GitHub ระบุว่า local sandbox เป็นการจำกัดสิทธิ์ระดับระบบปฏิบัติการแบบเบา ไม่ได้แยกคำสั่งไปอยู่ในเครื่องเสมือนหรือคอนเทนเนอร์อีกชุด ซึ่งหมายถึงสภาพแวดล้อมทำงานที่แยกต่างหาก จึงต้องอ่านขอบเขตที่บังคับได้จริง ตามเอกสารแนวคิด

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

สำหรับนักศึกษาหรือคนเขียนโปรแกรมเอง ต้องแยกการจัดไฟล์ออกจากการจำกัดสิทธิ์ด้วยครับ GitHub ระบุว่า working tree ซึ่งแยกไฟล์และสาขางานของแต่ละเซสชัน ไม่ได้ห้ามคำสั่งเข้าถึงส่วนอื่นของเครื่อง การมีพื้นที่งานแยกจึงยังต้องใช้ sandbox เพิ่ม ตามเอกสารตั้งค่าแอป

ทำงานยังไง

เบื้องหลังใช้ Microsoft eXecution Container หรือ MXC เป็นตัวแปลงกฎกลางให้ระบบปฏิบัติการบังคับใช้ กฎระบุได้ว่าเส้นทางไฟล์ใดอ่านได้ เขียนได้ หรือถูกปิดกั้น รวมถึงการเชื่อมต่อเครือข่าย ชื่อเทคโนโลยีมีคำว่า Container แต่ local sandbox ไม่ได้รันทุกคำสั่งในคอนเทนเนอร์แยก ตามGitHub Docs

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

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

เรื่องข้อมูลยืนยันตัวตน ใช้วิธีให้ค่าตัวแทนแก่คำสั่ง แล้วให้ proxy ซึ่งเป็นตัวกลางรับส่งการเชื่อมต่อ เติมค่าจริงเฉพาะปลายทาง HTTPS ที่อนุญาต Git และ gh หรือเครื่องมือจัดการ GitHub ผ่านคำสั่ง เปิดการยืนยันตัวตนไว้เป็นค่าเริ่มต้น ผู้ใช้เลือกปิดได้ ตามคู่มือใช้งาน

การซ่อนค่านั้นครอบคลุมตัวแปรที่เลือกไว้ รวมถึง Git และ gh ที่เปิดใช้เท่านั้น ไม่ได้ซ่อนความลับในไฟล์ข้อมูลยืนยันตัวตนหรือตัวแปรอื่นทั้งหมด อีกทั้งค่าเริ่มต้น Allow dev tool access ยังให้อ่านการตั้งค่าเครื่องมือพัฒนาและข้อมูลที่เก็บชั่วคราว รวมถึงโทเคนที่อยู่ในนั้นได้ โทเคนคือค่าที่ใช้ยืนยันสิทธิ์กับบริการ จึงควรตรวจรายการนี้ด้วย ตามคู่มือใช้งานและคู่มือตั้งค่า

จุดหักมุม: มีให้ใช้ แต่ยังต้องเปิดเอง

แต่ local sandboxing ปิดเป็นค่าเริ่มต้นครับ หากไม่มีนโยบายองค์กรบังคับ คำสั่งยังทำงานด้วยสิทธิ์บัญชีผู้ใช้ การอ่านข่าวว่าเปิดให้ใช้ทั่วไปจึงยังไม่ยืนยันสถานะเครื่องเรา ตามGitHub Docs

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

เรื่องเงิน / ผลกระทบ

GitHub ระบุว่า local sandboxing รวมอยู่กับ Copilot โดยไม่คิดค่าใช้จ่ายเพิ่ม แต่ cloud sandboxing ซึ่งย้ายเซสชันไปทำงานบนระบบของ GitHub คิดตามการใช้งาน และยังอยู่ใน public preview หรือช่วงทดลองที่เปิดให้คนทั่วไปใช้ การเลือกทำงานบนเครื่องกับบนคลาวด์จึงมีเงื่อนไขค่าใช้จ่ายต่างกัน ตามเอกสารแนวคิดและการคิดเงิน

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

องค์กรต้องเผื่อเวลาตรวจระบบปฏิบัติการด้วย macOS แนะนำรุ่น 15 หรือใหม่กว่า แปลว่ารุ่นเก่าไม่อยู่ในขอบเขตที่ทดสอบ แม้ CLI ไม่บล็อกการใช้งาน ส่วน Linux ต้องมี bubblewrap รุ่น 0.5.0 ขึ้นไป แปลว่าต้องตรวจเครื่องมือแยกสิทธิ์ก่อนเปิดใช้งาน ตามข้อกำหนดข้ามแพลตฟอร์ม

บน Linux ยังต้องมี slirp4netns และเครื่องมือเครือข่ายเพิ่มเติมเมื่ออนุญาตการเชื่อมต่อขาออก รายการในเอกสารรวมถึง unshare และ nsenter จาก util-linux รุ่น 2.35 ขึ้นไป แปลว่าตรวจเพียงว่ามี bwrap ยังไม่ครบ นอกจากนี้ระบุ iptables, ip6tables และสิทธิ์เข้าถึง /dev/net/tun ด้วย ตามGitHub Docs

สำหรับ Windows คู่มือระบุ Windows 11 รุ่น 25H2 พร้อมอัปเดต KB5124010 หรือใหม่กว่า แปลว่าชื่อระบบปฏิบัติการอย่างเดียวไม่พอ อีกทางเลือกคือรุ่น 26H1 พร้อม KB5124006 หรือใหม่กว่า และต้องรองรับความสามารถ BaseContainer ตามที่เอกสารกำหนด ไฟล์แหล่งข่าวที่ใช้ไม่ได้บอกว่าต้องเป็น Insiders build จึงไม่ควรสรุปเพิ่มเอง ตามข้อกำหนดใช้งาน

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งสนับสนุนคือ GitHub Changelog ซึ่งชูว่าขอบเขตสิทธิ์ช่วยให้เอเจนต์ทำงานเองได้มากขึ้น โดยยังควบคุมสิ่งที่เข้าถึงได้ ส่วนข้อทักท้วงมาจาก GitHub Docs ขององค์กรเดียวกัน ซึ่งระบุชัดว่า local sandbox เป็นการแยกแบบเบา ไม่มีแหล่งคัดค้านอิสระในชุดข้อมูลนี้ จึงยังสรุปประสิทธิภาพจากคำรับรองบริษัทเพียงอย่างเดียวไม่ได้ ตามประกาศและเอกสารข้อจำกัด

อีกข้อจำกัดคือเครื่องมือไฟล์ที่ติดมากับ CLI ทำงานอยู่ในตัว CLI ซึ่งไม่ได้ถูก sandbox ระบบปฏิบัติการจึงไม่เห็นการอ่านเขียนของเครื่องมือเหล่านี้ GitHub ระบุว่าเครื่องมือตรวจและทำตามกฎด้วยตัวเองแบบ best effort หรือพยายามทำตามให้ดีที่สุด ต่างจากคำสั่งภายนอกที่ถูกบังคับโดยระบบปฏิบัติการ ส่วนเซิร์ฟเวอร์ MCP ระยะไกล ซึ่งเป็นบริการเชื่อมเครื่องมือให้ AI ไม่ถูก sandbox ตามเอกสารแนวคิด

กฎเครือข่ายก็ไม่ได้ให้ผลเท่ากันทุกระบบ บน macOS และ Linux คำสั่งถูกบังคับผ่าน proxy แต่ Windows พึ่งโปรแกรมให้เคารพการตั้งค่า proxy โปรแกรมที่ไม่ทำตามจึงเชื่อมต่อโดยตรงเลี่ยงกฎปลายทางได้ นี่เป็นข้อจำกัดที่ GitHub ระบุเอง ไม่ใช่คำยืนยันว่าป้องกันการส่งข้อมูลออกได้ทั้งหมด ตามคู่มือตั้งค่าเครือข่าย

ส่วนค่าท้องถิ่นของ CLI ที่ปิดไว้ กับแอปที่เปิดไว้ ไม่ใช่ข่าวขัดกัน แต่เป็นคนละช่องทางใช้งาน การเปิดหรือเปลี่ยนกฎในช่องทางหนึ่งไม่เปลี่ยนอีกช่องทาง องค์กรจึงต้องตรวจทั้งสองแบบหากทีมใช้สลับกัน ตามคู่มือตั้งค่า

ถ้าเครื่องไม่รองรับ จะหยุดหรือทำงานต่อ? สำหรับ CLI การตั้งค่าผู้ใช้ให้เปิดอาจถูกปิดเฉพาะเซสชัน พร้อมแจ้งว่าคำสั่งจะทำงานโดยไม่มี sandbox แต่นโยบายองค์กรที่กำหนดทั้ง sandbox.enabled และ sandbox.failIfUnavailable เป็น true จะบล็อกคำขอโมเดลและเครื่องมือเมื่อบังคับ sandbox ไม่ได้ ตามเอกสารกรณีเครื่องไม่รองรับ

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

แล้วเราควรทำอะไร

คนเขียนโปรแกรมเอง: เปิด แล้วตรวจสิทธิ์จริง

1. ตรวจข้อกำหนดระบบจากเอกสาร GitHub ก่อน จากนั้นใน CLI ใช้ /sandbox enable และ /sandbox status ตามลำดับ หากมีเซสชันอื่นเปิดค้าง ต้องเปิดในเซสชันนั้นด้วยหรือเริ่มใหม่ การเปิดในหน้าหนึ่งไม่เปลี่ยนหน้าที่เปิดค้างทันที ตามคู่มือใช้งาน
2. ใช้ /sandbox policy อ่านว่าโฟลเดอร์ใดอ่านหรือเขียนได้ จากนั้นเปิด /sandbox config ตรวจ Filesystem, Network และ Credentials เลือกให้สิทธิ์เฉพาะที่งานต้องใช้ โดยเฉพาะโฟลเดอร์สำคัญและข้อมูลเครื่องมือพัฒนา ตามคู่มือตั้งค่า
3. หากใช้แอป ให้เปิด Settings เลือกโปรเจกต์ใน Projects แล้วเปิด Sandbox new sessions สำหรับงานใหม่ ส่วนงานปัจจุบันใช้ /sandbox on การเปลี่ยนกฎไฟล์หรือเครือข่ายใช้กับเซสชันใหม่หรือหลังเริ่มใหม่ด้วย /restart-session ตามคู่มือตั้งค่าและคู่มือใช้งาน
4. เมื่อขึ้นคำขอทำงานนอก sandbox ให้อ่านคำสั่งและขอบเขตที่เพิ่มก่อนอนุมัติ การอนุมัติข้ามขอบเขตทำให้คำสั่งใช้สภาพแวดล้อมปกติซึ่งอาจมีความลับจริง และไม่อยู่ใต้กฎซ่อนค่าผ่าน proxy ตามคู่มือใช้งาน

หัวหน้าทีมและ IT: กำหนดกฎให้ตรวจได้

1. สำรวจว่าทีมใช้ CLI แอป หรือ VS Code ผ่าน Agent Host แล้วจัดการแต่ละช่องทาง อย่าใช้สถานะจาก CLI ยืนยันทุกช่องทาง เพราะ GitHub ระบุว่าการตั้งค่าท้องถิ่นของ CLI และแอปแยกกัน ตามประกาศและเอกสารแนวคิด
2. พิจารณา enterprise managed settings หรือกฎที่องค์กรจัดการ ซึ่งบังคับ sandbox และป้องกันผู้ใช้ลดข้อจำกัดได้ เอกสารรองรับการจัดการผ่านเซิร์ฟเวอร์ ระบบจัดการอุปกรณ์ และไฟล์นโยบาย หากต้องหยุดเมื่อบังคับไม่ได้ ให้ตรวจเงื่อนไข sandbox.failIfUnavailable ด้วย ตามGitHub Docs
3. ตัดสินใจให้ชัดว่าอนุญาต bypass หรือการข้าม sandbox หรือไม่ การบังคับเปิดอย่างเดียวอาจยังอนุญาตให้ปิดเฉพาะเซสชันได้ ถ้านโยบายยอมให้ bypass แต่เมื่อองค์กรตั้ง sandbox.allowBypass เป็น false ผู้ใช้อนุมัติคำสั่งออกนอกขอบเขตไม่ได้ ตามคู่มือตั้งค่า

ผู้จัดการหรือเจ้าของธุรกิจที่ไม่ได้เขียนโค้ด: ขอคำตอบเรื่องงานและข้อมูล

1. ขอให้ทีมระบุว่าเปิด sandbox ที่ช่องทางใด และตรวจสถานะอย่างไร ขอรายการโฟลเดอร์และบริการที่ AI ต้องเข้าถึง แทนการขอคำตอบกว้าง ๆ ว่าใช้ AI อย่างปลอดภัยแล้ว
2. แยกงานที่ต้องใช้อินเทอร์เน็ตหรือบัญชี GitHub ออกจากงานที่ไม่ต้องใช้ แล้วให้ IT ตรวจการตั้งค่าตามคู่มือ GitHub เอกสารอนุญาตปิดสิทธิ์เหล่านี้ได้ แต่บางงานจะทำต่อไม่ได้ จึงต้องตกลงผลกระทบก่อน
3. ขอแนวทางรับมือเมื่อคำสั่งถูกบล็อก รวมถึงผู้ตัดสินใจให้สิทธิ์เพิ่ม และอย่าใช้คำว่าไม่คิดเงินเพิ่มเป็นเหตุผลข้ามการตรวจระบบ รายการนี้เป็นข้อเสนอสำหรับการคุยในทีม ไม่ใช่ข้อกำหนดที่ GitHub บังคับทุกองค์กร

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

การใช้ AI ลงมือบนเครื่องควรเริ่มจากสิทธิ์ที่งานต้องการ แล้วค่อยเลือกความอิสระที่จะให้ผู้ช่วยครับ สิ่งที่ควรตามต่อคือข้อจำกัดข้ามระบบปฏิบัติการในเอกสาร sandbox และการตรวจสถานะจริงหลังทีมเปลี่ยนเครื่องหรือการตั้งค่า

อีกเรื่องที่เกี่ยวข้องกับกิจวัตรคือประกาศรายสัปดาห์วันที่ 9 ตุลาคม แปลว่ามีการอัปเดตต่อหลังเปิด sandbox แล้ว CLI ใช้ /model ค้นหาโมเดลที่รองรับจาก Ollama ที่กำลังรันบนเครื่องได้ ส่วนแอปแยกบัญชีสำหรับสิทธิ์ Copilot กับบัญชีเข้าคลังโค้ดได้ แต่การเลือกโมเดลกับการจำกัดเครื่องมือเป็นคนละเรื่อง ตามประกาศรายสัปดาห์และประกาศ sandbox

ในเครื่องทำงานของคุณ โฟลเดอร์ไหนที่อยากให้ทีมตรวจว่า AI ไม่มีสิทธิ์อ่านก่อนเริ่มงานครั้งถัดไป?

Recap

• เกิดอะไรขึ้น: GitHub เปิด local sandboxing ให้ใช้ทั่วไป เพื่อจำกัดสิทธิ์เครื่องมือของ Copilot
• ตัวเลขที่จำ: ค่าใช้จ่ายเพิ่มเป็นศูนย์สำหรับ local sandboxing แปลว่าไม่ต้องซื้อส่วนเสริมเพื่อใช้ขอบเขตนี้ตามประกาศ
• อีกด้านของข่าว: GitHub Changelog ชูประโยชน์ ส่วน GitHub Docs ระบุข้อจำกัด ไม่มีเสียงคัดค้านอิสระในแหล่งที่ใช้
• ยังไม่รู้: ไม่มีผลทดสอบอิสระหรือการรับรองว่าปกป้องข้อมูลทุกชนิดได้ครบ
• ผลต่อคุณ: ตรวจสิทธิ์ไฟล์ เครือข่าย และข้อมูลยืนยันตัวตนก่อนให้ AI ทำงานกับข้อมูลจริง
• สิ่งที่จับตา: ความสามารถที่ระบบปฏิบัติการบังคับได้ และสถานะ sandbox ของแต่ละเซสชัน
• แหล่ง [1]: ประกาศเปิดให้ใช้ทั่วไป
• แหล่ง [2]: วิธีเปิดและตรวจสถานะ
• แหล่ง [3]: แนวคิดและข้อจำกัด
• แหล่ง [4]: ประกาศรายสัปดาห์
• แหล่ง [5]: ตั้งค่าสิทธิ์และนโยบาย