GitHub Copilot CLI 1.0.94 ให้ policy ปิด Assisted Permissions และคง Manual Approval

GitHub ออก Copilot CLI 1.0.94 วันที่ 8 ตุลาคม 2026 โดยเปลี่ยน permission flow หลายจุด: Assisted Permissions ส่ง shell code ที่มองเห็นได้ไปยัง permission judge, managed policy สามารถปิด Assisted Permissions และคง session ไว้ใน Manual Approval mode, และ CLI แสดง warning เมื่อ startup flag ที่พยายาม bypass permission ถูก managed settings กดไว้ครับ

รุ่นนี้ยังทำให้เปิด/ปิด MCP server ได้ก่อน discovery โดยไม่ต้อง start server, แก้ copilot mcp add ให้กู้จาก config initialization ที่ถูกขัดจังหวะ และแสดงคำแนะนำเมื่อ managed settings ต้องการ CLI รุ่นใหม่ การเปลี่ยนเหล่านี้ช่วยให้องค์กรมีจุดคุมชัดขึ้น แต่ permission judge ไม่ควรถูกมองเป็น security oracle: model decision เป็นเพียง control ชั้นหนึ่ง และ human/manual policy ยังต้องครอบ action ที่ย้อนกลับยาก

ผมตรวจ publisher, repository/tag/changelog, metadata ของ npm 1.0.94, SHA-256 digest ของ release assets, เอกสาร Copilot CLI และ public advisories แบบอ่านอย่างเดียว ไม่ได้ติดตั้ง package, รัน binary, เปิด MCP หรือให้ tool เข้าถึง credential รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-09 เมื่อ managed policy บังคับ least privilege และ action สำคัญยังใช้ Manual Approval

สรุป 30 วินาที

• Assisted Permissions ตอนนี้ส่ง visible shell code ให้ judge แทน context ที่ไม่จำเป็นบางส่วน ทำให้สิ่งที่ตัดสินสอดคล้องกับคำสั่งที่ผู้ใช้เห็นมากขึ้น
• ผู้ดูแลองค์กรปิด Assisted Permissions ได้ผ่าน managed policy และบังคับ Manual Approval ต่อ session
• เมื่อผู้ใช้ส่ง bypass-permission flag แต่ policy ไม่ยอม CLI จะแจ้ง warning แทนการเงียบ ทำให้ตรวจ configuration mismatch ได้
• MCP enable/disable ก่อน discovery ไม่ต้อง start server จึงลด side effect ตอนจัด config แต่การ enable จริงยังต้องตรวจ publisher/version/tools/permissions
• npm integrity ที่ตรวจคือ sha512-YACBu7SSUPO5qPxezq4IMmXbNLC5Tg6dwUyGmq3pJdQXFKwZ6X7AeTHVOsrWQJTvMLOgsqfo7BIPW/Vwq4SmAQ==; GitHub assets มี digest แยกตามไฟล์
• advisories สาธารณะที่ตรวจมี high รุ่นเก่าถึง 0.0.422 และ medium ถึง 1.0.42 ซึ่งแก้แล้วก่อน 1.0.94; ยังต้อง monitor zero-day/dependency/MCP แยก

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

AI agent มักเสนอ shell command ที่ดูสมเหตุผล เช่นติดตั้ง dependency, แก้ permission หรือ push branch แต่ผลจริงขึ้นกับ cwd, expansion, environment และ credential ผู้ใช้ การอนุมัติทุกครั้งด้วยคนสร้าง fatigue; การให้ judge ช่วยลด prompt ก็สร้าง false confidence ถ้าคิดว่าระบบเข้าใจผลข้างเคียงครบ

ให้นึกถึงด่านหมู่บ้านที่มี รปภ. ช่วยดูรถทั่วไป แต่รถบรรทุกสารเคมีต้องให้ผู้ควบคุมเปิดประตูเอง Permission judge เหมาะกับการจัดกลุ่ม action ความเสี่ยงต่ำตาม policy ที่ตรวจสอบได้ ส่วน publish package, deploy, delete, credential access และ remote mutation ควรคง Manual Approval แม้ judge จะมองว่า command ธรรมดา

Managed policy สำคัญเพราะผู้ใช้แต่ละคนอาจเปิด flag เพื่อทำงานเร็ว หาก policy กด flag ไว้แต่ CLI ไม่บอก ผู้ใช้จะเข้าใจผิดว่ากำลังอยู่ในโหมดหนึ่งและหา root cause ยาก Warning ทำให้ effective policy มองเห็น แต่ต้องส่ง telemetry ไปยังทีมดูแลเมื่อมี bypass attempt ซ้ำ ไม่ใช่แค่พิมพ์ข้อความแล้วหาย

ทำงานยังไง: judge ช่วยคัดคิว แต่ policy ถือกุญแจ

