HYBRID MIND / AGENT INFRASTRUCTURE / INTERACTIVE EXPLAINER
MXC 1.0: กั้นสิทธิ์ AI Agent
ไม่ใช่แค่บอกให้ระวัง
คำถามไม่ใช่แค่ว่า Agent ฉลาดแค่ไหน แต่คือเมื่อมันเรียกเครื่องมือ มันได้รับสิทธิ์อะไร — และใครเป็นคนบังคับขอบเขตนั้น
QUICK ANSWER
โมเดลเลือกการกระทำ
ระบบต้องกำหนดสิทธิ์
เกิดอะไรขึ้น: Microsoft ประกาศ Microsoft Execution Containers หรือ MXC เป็น GA และ repository ปล่อย SDK v1.0.0 วันที่ 7 ตุลาคม 2026 เป็นชั้น containment สำหรับการรันโค้ดและเครื่องมือ ไม่ใช่โมเดลภาษาใหม่ ประกาศ Microsoft / Release v1.0.0
สำคัญอย่างไร: การกำหนดขอบเขตจากภายนอกการตัดสินใจของ Agent ทำให้คำขอใช้ทรัพยากรต้องผ่านนโยบาย ไม่ใช่อาศัยเพียงข้อความว่า “อย่าแตะไฟล์ที่ไม่เกี่ยวข้อง”
ยังยืนยันอะไรไม่ได้: GA และ API stable ไม่ใช่หลักฐานว่า Agent ไม่ผิดพลาด หรือ Sandbox ไม่มีทางหลุดในทุก OS และทุก Backend บทความนี้ตรวจเอกสารและรายงานต้นฉบับ แต่ไม่ได้รัน MXC หรือทดสอบการหลุดจาก Sandbox เอง
WHAT CHANGED
รุ่น 1.0 ทำให้สัญญา SDK ชัดขึ้น
ไม่ใช่ใบรับรองความปลอดภัย
Release notes ระบุว่านี่เป็น stable SDK surface ครั้งแรก โดยมีจุดเข้า API แบบ V1 ใน Rust, .NET และ Node พร้อมสัญญาความเข้ากันได้ตาม SemVer ของสาย SDK นั้น การเรียกงาน การค้นหา Backend และ Lifecycle ที่รองรับจึงมีขอบเขต API ที่ระบุชัดกว่าเดิม รายละเอียดการเปลี่ยนแปลงจากผู้พัฒนา
บทความนี้ยึด tag v1.0.0 ที่ commit 7bf2102 ไม่ปะปนเอกสารของ main ที่อาจเดินหน้าต่อแล้ว Config stable ใช้สัญญา 1.0.0 ส่วน development contract 1.1.0-alpha เป็นอีกพื้นผิวหนึ่ง Node SDK ที่ pin commit
API stable ช่วยเรื่องการเชื่อมต่อซอฟต์แวร์ ส่วนความปลอดภัยจริงต้องพิจารณา Backend, นโยบาย, Host และเครื่องมือที่เรียก การอนุมานของ Hybrid Mind คือไม่ควรนำสถานะรุ่นไปแทนผลทดสอบขอบเขตการทำงาน
Microsoft ยังระบุการจัดการผ่าน Intune และการแยก Agent identity ด้วย Entra/Agent 365 ว่าเป็นสิ่งที่จะตามมา จึงไม่สรุปว่าความสามารถเหล่านี้พร้อมทั้งหมดแล้ว ขอบเขตในประกาศ
FOLLOW THE TOOL CALL
เครื่องมือสามประเภท
ไม่ได้อยู่ในกล่องเดียวกัน
ให้คิดถึง Agent harness ว่าเป็นโปรแกรมที่รับคำตอบโมเดล แล้วนำคำขอไปเรียกเครื่องมือจริง การวางนโยบายต้องเริ่มจากตามให้พบว่า “โค้ดส่วนไหนกำลังทำงานอยู่ที่ไหน” ไม่ใช่เริ่มจากชื่อโมเดลหรือคำว่า MCP อย่างเดียว
บทความต้นฉบับ Microsoft/GitHub อธิบาย integration ของ Copilot เมื่อเปิด sandbox ไว้ดังนี้: shell และ local MCP โดยปริยายอยู่ในขอบเขต child process; built-in file tools อยู่ใน harness และตรวจคำขอตาม effective policy; remote MCP อยู่นอก local process sandbox โดยตรวจ connection policy ใน harness ตาม controls ที่ใช้ ต้นฉบับส่วน How sandboxes help secure tool execution
Local process
ใช้ Backend ของ OS สำหรับกระบวนการที่ถูกสร้างบนเครื่อง ไม่ได้แปลว่าเครื่องมือทุกชิ้นใน Agent เป็น child process
Built-in file tool
ตรวจในโปรแกรมห่อ Agent เป็นคนละกลไกกับการแยก child process ด้วย OS
Remote MCP
ข้ามไปยังเซิร์ฟเวอร์อื่น ขอบเขตการเชื่อมต่อฝั่ง local ไม่ได้กลายเป็น Sandbox ของเซิร์ฟเวอร์นั้น
ความต่างนี้นำไปสู่บทเรียนเชิงออกแบบ: ต้องตรวจเส้นทางที่ออกจาก Boundary ด้วย ไม่ใช่เห็นว่าคำสั่งหนึ่งถูกกั้นแล้วสรุปว่าไฟล์ การเชื่อมต่อ และสิทธิ์เซิร์ฟเวอร์ทั้งหมดถูกกั้นแบบเดียวกัน ลองสลับเส้นทางใน Lab ถัดไป แล้วสังเกตว่าจุดตรวจย้ายไปอยู่ที่ใด
คำสั่งเดินทางผ่านขอบเขตไหน?
เลือกชนิดการเรียก แล้วเลือกโหนดในฉากเพื่อดูหน้าที่และเส้นทางที่เปลี่ยนตาม integration นี้ แผนภาพไม่ใช่ Runtime ของ MXC และไม่ได้ทดสอบการแยกขอบเขตจริง
โหนดที่ไม่อยู่ในเส้นทางนี้ — เลือกอ่านคำอธิบายได้
เส้นทางที่เลือก
Agent → harness → local shell / local MCP ใน OS child-process boundary → local resource
โหนดที่เลือก
Agent
Agent ขอใช้ tool; policy เป็นตัวกำหนดขอบเขต ไม่ใช่คำสั่งใน prompt
แสดงเส้นทาง Local shell / local MCP
สรุปเส้นทาง (อ่านได้แม้ JavaScript ปิด)
- Local shell / local MCP: agent → harness → local child process ภายใน OS process boundary → local resource
- Built-in file tool: agent → harness policy check → built-in file tool/resource; ตรวจใน harness ไม่ใช่ child-process isolation
- Remote MCP: agent → harness/connection policy → remote MCP server → remote resource; อยู่นอก local OS boundary
HYBRID MIND VIDEO LAB / VISUAL STUDIO
สำรวจเส้นทาง Local process
ด้วยระบบ Lab ของ Hybrid Mind
ฉากนี้ใช้ Visual Studio ในปลั๊กอิน Hybrid Mind Video Agent 3D Lab เลือกโหนดเพื่ออ่านหน้าที่และข้อควรตรวจ ใช้ ORBIT, FRONT, TOP, Zoom หรือ FOCUS สำรวจภาพแบบ 2.5D ที่จัดโหนดให้อ่านได้ ส่วนแผนภาพ 3D ด้านบนใช้สลับขอบเขตของทั้งสามเส้นทาง
ฉากนี้อธิบายเฉพาะ Local shell / Local MCP ใน integration ที่เปิด sandbox ไม่ใช่ภาพ Runtime หรือการทดลอง MXC จริง ค่า Zoom เป็นขนาดมุมมอง ไม่ใช่คะแนนความปลอดภัยหรือประสิทธิภาพ
MXC: เส้นทาง Local process
เลือกขั้นตอนแล้วอ่านว่าใครกำหนดสิทธิ์ ใช้ ORBIT / FRONT / TOP หรือหมุนมุมมองเพื่อสำรวจ เป็นแบบจำลองของ integration เมื่อเปิด sandbox ไม่ใช่ Runtime หรือผลทดสอบ MXC
Agent
โมเดลเสนอคำขอใช้ shell หรือ Local MCP แต่ไม่ได้เป็นผู้อนุมัติสิทธิ์ของตนเอง
แยกการเลือกการกระทำออกจากอำนาจกำหนดนโยบาย
อ่านข้อมูลทั้งหมดแบบข้อความ
- Agent — โมเดลเสนอคำขอใช้ shell หรือ Local MCP แต่ไม่ได้เป็นผู้อนุมัติสิทธิ์ของตนเอง ตรวจรับ: แยกการเลือกการกระทำออกจากอำนาจกำหนดนโยบาย
- Harness — โปรแกรมห่อ Agent ส่งงานเข้าสู่ขอบเขตตาม policy ที่ผู้พัฒนาหรือผู้ดูแลกำหนด ตรวจรับ: ต้องตรวจว่า integration ส่งงานประเภทใดเข้าสู่ sandbox จริง
- OS process — Shell และ Local MCP ที่ integration นี้เริ่มภายใต้ sandbox ทำงานเป็น child process ในขอบเขต OS ที่ Backend รองรับ ตรวจรับ: ไม่ขยายความว่า Built-in tools และ Remote MCP อยู่ในขอบเขตเดียวกัน
- Local resource — ไฟล์หรือทรัพยากรในเครื่องอยู่หลังข้อจำกัดของ Backend, policy และ Host ที่รองรับ ตรวจรับ: API stable ไม่ใช่หลักฐานว่าเข้าถึงหรือกั้นทรัพยากรได้เหมือนกันทุก Host
POLICY AUTHORING
เห็นรายงานการเข้าถึง
ไม่เท่ากับกำลังบังคับสิทธิ์
ตารางของ Microsoft สำหรับ Windows ProcessContainer แยก Enforcement ที่บล็อกสิทธิ์นอกนโยบายแต่ไม่มี Activity Report, Learning ที่บล็อกและบันทึก กับ Permissive ที่ยอมให้สิทธิ์นอกนโยบายของ MXC ผ่านพร้อมบันทึก โหมดสุดท้ายยังไม่ข้ามข้อจำกัด OS หรือองค์กรที่มีอยู่ ตาราง operating modes ต้นฉบับ
ข้ออนุมานสำหรับทีมพัฒนาคือ “มี log” กับ “มี enforcement” ต้องเป็นคนละคำถาม กรณี workload ใช้ทรัพยากรไม่ได้ อาจเป็นข้อผิดพลาดของงาน หรืออาจเป็นนโยบายที่ทำงานตามตั้งใจ การเพิ่มสิทธิ์ทุกอย่างเพื่อให้ demo จบไม่ได้พิสูจน์ว่านโยบายเหมาะกับ production
โหมด + grant + ข้อจำกัด OS
ปรับเงื่อนไขเพื่อดูว่า MXC ตัดสินอย่างไร และ OS/องค์กรยังบล็อกผลสุดท้ายได้หรือไม่ ผล “บันทึก” หมายถึงการบันทึก denied attempt โดย MXC ตามโหมด ไม่ใช่บันทึกทุกเหตุการณ์จาก OS
Enforcement บล็อกคำขอที่ไม่มี grant และไม่บันทึก denied attempt ด้วย MXC ในแบบจำลองนี้
ตารางกติกา MXC (อ่านได้แม้ JavaScript ปิด)
| โหมด | ไม่มี grant | มี grant |
|---|---|---|
| Enforcement | MXC บล็อก · ไม่บันทึก denied attempt | MXC อนุญาต · ไม่ใช่ denied attempt |
| Learning | MXC บล็อก · บันทึก denied attempt | MXC อนุญาต · ไม่ใช่ denied attempt |
| Permissive | MXC อนุญาต · บันทึก denied attempt | MXC อนุญาต · ไม่ใช่ denied attempt |
เมื่อ OS/องค์กรมีข้อจำกัดแยกต่างหาก ผลสุดท้ายยังอาจถูกบล็อก แม้ MXC อนุญาต การบันทึกจากข้อจำกัดภายนอกนี้ไม่รับประกันโดย MXC
ขอบเขตแบบจำลอง: ตารางนี้ย่อพฤติกรรม Windows ProcessContainer ตามเงื่อนไข grant ที่ทดลอง ไม่ได้เรียกใช้ MXC หรือรัน Agent จริง ไม่จำลองความสามารถที่ต่างกันของ backend, host, network หรือ policy องค์กรทั้งหมด และ grant ไม่สามารถลบล้างข้อจำกัด OS/องค์กร
EVIDENCE, NOT A SAFETY SCORE
อะไรตรวจจากต้นฉบับได้
อะไรยังเป็นขอบเขตของคำกล่าว
Release / เอกสารผู้พัฒนา
GA วันที่ 7 ต.ค. และ SDK stable v1.0.0 ตรวจได้จากประกาศกับ tag แต่ไม่ได้ให้ผลการทดสอบ sandbox escape แบบครอบคลุม Release
รายงานทดสอบอิสระเฉพาะ Host
Yuval Glasman จาก Platform Monkey รายงานวันที่ 9 ต.ค. ว่า SDK 1.0.0 บน Ubuntu 24.04.5 ตรวจพบ Backend แต่ launch ที่ลองล้มด้วยข้อจำกัด AppArmor ของ Host นั้น เขาระบุว่าไม่ได้ยืนยัน timeout แบบ end-to-end; หน้ารีวิวมี output บางส่วน แต่ไม่พบชุด raw logs และ test harness ครบสำหรับทำซ้ำ รายงานต้นฉบับ
สิ่งที่ยังไม่มีผลตรวจครบในบทความนี้
พฤติกรรมทุก OS/Backend, ความทนต่อการหลุดจาก Sandbox และความพร้อมของทุก integration ไม่ได้ผ่านการทดสอบโดย Hybrid Mind จึงไม่ให้คะแนนความปลอดภัยหรือสรุปว่าระบบทั้งหมดใช้ไม่ได้จาก Host เดียว
Backend และ Host เป็นส่วนหนึ่งของคำตอบ
README รุ่นที่ตรวจแยก Backend stable ออกจาก experimental ส่วนเอกสาร Windows แยกความสามารถตาม OS build และ tier จึงไม่ควรสมมติว่านโยบายเดียวกันมีพื้นผิวการบังคับใช้เหมือนกันทุกเครื่อง Backend table / OS capability matrix
ระหว่างตรวจพบ Search cache ที่ยังแสดงคำเตือน early preview เก่า แต่ README ที่ pin รุ่นไม่มีคำเตือนนั้นแล้ว และ PR #1388 ลบออกก่อน release การเปลี่ยนเอกสารนี้ไม่ใช่หลักฐานผลทดสอบความปลอดภัยใหม่
WHY IT MATTERS
จาก “เชื่อใจ Agent”
สู่ “ตรวจเส้นทางสิทธิ์”
การวิเคราะห์ต่อไปนี้เป็นข้ออนุมานของ Hybrid Mind จากกลไกที่อธิบาย ไม่ใช่ผลวัดผลลัพธ์ทางธุรกิจหรือ benchmark ของ MXC
สำหรับผู้ใช้
ถามให้เจาะจงว่า Agent แตะ repository ใด มีสิทธิ์เขียนอะไร และส่งข้อมูลออกที่ไหนได้ ไม่หยุดที่คำว่า “เปิด sandbox แล้ว” โดยเฉพาะเมื่อใช้เครื่องมือหรือบริการหลายชนิดร่วมกัน
สำหรับผู้พัฒนา
แยก model choice, tool routing และ permission decision เป็นคนละส่วน ทดลองทั้งงานที่ควรผ่านและงานที่ต้องถูกปฏิเสธ รวมถึงทางออกผ่าน built-in tools หรือ remote services
สำหรับองค์กร
ต้องคิดต่อเรื่องสิทธิ์เซิร์ฟเวอร์ การเก็บ log ข้อมูลส่วนบุคคล ความลับ และผู้รับผิดชอบเมื่อมีการยกระดับสิทธิ์ ความพร้อมของชั้น local ไม่แทนนโยบายบริการภายนอกหรือข้อกำหนดการใช้ข้อมูล
ข้อจำกัดที่ไม่ควรถูกกลบด้วยภาพสวย
Containment ไม่ตัดสินว่าเป้าหมายดีหรือไม่ ไม่ทำให้คำตอบถูกต้อง และไม่ยกเลิกความเสี่ยงภายในสิทธิ์ที่อนุญาต หากตั้งขอบเขตกว้างเกินไป การกระทำที่ไม่พึงประสงค์อาจยังอยู่ในสิทธิ์นั้นได้ กราฟิกและการทดลองในบทความจึงแสดงกลไก ไม่แสดงคะแนน “ปลอดภัยกี่เปอร์เซ็นต์”
สิ่งที่ควรจับตา
- หลักฐานการทดสอบที่ pin package/commit และทำซ้ำได้บน Host ต่างชนิด
- การอธิบาย failure ที่แยก policy denial, launch failure และปัญหาของ workload
- การใช้สิทธิ์กับ built-in tools และ remote services ที่ไม่อยู่ใน local child-process boundary
- ความพร้อมจริงของ identity และการจัดการองค์กรที่ประกาศว่าจะตามมา
ข่าวนี้น่าสนใจเพราะการกำหนดสิทธิ์ของ Agent กลายเป็นสัญญา SDK และกลไกที่ตรวจรายละเอียดได้ บทเรียนสำคัญไม่ใช่ “MXC ทำให้ทุก Agent ปลอดภัย” แต่คือ ตามให้พบว่าใครเรียกเครื่องมือ ที่ไหน และใครมีอำนาจหยุดคำขอนั้น
อ่านต่อใน Hybrid Mind: Loop Engineering — ออกแบบวงจรตรวจงาน และ AI ERA — Agent, tools และการทำงานร่วมกัน
FAQ
คำถามที่ต้องตอบก่อนใช้จริง
MXC เป็นโมเดล AI ตัวใหม่หรือไม่?
ไม่ใช่ เป็น SDK และระบบ containment สำหรับงานที่รันโค้ดหรือเรียกเครื่องมือ ภายใต้นโยบายและ Backend ที่รองรับ
เปิด Sandbox แล้ว Remote MCP ถูกกั้นด้วยไหม?
ไม่ใช่โดยอัตโนมัติ ใน integration ที่บทความอ้าง Remote MCP อยู่นอก local process sandbox การตรวจ connection policy ฝั่ง harness กับการจำกัดการกระทำบนเซิร์ฟเวอร์เป็นคนละขอบเขต
Learning mode ยอมให้สิทธิ์ที่ไม่ได้อนุญาตผ่านหรือไม่?
ตามตาราง Windows ProcessContainer ของ Microsoft: ไม่ยอมผ่าน แต่บล็อกและบันทึก อย่าสับสนกับ Permissive ที่ยอมผ่าน MXC พร้อมบันทึก และยังเคารพข้อจำกัด OS/องค์กร
GA แปลว่าพิสูจน์แล้วว่า Sandbox ไม่มีทางหลุดหรือไม่?
ไม่แปลเช่นนั้น GA เป็นสถานะ release ของผู้พัฒนา ส่วนหลักฐานด้านการแยกสิทธิ์ต้องผูกกับรุ่น นโยบาย Backend และสภาพแวดล้อมที่ทดสอบ
Lab นี้เรียก Agent หรือเปลี่ยนสิทธิ์เครื่องจริงหรือไม่?
ไม่เรียก API ไม่รัน Agent ไม่สั่ง OS และไม่ส่งข้อมูลออก เป็น Educational Simulation ใน Browser เท่านั้น ผลลัพธ์อธิบายความสัมพันธ์ตามสมมติฐานที่เขียนไว้ ไม่ใช่ผลทดสอบ MXC
ใส่ความเห็น