
GitHub Copilot CLI 1.0.95 เพิ่ม injectHosts: จำกัด credential ให้ตรงปลายทาง
GitHub ออก Copilot CLI 1.0.95 วันที่ 9 ตุลาคม 2026 โดยเพิ่ม native Microsoft Entra broker authentication บน macOS และเพิ่มคีย์ injectHosts ใน copilot config สำหรับ sandbox credential ประเด็นสำคัญไม่ใช่แค่ login สะดวกขึ้น แต่คือ credential ควรถูกฉีดให้เฉพาะ host ที่ต้องใช้ ไม่ลอยอยู่กับทุก process หรือทุกปลายทางครับ
ผมตรวจ release tag, metadata npm 1.0.95, เอกสาร Copilot CLI และ public advisory แบบอ่านอย่างเดียว ไม่ติดตั้ง package, ไม่เริ่ม broker login, ไม่รัน agent และไม่ส่ง credential ให้ sandbox รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-11 เมื่อ pin artifact, allowlist host แคบ และทดสอบว่า secret ไม่โผล่ใน environment/log
สรุป 30 วินาที
- 1.0.95 เพิ่ม native Entra broker auth บน macOS พร้อม browser fallback ทำให้เส้นทางยืนยันตัวตนอาจต่างตามเครื่องและนโยบายองค์กร
copilot configรองรับ sandbox credentialinjectHostsและ shell completion ช่วยผูก credential กับรายชื่อปลายทางที่กำหนด--contextถูกนำไปใช้กับ ACP session ทั้งตอนเริ่มใหม่และ resume ลดความต่างของ context behavior- managed plugin setup จะ retry ทุกชั่วโมงหรือหลัง policy เปลี่ยน จึงต้องเฝ้าดูว่า policy ใหม่ไม่เปิด plugin ที่ยังไม่ผ่านการตรวจ
- npm integrity คือ
sha512-TAYlgMwjTnHi04ZGRc6Z+41piGeUC6xuA8z7gWVc5qOTqJLi/B3vCVg9ttkwvxnahbTWjX8x0DORwrJMXOQxGg==; shasum คือ2de10fd6011d47a2ea8ae76946f54765d4947e32 - public advisory ไม่พบ high/critical ที่ประกาศว่ากระทบ 1.0.95 โดยไม่มี mitigation ณ เวลาตรวจ แต่ host allowlist ที่เขียนผิดยังรั่ว credential ได้โดยไม่มี CVE
ทำไมเรื่องนี้เกี่ยวกับคุณ
เครื่องมือ agent ต้องคุยกับ API, Git host, package registry หรือบริการภายใน สิ่งที่อันตรายคือการให้ token เป็น environment กลางแล้วหวังว่าทุก subprocess จะสุภาพ injectHosts สื่อทิศทางที่ดีกว่า: ผูก secret กับ destination ที่จำเป็น เหมือนพนักงานถือคีย์การ์ดที่เปิดได้เฉพาะชั้น ไม่ใช่มาสเตอร์คีย์ทั้งตึก
แต่ชื่อ host เป็น policy boundary ที่ละเอียดมาก ถ้าใส่ wildcard กว้าง, โดเมนคล้ายกัน หรือปลายทาง redirect ไปอีก origin Credential broker และ sandbox อาจตีความไม่เหมือนที่ผู้ดูแลคิด ความสะดวกของ shell completion ช่วยลด typo แต่ไม่ตรวจว่า host นั้นควรได้รับ secret จริง
สำหรับทีมไทยที่ใช้ Entra และ GitHub Enterprise เส้นทาง login อาจผ่าน broker native หรือ browser fallback การ audit ต้องบันทึกว่าใช้ flow ใด, token audience/scope/อายุเท่าไร และ session ถูก revoke อย่างไร ไม่ใช่บอกเพียงว่า “SSO ผ่านแล้ว”
ทำงานยังไง: broker, host binding และ session context
Credential broker ช่วยให้แอปขอ token ผ่านตัวกลางของระบบปฏิบัติการหรือองค์กร แทนการเก็บรหัสผ่านเอง บน macOS รุ่นนี้พยายามใช้ native Microsoft Entra broker ก่อนและ fallback ไป browser เมื่อจำเป็น Broker ลดการกระจาย credential แต่ยังต้องอาศัย device trust, account policy และ consent ที่ถูกต้อง
injectHosts เป็น configuration สำหรับ credential ใน sandbox โดยแนวคิดคือฉีด credential เมื่อ request มุ่งไป host ที่ระบุ แทนการวาง token เป็น ambient secret ให้ทุก command เห็น การควบคุมนี้ต้อง match hostname หลัง normalization อย่างระมัดระวัง รวมถึง port, subdomain, proxy และ redirect ตาม implementation จริง
ให้นึกถึงคูปองส่งอาหารที่ใช้ได้เฉพาะร้านในใบสั่ง ถ้าคนส่งเปลี่ยนร้านระหว่างทาง ระบบต้องถามใหม่ ไม่ควรส่งคูปองเดิมต่อทันที ดังนั้นทีมควรทดสอบ direct host, subdomain, look-alike domain, redirect และ proxy ด้วย synthetic credential ไม่ใช่ token จริง
การให้ --context ใช้กับ ACP session ตอน resume ช่วยให้ agent ได้ context ที่ผู้ใช้ตั้งใจต่อเนื่อง แต่ context อาจมี source path หรือข้อมูลอ่อนไหว ต้องจำกัดสิ่งที่แนบและไม่ถือว่า resumed session ยังอยู่ใน trust boundary เดิมหาก cwd, repository หรือ account เปลี่ยน
หลักฐานที่ตรวจ
Release 1.0.95 อยู่ใน repository github/copilot-cli และบันทึกฟีเจอร์ broker auth, injectHosts, ACP context และ managed plugin retry Metadata registry ชี้ repository เดียวกันและให้ integrity/shasum ที่ระบุ การตรวจนี้ยืนยันข้อมูล publisher/distribution ณ เวลาตรวจ แต่ไม่ได้ติดตั้ง tarballหรือทำ reproducible build
เอกสาร GitHub อธิบายวิธีใช้ Copilot CLI และ permission flow ระดับผลิตภัณฑ์ ส่วน public security advisories ไม่แสดง known high/critical ที่ระบุ affected range ครอบคลุม 1.0.95 แบบไม่มี mitigation ณ วันตรวจ การไม่มีรายการไม่ได้ยืนยันว่า plugin, MCP, dependency หรือ enterprise proxy ปลอดภัย
Default permission ของ agent ยังครอบคลุม filesystem/shell/network ตาม configuration และ approval ที่ผู้ใช้เลือก injectHosts จำกัดด้าน credential destination ไม่ได้ทำให้ filesystem read แคบลงหรือปิด command execution ต้องวาง sandbox และ approval policyอีกชั้น
Install/update path ถูกอ่านจาก npm/release เท่านั้น ผมไม่ได้รัน npm install -g, login, broker, browser auth, managed plugin setup หรือ CLI binary ไม่ได้ส่ง synthetic หรือ credential จริงเข้า process และไม่แตะ private network
เงินและผลกระทบ
Native broker อาจลด support ticket เรื่อง login และช่วย reuse policy ขององค์กร แต่ถ้า browser fallback ถูก proxy/conditional access ปฏิเสธ ผู้ใช้ยังหยุดงาน ทีมต้องมี runbook แยก flow และ telemetry ที่ไม่บันทึก token
การผูก credential กับ host ลด blast radius เมื่อ command หรือ plugin แปลกพยายามออก network แต่มีต้นทุนดูแล allowlist, rotation และ test หากตั้งแคบเกินไปงานล้ม หากตั้งกว้างเกินไป control กลายเป็นป้ายสวย ๆ ที่ไม่ลดสิทธิ์
Managed plugin retry ทุกชั่วโมงช่วยให้ policy ที่แก้กลับมามีผลโดยไม่รอ restart แต่ทำให้ external state เปลี่ยนระหว่าง session ต้อง log policy revision และ plugin digest เพื่ออธิบายได้ว่าตอนไหน capability เพิ่มขึ้น
สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน
Release note ระบุชื่อคีย์ injectHosts แต่ไม่ได้อธิบาย normalization, redirect, proxy และ wildcard semantics ครบในบรรทัดสรุป เอกสารผลิตภัณฑ์ให้ภาพ workflow กว้างกว่าแต่ไม่ใช่หลักฐานว่าคอนฟิกองค์กรทุกแบบตีความเหมือนกัน ต้องทดสอบ version นี้ใน environment ของตน
Native broker กับ browser fallback อาจออก token ที่มีประสบการณ์ login ต่างกัน ขอบเขตสิทธิ์ควรเหมือน policy ที่องค์กรอนุมัติ แต่ยังไม่มีข้อมูลใน release summary ให้เปรียบเทียบ token claim ทุกกรณี ทีม identity ต้องตรวจ audience/scope จากเครื่องมือของตนโดยไม่ log raw token
ยังไม่ชัดว่า managed plugin ที่ retry หลัง policy change จะจัดการ session ที่มี tool catalog เก่าอย่างไรในทุกโหมด และไม่มีหลักฐานว่าการ resume ACP context จะล้างข้อมูลของ project เดิมหากผู้ใช้ย้าย cwd
วิธีใช้ให้ปลอดภัยขึ้น
- pin 1.0.95 และตรวจ npm integrity ของ tarball ที่ mirror/ติดตั้งจริง
- เริ่มด้วย
injectHostsแบบ exact host ไม่มี wildcard และทดสอบ redirect/subdomain/proxy ด้วย synthetic credential - ใช้ token อายุสั้น audience แคบ แยก read/write และไม่ forward environment ทั้งก้อนเข้า sandbox
- บังคับ sandbox filesystem แบบ workspace-write, network deny-by-default และ approval ก่อน remote/destructive action
- ตรวจ broker กับ browser fallback แยกกัน บันทึก flow, policy revision และผลโดยไม่บันทึก raw token
- pin managed plugin/MCP ด้วย publisher, tag, checksum และ advisory แยก พร้อม review ก่อน policy เปิดให้ retry
- จำกัด
--contextให้เฉพาะไฟล์ที่จำเป็น และทบทวนใหม่เมื่อ resume ใน repository/account อื่น - เก็บ audit log ของ destination, tool call, approval และ plugin digest พร้อม revoke/rollback plan
แล้วเราควรทำอะไร
ผู้ใช้เดี่ยวควรเริ่มจาก host เดียวและ repository ทดลอง ตรวจว่า token ไม่ปรากฏใน env, child process หรือ debug log แล้วค่อยเพิ่มปลายทาง ทีมองค์กรควรให้ identity/security owner review host map และ broker flow ก่อน rollout ไม่ปล่อยให้นักพัฒนาแต่ละคนใส่ wildcardเอง
ถ้าระบบต้องคุยหลาย API ให้สร้าง credential แยกต่อบริการ ไม่ใช้ token เดียวครอบคลุมทั้งหมด injectHosts เป็นกลไกส่งมอบ secret ไม่ใช่เหตุให้ขยาย scope ของ secret
ความเสี่ยงคงเหลือ
DNS, proxy, redirect และโดเมนหน้าตาคล้ายอาจทำให้ host policy ไม่ตรงความคาดหวัง Plugin/MCP ที่ได้รับ credential ถูกต้องยังอาจนำไปใช้เกินเจตนา ผู้ใช้สามารถ approve network action โดยไม่อ่านปลายทาง และ browser session อาจมี account สิทธิ์สูง
Broker compromise, device theft, stale refresh token, misconfigured conditional access และ log leakage ยังอยู่นอกสิ่งที่ release นี้แก้ Public advisory อาจเปลี่ยนหลังวันตรวจ รุ่นนี้จึงผ่านเกณฑ์คัดกรองแบบมี control ประกอบ ไม่ใช่การรับรองว่าไร้ช่องโหว่
Recap
- 1.0.95 เพิ่ม Entra broker บน macOS และ
injectHosts - exact-host allowlist ดีกว่า ambient credential แต่ต้องทดสอบ redirect/proxy
- pin registry integrity และตรวจ plugin/MCP แยก
- จำกัด filesystem, network, token scope และ approval คนละชั้น
- resume context ต้องทบทวน trust boundary ใหม่
- สถานะคือผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ พร้อม residual risks