Assisted Permissions นำรายละเอียด action ไปให้ permission judge ประเมินตาม context รุ่นนี้เน้นส่ง shell code ที่ผู้ใช้มองเห็น ลดกรณี judge ข้อมูลไม่ตรง command ที่แสดง อย่างไรก็ตาม shell code อย่างเดียวอาจไม่บอก symlink target, alias/function, environment expansion, current branch, mounted credential หรือว่า executable ใน PATH ถูกแทนที่หรือไม่

Managed settings อยู่ชั้นองค์กร ใช้กำหนดว่า feature นี้เปิดได้หรือไม่ หากปิด session อยู่ Manual Approval ผู้ใช้ไม่ควร bypass ด้วย startup flag และ 1.0.94 แจ้งเมื่อ flag ถูก suppress การแยกนี้ดีเพราะ permission convenience ไม่สามารถลบ baseline policy ขององค์กรได้ตามใจ session

MCP discovery ปกติอาจ start server เพื่ออ่าน tool catalog แต่ start process เองคือ side effect: binary อาจอ่าน env, เขียน cache, เรียก network หรือรัน post-start logic ความสามารถ enable/disable ก่อน discovery โดยไม่ start จึงให้ผู้ดูแลปิดของที่ไม่ต้องการก่อน execute แต่ไม่ยืนยันว่า config ถูกต้องหรือ server ปลอดภัย ต้อง inspect command/path/package/digest/permissions แยก

การกู้ config initialization ที่ถูกขัดจังหวะลดโอกาสไฟล์ค้างครึ่งหนึ่ง แต่ทีมต้อง test atomic write, backup และ permission ของ config เอง โดยเฉพาะเครื่องแชร์ ห้ามเก็บ token ใน config ที่ repository sync หรือ log อ่านได้

หลักฐานที่ตรวจ

Release tag v1.0.94 อยู่ใน repository ทางการ github/copilot-cli พร้อมวันที่และรายการเปลี่ยน Publisher npm ทางการมี dist integrity ข้างต้น Release แสดง assets หลาย platform พร้อม SHA-256 ใน metadata ผู้ใช้ต้องตรวจไฟล์ที่ติดตั้งจริงและช่องทาง update ของตน ไม่ใช้ hash ของ archive อื่นแทน

Public advisory list ที่ตรวจมี CVE ระดับสูงซึ่ง affected version จบที่ 0.0.422 และ fixed 0.0.423 กับรายการ medium ที่ fixed 1.0.43 ดังนั้น 1.0.94 อยู่นอกช่วงที่ประกาศ ณ วันตรวจ ไม่มี known high/critical unmitigated จากรายการนั้น แต่ dependency, extension, MCP server และ GitHub-side service มีวงจร advisory แยก

เอกสาร GitHub ใช้ตรวจภาพรวม CLI/permission/config โดยไม่อ้างว่า release note เท่ากับ security certification Install/update path ถูกอ่านจาก npm/release metadata ไม่ได้รัน installer/package/binary และไม่ได้ทดลอง untrusted MCP บน repo, private network หรือ credentials จริง

Default permissions ต้องประเมินที่ effective configuration ขององค์กร ไม่ใช่จาก feature list รุ่นเดียว Shell/filesystem/network ที่ session เข้าถึงขึ้นกับ environment, managed settings และการอนุมัติ MCP tools อาจมี permission ของ process server เพิ่มเติม จึงต้อง inventory ทั้ง chain

เงินและผลกระทบ

Manual Approval ทุก action มีต้นทุนเวลาและ attention Assisted mode อาจลด queue แต่ approval ผิดหนึ่งครั้งอาจสร้างค่า incident, rollback และ credential rotation มากกว่าเวลาที่ประหยัด Policy ควรแบ่ง tier ตาม consequence และใช้ allowlist command ที่ argument/cwd/network ชัด มากกว่ากดอนุมัติทุกคำสั่งชื่อเดียวกัน

การปิด MCP ก่อน discovery ลด startup และ network ที่ไม่จำเป็น แต่ catalog ที่ใหญ่/เปลี่ยนบ่อยยังเพิ่ม context/cost และ attack surface องค์กรควรอนุมัติ server/version/tool subset ไม่ติดทุก MCP “เผื่อใช้” และตั้ง owner/expiry สำหรับ exception

Managed update guidance ช่วยลด drift ของ client fleet แต่ห้าม auto-update จาก unverified channel บน production workstation ควร stage package, verify integrity/signature, canary และมี rollback โดยเก็บ policy compatibility ระหว่างรุ่น

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

Release note บอกว่า visible shell code ถูกส่งให้ judge แต่ไม่ได้แจกแจงข้อมูลอื่นที่ judge เห็น, model/version, retention หรือ decision guarantees ในหน้าสรุป องค์กรที่มี data classification ต้องอ่าน privacy/enterprise docs และทดสอบ telemetry ไม่สรุปเองว่า code ไม่ออกนอกเครื่อง

