Copilot CLI 1.0.102 ถามสิทธิ์ซ้ำน้อยลง แต่ต้องรู้ว่าอนุญาตอะไรไป

คำสั่งที่ทำงานในพื้นที่จำกัดของ Copilot CLI 1.0.102 ถูกแก้ให้ทำงานต่อได้อย่างเชื่อถือได้เมื่อเกิน 10 วินาที ตามบันทึกรุ่นวันที่ 21 ตุลาคม 2026 และรุ่นนี้ยังลดการถามสิทธิ์ซ้ำของผู้ช่วยย่อยด้วย (GitHub) สำหรับคนที่ให้ AI ช่วยแก้โปรแกรม เรื่องนี้เกี่ยวกับเวลาที่ต้องนั่งเฝ้าหน้าจอ และความเข้าใจว่าการกดอนุญาตหนึ่งครั้งครอบคลุมงานแค่ไหนครับ

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

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

บันทึก Copilot CLI 1.0.102 ระบุว่า subagent หรือผู้ช่วยย่อยที่ตัวหลักแตกงานไปให้ จะเคารพการอนุมัติเครื่องมือแบบกำหนดเองและเครื่องมือ MCP แล้ว โดย MCP ในบริบทนี้คือช่องทางเชื่อมผู้ช่วยเข้ากับเครื่องมือหรือบริการเพิ่มเติม ผลที่ผู้พัฒนาระบุคือช่วยเลี่ยงคำถามอนุญาตซ้ำ และให้ขั้นตอนงานที่รับการอนุมัติมาทำต่อได้ (GitHub, GitHub Docs)

รุ่นนี้ยังแก้โหมดรับคำสั่งเป็นข้อความให้ใช้การเลือกโมเดลแบบ Auto ที่มีการจัดการไว้ ทั้งกรณีส่งข้อความผ่านตัวเลือก -p และรับข้อความที่ส่งต่อมาจากโปรแกรมอื่นทาง stdin รวมถึงแก้การทำงานของคำสั่งใน sandbox หรือพื้นที่จำกัดการเข้าถึง และการรับค่าพร็อกซีจากเครื่องที่ใช้งาน (GitHub) โมเดลหมายถึงระบบ AI ที่รับงานไปประมวลผล ส่วนรายละเอียดว่า Auto เลือกตัวใดในแต่ละงานไม่ได้อยู่ในบันทึกนี้

อีกชุดเป็นการลดจังหวะสะดุดระหว่างทำงาน ได้แก่ ลองรับคำตอบใหม่เมื่อผู้ให้บริการแจ้งภาระงานล้น แสดงข้อความจากผู้ให้บริการพร้อมหมายเลขคำขอ แก้การเติมคำสั่งของ fish และไม่ปล่อยให้การเตรียมปลั๊กอินขององค์กรขวางการส่งข้อความในแชต (GitHub) นี่เป็นอัปเดตที่เน้นพฤติกรรมระหว่างใช้งานมากกว่าประกาศความสามารถเขียนโค้ดใหม่ทั้งชุด

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

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

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

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

ทำงานยังไง

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

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

สิ่งที่บันทึกรุ่นยืนยันจริงคือผู้ช่วยย่อยเคารพการอนุมัติเครื่องมือแบบกำหนดเองและ MCP เพื่อเลี่ยงการถามซ้ำและให้ขั้นตอนงานที่สืบทอดมาทำงานได้ (GitHub) ส่วนข้อคิดที่ตามมาคือควรอ่านการอนุมัติตั้งแต่ต้นให้ดี เพราะความคล่องตัวของงานที่ส่งต่อควรมาคู่กับขอบเขตที่เราตั้งใจให้ใช้

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

ส่วน sandbox เป็นวิธีจำกัดสิ่งที่ Copilot เข้าถึงได้ เอกสารทางการระบุด้วยว่าการจำกัดในเครื่องไม่ได้หมายถึงนำตัว CLI ทั้งตัวเข้าไปอยู่ใน sandbox (GitHub Docs) ข้อความส่วนอธิบายต่อจากนั้นในต้นฉบับที่ได้รับไม่ครบ จึงยังใช้สรุปไม่ได้ว่าป้องกันการเข้าถึงอะไรได้ทั้งหมด การแก้ให้คำสั่งทำงานเกิน 10 วินาทีในรุ่นนี้จึงควรอ่านเป็นเรื่องความต่อเนื่องของคำสั่ง ไม่ใช่หลักฐานว่าการแยกพื้นที่ปลอดภัยสมบูรณ์แล้ว (GitHub)

จุดหักมุม: ถามน้อยลง ทำให้ต้องอ่านตอนอนุมัติให้มากขึ้น

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

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

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

