GitHub ให้องค์กรล็อกรายชื่อ MCP server ที่ Copilot รันได้ — นโยบาย fail closed พร้อม API นับการใช้งาน Claude และ Codex แยกรายตัว

ปีที่ผ่านมาคำถามเรื่อง MCP ในองค์กรเปลี่ยนจาก “จะเขียน server ยังไง” มาเป็น “จะห้ามคนในทีมต่อ server มั่วซั่วยังไง” — เพราะ MCP server ตัวหนึ่งคือช่องทางที่ agent เข้าถึงเครื่องมือและข้อมูลได้จริง และการที่นักพัฒนาแต่ละคนเติมเซิร์ฟเวอร์จากอินเทอร์เน็ตลงไฟล์คอนฟิกของตัวเองได้อย่างอิสระ คือปัญหาความปลอดภัยที่ทีมความมั่นคงมองเห็นมานานแล้วแต่ยังไม่มีเครื่องมือจัดการ

เมื่อ 6 สิงหาคม 2026 GitHub ปิดช่องนั้นด้วย MCP allowlists ใน enterprise managed settings และตามด้วยอีกสองรายการในวันที่ 7 สิงหาคม ที่ประกอบกันเป็นภาพเดียวกัน — GitHub กำลังเปลี่ยน Copilot จาก “ผู้ช่วยเขียนโค้ด” ให้กลายเป็น ชั้นควบคุม agent ขององค์กร

allowlist ที่ทำงานแบบ fail closed

เจ้าของ enterprise ได้คีย์คอนฟิกใหม่สองตัวใน copilot/managed-settings.json คือ allowedMcpServers และ deniedMcpServers ซึ่งบังคับใช้กับไคลเอนต์สามตัว: GitHub Copilot app, Copilot CLI และ VS Code

การระบุตัวเซิร์ฟเวอร์ทำได้สามแบบ และความต่างระหว่างสามแบบนี้สำคัญกว่าที่เห็น:

• serverUrl — สำหรับ remote server แบบ HTTP/SSE รองรับ wildcard
• serverCommand — สำหรับ local stdio server จับคู่แบบตรงตัวเป๊ะ ๆ ไม่มี wildcard
• serverName — ชื่อที่ผู้ใช้ตั้งเอง ซึ่ง GitHub ระบุชัดว่า มีไว้เพื่อความสะดวกเท่านั้น

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

จุดออกแบบที่ผมชอบที่สุดคือประโยคนี้ในประกาศ: “Policies fail closed, meaning a malformed or unverifiable configuration is blocked rather than allowed.” — คอนฟิกที่เขียนผิดหรือตรวจสอบไม่ได้จะถูก บล็อก ไม่ใช่ปล่อยผ่าน ซึ่งเป็นค่าเริ่มต้นที่ถูกต้องสำหรับฟีเจอร์ความปลอดภัย และตรงข้ามกับพฤติกรรมของเครื่องมือ dev จำนวนมากที่เลือก “ปล่อยผ่านไว้ก่อนเพื่อไม่ให้ใครทำงานสะดุด”

ตัวไฟล์นโยบายวางไว้ในรีโป .github-private ขององค์กรต้นทาง ที่พาธ copilot/managed-settings.json บนแบรนช์เริ่มต้น — แปลว่านโยบายเป็นโค้ดที่รีวิวผ่าน pull request และมีประวัติย้อนหลังได้ ไม่ใช่สวิตช์ในหน้าตั้งค่าที่ไม่มีใครรู้ว่าใครกด

เมตริกที่เริ่มนับ agent ของคนอื่นด้วย

วันถัดมา (7 ส.ค.) GitHub เพิ่มฟิลด์ totals_by_3rd_party_agent เข้าไปใน Copilot usage metrics API ซึ่งเป็นอาร์เรย์ที่แยกกิจกรรมออกเป็นราย agent app โดยเอกสารยก Claude และ Codex เป็นตัวอย่าง แต่ละรายการมี:

• agent_name — ชื่อที่แสดง ซึ่ง GitHub เตือนว่า เปลี่ยนได้ตามเวลา
• agent_id — ตัวระบุที่เสถียร ใช้ไล่ข้ามช่วงเวลาได้
• user_initiated_interaction_count — จำนวนงานที่ผู้ใช้เป็นคนสั่งเริ่ม
• session_count — จำนวน session (มีเฉพาะในรายงานระดับรวม ไม่มีในรายงานรายบุคคล)