คำว่า Manual Approval mode อาจทำให้เข้าใจว่าทุก side effect ต้องผ่าน prompt แต่ MCP server ที่ start, extension initialization หรือ background network บางอย่างอาจเกิดนอก shell approval flow ต้องตรวจ startup behavior และ egress แยก Release note ของ MCP enable/disable ช่วยก่อน discovery แต่ไม่ได้ประกาศว่า server ทุกตัวปิดเป็น default

Advisory page ไม่มีรายการที่กระทบ 1.0.94 ตามข้อมูลที่ตรวจ แต่ absence ไม่ใช่ evidence of no vulnerability และ GitHub service-side behavior อาจเปลี่ยนโดยไม่เปลี่ยน CLI version ทีมต้อง monitor both client release กับ managed policy/changelog

วิธีใช้ให้ปลอดภัยขึ้น

1. pin 1.0.94 และตรวจ npm integrityหรือ asset digest ของไฟล์จริง
2. ใช้ managed policy ปิด Assisted Permissions สำหรับ repository/ทีมความเสี่ยงสูง และคง Manual Approval กับ remote/destructive action
3. สร้าง command allowlist ที่ผูก executable absolute path, cwd, argument pattern และ network expectation ไม่ allow จากชื่อ command อย่างเดียว
4. แสดง expanded command/target ก่อน approve และห้าม secret ปรากฏใน prompt/log
5. ปิด MCP ทั้งหมดก่อน inventory จากนั้น enable ทีละ server หลังตรวจ publisher, tag, digest, advisory, tools, env, filesystem และ egress
6. ใช้ token อายุสั้น scope ต่อ repo/operation ไม่ให้ ambient cloud/admin credential แก่ agent
7. alert เมื่อ bypass flag ถูก suppressed, policy โหลดไม่ได้, tool catalog เปลี่ยน หรือ approval rate ผิดปกติ
8. ทดสอบ prompt injection, symlink, PATH replacement, shell expansion และ interrupted config ด้วย fixture แยก

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

ผู้ใช้เดี่ยวควรเริ่ม Manual Approval แล้วเก็บรายการคำสั่งซ้ำที่ความเสี่ยงต่ำจริง ค่อยสร้าง rule แคบหลังเข้าใจ cwd/argument ทีมองค์กรควร rollout 1.0.94 แบบ canary ตรวจ warning/approval telemetry และเทียบ effective managed settings ก่อนบังคับ fleet

ถ้าต้องใช้ Assisted Permissions ให้กำหนดขอบว่า judge อนุมัติได้แค่ read-only/local build ที่ไม่มี credential ส่วน push, PR mutation, package publish, deploy, database write, permission change และ delete ต้องกลับมาหาคนเสมอ เมื่อ command ซับซ้อนด้วย pipe/subshell/redirection ให้แยกเป็นขั้นเล็กที่ตรวจได้

ความเสี่ยงคงเหลือ

Permission judge อาจประเมินผิดหรือขาด context ผู้ใช้ยังถูก social-engineer ให้ approve ได้ Managed policy อาจโหลดผิด scope, client เก่าไม่รองรับหรือ endpoint ถูกเปลี่ยน MCP server ที่อนุมัติแล้วอาจอัปเดตเป็นอันตรายหรือคืน prompt injection และ token ของ GitHub เองอาจกว้างเกินงาน

การปิด server ก่อน discovery ไม่พิสูจน์ว่าไม่มี startup จากส่วนอื่น และ integrity ยืนยัน byte จาก publisher ไม่รับรองว่า code ไม่มีช่องโหว่ การผ่านเกณฑ์ครั้งนี้ไม่ใช่คำว่า “ปลอดภัยแน่นอน”; เป็นการคัดกรอง provenance/version/advisory พร้อมเงื่อนไข least privilege และ residual risk ณ วันที่ตรวจ

Recap

• pin 1.0.94 และตรวจ artifact ตามช่องทางจริง
• managed policy ถือ baseline; judge เป็นตัวช่วย ไม่ใช่ผู้มีอำนาจสูงสุด
• action ย้อนกลับยากคง Manual Approval
• ปิด MCP ก่อน inventory แล้วเปิดทีละตัวพร้อมจำกัด env/network/filesystem
• alert bypass suppression และ config/policy drift
• ทดสอบ shell context ที่ judge อาจไม่เห็น
• บันทึก residual risk; รุ่นนี้ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ

ประเด็นที่ดีของ 1.0.94 คือทำให้ “ใครถือกุญแจ” ชัดขึ้นครับ Assisted Permissions ช่วยคัดคิวได้ แต่ managed policy ต้องกำหนดเพดาน และคนยังต้องอยู่หน้าประตูเมื่อผลของคำสั่งข้ามจากเครื่องเราไปเปลี่ยนโลกภายนอก