แหล่งข้อมูลชุดนี้ไม่มีราคาไทย ไม่มีอัตราค่าใช้จ่ายใหม่สำหรับรุ่นนี้ และไม่มีผลวัดว่าการอัปเดตช่วยลดต้นทุนได้กี่บาท จึงยังบอกผลต่อบิลไม่ได้ สิ่งที่เอกสารระบุได้คือผู้ใช้ดูสถิติรอบการทำงาน เช่น GitHub AI Credits ที่ใช้ ระยะเวลา จำนวนบรรทัดโค้ดที่แก้ และการใช้โทเคนแยกตามโมเดลได้ โดยโทเคนคือหน่วยข้อความที่ระบบใช้ประมวลผล (GitHub Docs) ผมแนะนำให้ใช้ข้อมูลเหล่านี้เทียบกับงานจริงของทีมก่อนสรุปความคุ้มค่า

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

ด้านงานประจำ ปลั๊กอินหรือส่วนเสริมสามารถมาจากแหล่งแบบ git-subdir ซึ่งหมายถึงแหล่งที่ชี้ไปยังโฟลเดอร์ย่อยในคลัง Git ที่เก็บประวัติการเปลี่ยนแปลงโค้ด และรองรับคำอธิบายปลั๊กอินที่ยาวขึ้นแล้ว รุ่นนี้ยังแก้ไม่ให้การเตรียมปลั๊กอินขององค์กรมาขวางการส่งข้อความ (GitHub) ทีมที่ใช้ส่วนเสริมจึงมีเหตุผลจะทดสอบขั้นตอนเดิมอีกครั้ง แต่ข้อความนี้ไม่ได้ยืนยันคุณภาพหรือความปลอดภัยของส่วนเสริมแต่ละตัว

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

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

แหล่งที่ยืนยันตัวรุ่นได้นอกหน้า GitHub คือ npm registry ซึ่งแสดงว่าแพ็กเกจ @github/copilot รุ่น 1.0.102 ถูกเผยแพร่เมื่อ 21 ตุลาคม 2026 เวลา 18:04 UTC หรือราว 01:04 น. ของวันที่ 22 ตุลาคม ตามเวลาไทย และเป็นรุ่น latest ในวันที่ผมตรวจ (npm) แต่ npm ยืนยันได้แค่ว่ามีรุ่นนี้ออกมาจริง ไม่ได้อธิบายรายการแก้ไข รายละเอียดฟีเจอร์ยังต้องอิงบันทึกรุ่น เอกสารใช้งาน และนโยบายความปลอดภัยของ GitHub เป็นหลัก (GitHub Release, GitHub Docs, GitHub Security)

แหล่งที่ได้รับไม่ได้แสดงข้อขัดแย้งโดยตรงเกี่ยวกับรายการเปลี่ยนแปลง แต่รายละเอียดของ 1.0.102 ยืนยันได้จากบันทึกรุ่นเพียงแหล่งเดียว เอกสารการใช้งานช่วยอธิบายการอนุมัติทั่วไป ไม่ได้เป็นผลทดสอบว่าการแก้ทุกข้อทำงานสำเร็จในทุกเครื่อง (GitHub, GitHub Docs) ควรแยกคำประกาศของผู้พัฒนาออกจากผลที่ทีมทดสอบพบเอง

หน้ารุ่นมีวันที่ 21 ตุลาคม 2026 และข้อความเวลา 18:05 ซึ่งสอดคล้องกับเวลาเผยแพร่บน npm ที่ 18:04 UTC (GitHub) ส่วนวันที่ของเอกสารใช้งานและนโยบายความปลอดภัยไม่ใช่วันเผยแพร่ตัวรุ่น จึงไม่ควรนำมาแทนกัน

รายละเอียดที่ยังไม่ทราบจากแหล่งเหล่านี้ ได้แก่ ผลต่อองค์กรไทย ขอบเขตการครอบคลุมของการแก้ในระบบปฏิบัติการแต่ละแบบ ความหมายเชิงนโยบายที่ละเอียดของ managed Auto และเงื่อนไขพร็อกซีทุกกรณี บันทึกรุ่นระบุเพียงว่ารับค่าพร็อกซีดังกล่าวเมื่อสืบทอดการตั้งค่าจากเครื่องหลัก ไม่ได้บอกว่าเครือข่ายทุกแบบจะใช้งานได้ทันที (GitHub)

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

คนทั่วไป เจ้าของกิจการ และผู้ปกครองที่ดูแลการใช้เครื่องร่วมกัน

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

นักศึกษาและคนเขียนโปรแกรม