ข้อมูลนี้มีทั้งระดับ enterprise, organization และรายผู้ใช้ ทั้งช่วง 1 วันและ 28 วัน โดยต้องเป็นเจ้าของ enterprise, billing manager, เจ้าขององค์กร หรือมี custom role ที่ให้สิทธิ์ “View Copilot Metrics”

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

รายการที่สามในวันเดียวกันคือ Copilot code review effort levels ขึ้นสถานะ GA เหลือสองระดับคือ Lite สำหรับการเปลี่ยนแปลงตรงไปตรงมา และ Balanced สำหรับ PR ที่ใหญ่ ซับซ้อน หรืออ่อนไหว โดยแอดมินองค์กรตั้งค่าเริ่มต้นได้ที่ organization settings → Copilot → Copilot code review และรีโปที่ไม่ได้ตั้งค่าเองจะรับค่าจากองค์กร ส่วนนักพัฒนาเลือกระดับเฉพาะครั้งได้โดยไม่ทับค่าที่ตั้งไว้ ชื่อเดิม “Low” กับ “Medium” ถูกย้ายมาชื่อใหม่โดยอัตโนมัติ ฟีเจอร์นี้ใช้ได้กับแพ็กเกจ Pro, Pro+, Max, Business และ Enterprise

มุมมอง AI Curator

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

ประเด็นที่ผมคิดว่าถูกมองข้ามคือ การจับคู่ serverCommand แบบตรงตัวเป๊ะ ๆ ฟังดูเข้มงวดดี แต่ในทางปฏิบัติมันเปราะ — คำสั่งอย่าง npx -y some-mcp-server@latest เปลี่ยนรูปได้ง่ายมากจากการเติมแฟล็ก เปลี่ยนเวอร์ชัน หรือเรียกผ่าน wrapper คนละตัว การเขียน allowlist ที่ครอบคลุมจริงจึงต้องอาศัยการรู้ล่วงหน้าว่าทีมใช้อะไรอยู่ ซึ่งองค์กรส่วนใหญ่ไม่รู้ ทางที่ควรทำก่อนคือ เปิดโหมดเก็บข้อมูลด้วย API เมตริกสักรอบเพื่อดูของจริง ก่อนจะเขียนนโยบายบล็อก ไม่ใช่เขียน denylist จากจินตนาการแล้วมาแก้ทีหลังตอนทีมทำงานไม่ได้

สำหรับองค์กรไทยและอาเซียน ผมคิดว่านี่คือชิ้นส่วนที่หลายที่รอมานาน โดยเฉพาะธนาคาร ประกัน และหน่วยงานรัฐที่อยากให้ทีมใช้ AI ช่วยเขียนโค้ดแต่ติดตรงที่ตอบผู้ตรวจสอบไม่ได้ว่า “เครื่องมือนี้ต่อออกไปข้างนอกที่ไหนบ้าง” การมีนโยบายเป็นไฟล์ในรีโปที่รีวิวผ่าน PR ได้ และการที่มันทำงานแบบ fail closed คือคำตอบที่เอาไปวางบนโต๊ะ audit ได้จริง — และเป็นสิ่งที่ควรเขียนลงในเอกสารประกอบ PDPA ตั้งแต่ก่อนเริ่มใช้งาน ไม่ใช่ตามไปเขียนทีหลัง

ข้อควรระวังสุดท้าย: allowlist นี้บังคับใช้กับไคลเอนต์ของ GitHub เท่านั้น ถ้านักพัฒนาในทีมเปิด Claude Code, Cursor หรือ agent อื่นข้าง ๆ กันบนเครื่องเดียวกัน นโยบายนี้ไม่ได้แตะเลย นี่คือการควบคุมระดับผลิตภัณฑ์ ไม่ใช่ระดับเครื่อง ใครที่คิดว่าตั้งค่าตรงนี้เสร็จแล้วจบ กำลังเข้าใจขอบเขตผิด — ชั้นที่ยังขาดคือการควบคุมที่ระดับ endpoint หรือ network ซึ่งยังไม่มีใครทำให้ครบ

แหล่งข่าว

• MCP allowlists in enterprise managed settings — GitHub Changelog (6 ส.ค. 2026)
• Copilot usage metrics API adds agent app activity — GitHub Changelog (7 ส.ค. 2026)
• Copilot code review effort levels are generally available — GitHub Changelog (7 ส.ค. 2026)
• โพสต์ก่อนหน้า: Google เปิดคู่มือรัน MCP stateless บนโปรดักชัน