1. ทดลองรุ่น 1.0.102 ในสภาพแวดล้อมทดสอบก่อน โดยเลือกงานเดิมที่เคยเจอการถามสิทธิ์ซ้ำหรืองานใน sandbox ที่ใช้เวลานาน บันทึกรุ่นระบุการแก้สองส่วนนี้ แต่ยังต้องตรวจผลกับงานของคุณเอง (GitHub)
2. อ่านว่ากำลังอนุญาตเครื่องมือครั้งเดียวหรือตลอดรอบการทำงาน หากไม่ต้องการให้ทำต่อ เอกสารระบุว่าสามารถปฏิเสธและให้คำอธิบายเพื่อปรับวิธีทำงานได้ (GitHub Docs) ผมแนะนำให้ใช้จังหวะนี้กำหนดผลลัพธ์ที่ต้องการให้ชัด
3. ถ้าใช้คำสั่งข้อความอัตโนมัติ ให้ทดสอบทั้งการส่งผ่าน -p และข้อความจากโปรแกรมอื่น เพราะบันทึกรุ่นระบุว่าทั้งสองกรณีเคารพ managed Auto แล้ว (GitHub) อย่าเติมข้อสรุปเองว่าโมเดลที่ได้หรือค่าใช้จ่ายจะเหมือนกันทุกงาน

ฝ่ายไอทีและผู้ดูแลเครื่องมือองค์กร

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

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ด้านที่มาของซอฟต์แวร์ แหล่งเผยแพร่ที่ใช้คือคลังทางการ github/copilot-cli บน GitHub และหน้ารุ่นติดแท็ก v1.0.102 ระบุวันที่ 21 ตุลาคม 2026 พร้อมรายการเปลี่ยนแปลง (GitHub) สิ่งนี้ช่วยยืนยันที่มาของประกาศ แต่ไม่ได้เป็นผลตรวจความปลอดภัยอิสระหรือหลักประกันว่าไม่มีข้อผิดพลาด

ด้านประกาศช่องโหว่ ข้อความจากหน้าความปลอดภัยที่ได้รับเป็นนโยบายรายงานปัญหา ไม่ได้แสดงคำเตือนช่องโหว่เฉพาะรุ่นหรือหมายเลข CVE ซึ่งเป็นรหัสอ้างอิงช่องโหว่ นโยบายขอให้รายงานแบบประสานงานอย่างไม่เปิดเผยต่อสาธารณะ และไม่รายงานผ่าน issue, discussion หรือ pull request สาธารณะของ GitHub โดยระบุช่องทางอีเมลสำหรับรับรายงาน (GitHub Security) การไม่พบประกาศในข้อความที่ให้มาไม่ได้แปลว่ายืนยันว่าไม่มีช่องโหว่

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

สำหรับพฤติกรรมอนุมัติ เอกสารระบุว่าต้องยืนยันความไว้ใจโฟลเดอร์ และเมื่อ Copilot ต้องการใช้เครื่องมือที่อาจแก้ไขหรือสั่งทำงานไฟล์ จะขออนุมัติ การให้สิทธิ์ตลอดรอบการใช้งานลดการถามซ้ำและครอบคลุมคำขอประเภทเดียวกันที่รอพร้อมกันได้ (GitHub Docs) นี่คือพฤติกรรมที่เอกสารอธิบาย ไม่ควรสรุปต่อว่าสิทธิ์ของทุกการติดตั้งเหมือนกันโดยไม่ดูการตั้งค่าของผู้ใช้

ความเสี่ยงที่ผมเห็นว่ายังต้องจัดการคือการให้สิทธิ์กว้างกว่าที่งานต้องการ และความเข้าใจผิดว่ามี sandbox แล้วจะวางข้อมูลสำคัญไว้ได้อย่างสบายใจ เอกสารส่วนที่ให้มายังอธิบายขอบเขต sandbox ไม่ครบ ขณะที่บันทึกรุ่นยืนยันเพียงการแก้พฤติกรรมบางส่วน (GitHub Docs, GitHub) คำแนะนำของผมจึงชัดเจนว่าให้ลองในโครงการที่ทิ้งได้หรือสภาพแวดล้อมทดสอบก่อน และอย่าใช้ข้อมูลรับรองของระบบจริงในการทดลองนี้ ไม่มีหลักฐานจากชุดข้อมูลนี้ให้เรียกเครื่องมือว่าปลอดภัย 100%

ผมมองว่า…

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

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

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

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

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

Recap

• รู้ว่า Copilot CLI อาจอ่าน แก้ไข และสั่งทำงานไฟล์ในพื้นที่ที่ยืนยันว่าไว้ใจ
• ตรวจว่าการอนุมัติเป็นครั้งเดียวหรือตลอดรอบการใช้งาน
• ทดสอบผู้ช่วยย่อยกับสิทธิ์แบบกำหนดเองและ MCP ที่ทีมใช้อยู่
• ตรวจงานใน sandbox ที่ต้องทำต่อเกิน 10 วินาทีในโครงการทดลอง
• ให้ฝ่ายไอทีทดสอบการรับค่าพร็อกซีจากเครื่องหลัก
• เก็บข้อความข้อผิดพลาดและหมายเลขคำขอโดยไม่แนบข้อมูลลับ
• ทดลองในสภาพแวดล้อมที่ทิ้งได้ และไม่ใช้ข้อมูลรับรองระบบจริง
• แยกนโยบายรายงานช่องโหว่ออกจากหลักฐานยืนยันความปลอดภัย