Meta เปิดตัว Muse เอเจนต์ส่วนตัวที่รันบน VM ของผู้ใช้เอง — และปล่อยเอกสารสถาปัตยกรรมความปลอดภัยที่ละเอียดที่สุดเท่าที่เอเจนต์ตัวไหนเคยปล่อย

วันที่ 8 กันยายน 2026 Meta เปิดตัว Muse ที่บริษัทเรียกว่า “personal AI agent” — ไม่ใช่แชตบอตที่ตอบคำถาม แต่เป็นเอเจนต์ที่ลงมือทำงานแทนผู้ใช้จริง ๆ เปิดเบราว์เซอร์ กรอกฟอร์ม ส่งอีเมล จองการเดินทาง และตามประกาศคือ “ต่อรองแทนคุณ” ได้ด้วย ตัวมันทยอยเปิดในสหรัฐฯ บน iOS, Android และ muse.ai คุยผ่านแอป Muse หรือผ่าน WhatsApp โดยตรงก็ได้ ส่วนแว่น AI ระบุว่า coming soon โมเดลที่ขับเคลื่อนคือ Muse Spark ซึ่งประกาศเรียกว่า “โมเดลที่เก่งที่สุดของ Meta จนถึงตอนนี้” ราคาคือฟรีสำหรับการใช้งานส่วนใหญ่ และมีแผนสมัครสมาชิกสำหรับคนที่ต้องการมากกว่านั้น

แต่สิ่งที่น่าสนใจกว่าตัวประกาศคือเอกสารคู่กันบน research.meta.ai ที่กางสถาปัตยกรรมความปลอดภัยของ Muse ออกมาแทบทั้งระบบ — ระดับที่บอกทั้งชื่อคอมโพเนนต์ วิธีแยกสิทธิ์ในเคอร์เนล และช่องทางที่ยังโจมตีได้ ทีมงานเขียนเองว่า “ความพยายามส่วนใหญ่ของโปรเจกต์นี้ลงไปที่ตรงนั้น” สำหรับคนที่กำลังสร้างเอเจนต์เอง เอกสารนี้มีค่ามากกว่าตัวผลิตภัณฑ์

VM หนึ่งเครื่องต่อผู้ใช้หนึ่งคน แล้วผ่าสิทธิ์ข้างในเป็นสองโดเมน

โมเดลความปลอดภัยตั้งต้นคือ ผู้ใช้แต่ละคนได้ Linux VM ของตัวเองบนคลาวด์ มีเบราว์เซอร์ พื้นที่เก็บข้อมูล ซีพียูและแรมพอที่จะ “คอมไพล์โค้ดที่เอเจนต์เขียนเอง สร้างสกิลของตัวเอง และรันซับเอเจนต์กับ cron พร้อมกัน” VM นี้เป็น system of record ของทุกอย่างที่ผู้ใช้ใส่เข้าไป และไคลเอนต์ (แอป iOS/Android/เว็บ) ต่อตรงเข้า VM ผ่านชั้นขนส่งที่เข้ารหัส

จุดที่ต่างจากเอเจนต์ทั่วไปคือ ข้างใน VM ยังถูกผ่าออกเป็นสองโดเมนความปลอดภัย ไม่ใช่ “LLM ที่มี root”:

• runtime cell — ที่อยู่ของ hatch daemon (ชื่อภายในของ Muse ในโค้ดเบส) พร้อมเวิร์กสเปซ ไฟล์ผู้ใช้ และไบนารีทุกตัวที่เอเจนต์รัน root ในเซลล์นี้ถูกแมปเป็น unprivileged user บนโฮสต์ ได้ root filesystem ของตัวเอง (อิมเมจ Debian เต็ม) แยกจากไฟล์ระบบที่อ่อนไหว มี virtual network interface ของตัวเอง syscall ถูกกรอง และ capability ของเคอร์เนลถูกจำกัด
• บริการนอกเซลล์ — รันเป็น systemd unit แยก ได้แก่ model gateway ที่มีชุดโมเดลและ classifier ของตัวเองคอยตรวจ request/response ที่วิ่งเข้าออก inference, privsep worker ที่รันโค้ดคอนเนกเตอร์ด้วยสิทธิ์แคบ ๆ, authd ที่เก็บ credential (รวม OAuth token ของบริการภายนอก — เก็บไว้ใน VM ของผู้ใช้ ไม่ใช่โครงสร้างพื้นฐานกลางของ Meta), Sentinel, และ postgres ที่เก็บสถานะถาวร

เหตุผลที่ต้องแยกก็ตรงไปตรงมา: runtime cell คือส่วนที่ “คาดว่าจะต้องประมวลผลข้อมูลที่ไม่น่าไว้ใจ” การเอา classifier ไว้นอกเซลล์แปลว่าผู้โจมตีปิดมันไม่ได้ การสื่อสารระหว่างเซลล์กับบริการอื่นใน VM ใช้ Unix domain socket พร้อม SO_PEERCRED และ peer ACL — คือยืนยันตัวตนที่ระดับเคอร์เนล และไม่มีความลับให้ขโมย

Sentinel: ผู้อนุมัติเพียงตัวเดียว และ credential ที่โมเดลไม่มีวันเห็น

Sentinel เป็นเอเจนต์ฝั่งโฮสต์ที่แยกจาก Muse และเป็น “ผู้มีอำนาจอนุญาตเพียงผู้เดียว” ทั้งสำหรับการเรียกคอนเนกเตอร์ไปยังบริการภายนอก และสำหรับ egress ทุกครั้งที่ออกเน็ต Muse ทำได้แค่ เสนอ แอ็กชัน คนที่อนุมัติคือ Sentinel เท่านั้น

ทราฟฟิกจาก runtime cell วิ่งเข้า Sentinel ผ่าน forward proxy ที่คุมด้วย userns, veth boundary และตัวกรอง eBPF โดย Sentinel ประเมินได้ทั้งเลเยอร์ 4 และ 7 — hostname, IP ปลายทางทั้งที่ resolve ได้และปลายทางจริง, พอร์ต, โปรโตคอล, HTTP method, path และ request ที่ถอดรหัสแล้ว พร้อมกันการโจมตีแบบ SSRF ที่ hostname ดูเป็นสาธารณะแต่ resolve ไปยังโครงสร้างพื้นฐานภายใน

ท่าที่คมที่สุดในเอกสารทั้งฉบับคือ credential surrogation: โค้ดใน runtime cell หรือใน worker จะเห็นได้แค่ “surrogate token” ที่ authd ปั๊มขึ้นมา หลังจาก Sentinel อนุมัติ request จริงแล้ว มันจะแทนที่ surrogate ด้วย credential จริงตรงขอบเน็ตเวิร์ก ผลคือเอเจนต์ไม่เคยเห็นโทเคนจริงเลย และเอกสารสรุปตรง ๆ ว่า ความพยายามหลอกให้เอเจนต์เปิดเผยความลับผ่าน prompt injection จึง “ไร้ผล”

อีกกลไกที่นักพัฒนาน่าจะยืมไปใช้ได้คือ tainted egress — การติดตามการไหลของข้อมูลระดับเคอร์เนล ทุกโพรเซสของ tool เริ่มต้นในสถานะสะอาด และกลายเป็น tainted เมื่ออ่านข้อมูลผู้ใช้ request ที่ยังสะอาดและเข้าเงื่อนไข auto-allow แบบแคบ ๆ ผ่านไปได้โดยไม่ต้องรบกวนผู้ใช้ ส่วนโพรเซสที่ tainted หรือตรวจสอบไม่ได้จะเสียสิทธิ์ auto-allow และตกกลับไปเข้าคิวขออนุมัติตามปกติ อิมพลีเมนต์ด้วยโปรแกรม eBPF สำหรับดักเน็ตเวิร์กและระบุตัวโพรเซส บวก eBPF ที่ผูกกับ Linux Security Module hook ที่ทีมเพิ่มเข้าไปเองเพื่อกระจาย taint

รายละเอียดเล็ก ๆ ที่สำคัญมากคือ ไดอะล็อกขออนุมัติไม่ได้วิ่งผ่านบทสนทนากับ Muse แต่ Sentinel ส่งตรงไปที่ไคลเอนต์ และคำตอบวิ่งกลับตรงมาที่ Sentinel — แปลว่าเอเจนต์ที่ถูกยึดแล้วปลอมคำขออนุมัติในแชตไม่ได้ สิทธิ์ที่อนุมัติเป็น capability จริง ผูกกับคอนเนกเตอร์/ปลายทาง/ยูสเคสนั้น ๆ และเลือกได้ว่าเป็นครั้งเดียว ผูกกับเซสชัน ผูกกับงาน มีกำหนดเวลา หรือถาวร

เบราว์เซอร์ที่เห็นแค่ accessibility tree และอีเมลที่กรอง OTP ทิ้ง

ฝั่งเบราว์เซอร์ Muse ใช้ Chromium จริงที่รันหลังชั้น virtualization และผู้ใช้แย่งคุมได้ตลอดเวลา แต่ซับเอเจนต์ที่ขับเบราว์เซอร์ เห็นเป็น accessibility tree snapshot ไม่ใช่ DOM ดิบ รันจาวาสคริปต์ในหน้าไม่ได้ ไม่มี script verb ไม่มี exec ในโพรเซสเบราว์เซอร์ และ devtools ถูกปิด ส่วนการต่อ Chrome DevTools Protocol อยู่ใน broker นอก runtime cell เมื่อผู้ใช้เข้ามาคุมเองหรือระหว่างที่ระบบเก็บ credential กรอกฟอร์มให้ เอเจนต์จะถูกหยุดและทำอะไรไม่ได้เลย

เหนือขึ้นไปมี classifier อีกชุดที่คอยดู 5 อย่าง: การส่งข้อมูลส่วนตัวออกทางเบราว์เซอร์โดยไม่เกี่ยวกับงาน, prompt injection ใน DOM, prompt injection ผ่านรูป/สื่อในหน้า, prompt injection ผ่านไฟล์ที่ดาวน์โหลด และการพยายามส่งฟอร์มความเสี่ยงสูง

ท่าที่ฉลาดที่สุดอาจเป็นเรื่องอีเมล เอกสารตั้งข้อสังเกตว่ากล่องอีเมลหลักคือกุญแจสำรองของทั้งชีวิตดิจิทัล เพราะมันมีทั้งรหัสผ่านครั้งเดียวและลิงก์รีเซ็ตรหัสผ่านของเว็บอื่น ๆ ดังนั้นคอนเนกเตอร์อีเมลของ Muse จึง กรอง one-time token, ลิงก์รีเซ็ตรหัสผ่าน และ magic link ทิ้ง ด้วยทั้งตัวกรองแบบกำหนดกฎและโมเดล classifier

สำหรับการชำระเงิน Muse ใช้ Link ของ Stripe ออกเลขบัตรแบบใช้ครั้งเดียวที่ผูกกับร้านค้าและยอดเงินนั้น ๆ และมีอายุจำกัด พร้อมขออนุมัติจากคนทุกครั้ง ส่วน Shop Pay และการรองรับ 1Password ระบุว่ากำลังจะมา

สิ่งที่ประกาศไม่ได้พูดดัง ๆ

หนึ่ง — Meta ยอมรับเองว่ายังแก้ prompt injection ไม่ได้ เอกสารอ้างคำว่า “lethal trifecta” ของ Simon Willison (มิ.ย. 2025) ตรง ๆ และปิดท้ายว่า “prompt injection ยังเป็นปัญหาที่เปิดอยู่ในอุตสาหกรรม และ Muse จะทำผิดพลาดบ้าง” สิ่งที่ระบบนี้ทำได้คือ จำกัดความเสียหาย ไม่ใช่ป้องกัน โดยระดับโมเดลระบุแค่ว่า Muse Spark 1.3 “ใกล้ SOTA” ในความสามารถต้าน prompt injection — ไม่มีตัวเลขให้ตรวจ

สอง — บั๊กบาวน์ตี้เปิดวันนี้ที่สูงสุด 300,000 ดอลลาร์ และหน้าเดียวกันระบุเจาะจงว่าจ่ายได้ถึง 130,000 ดอลลาร์สำหรับ prompt injection ที่สำเร็จและกระทบผู้ใช้หนึ่งราย ตัวเลขหลังนี้บอกเป็นนัยว่าทีมงานคาดว่าจะมีคนทำได้ ไม่ใช่ท้าเล่น ๆ

สาม — โหมดที่ Meta เข้าถึงข้อมูลไม่ได้ยังไม่ออก สถาปัตยกรรมวันนี้แยกข้อมูลผู้ใช้ออกจากกันและจำกัดการเข้าถึงของพนักงานด้วย “นโยบายปฏิบัติการ” แต่เอกสารเขียนตรง ๆ ว่า “มันไม่ได้ป้องกัน Meta จากการเข้าถึงข้อมูลเมื่อจำเป็นต่อการสนับสนุน รักษาความปลอดภัย หรือให้บริการ” ส่วน Muse Confidential VM ที่เข้ารหัสด้วยกุญแจของผู้ใช้คนเดียวนั้นระบุว่าจะมาภายในปีนี้ ตอนนี้อยู่กับกลุ่มทดสอบและเริ่มเปิดโค้ดให้ผู้ตรวจสอบภายนอกดูแล้ว

สี่ — ค่าเริ่มต้นคือข้อมูลของคุณถูกใช้เทรน trajectory ทั้งบทสนทนา tool call และการส่งต่อระหว่างซับเอเจนต์ ถูกนำไปเทรนเช็กพอยต์ใหม่ของโมเดลโดยผ่านการล้าง PII ก่อน ผู้ใช้ปิดได้ด้วยสวิตช์ในตั้งค่า — แต่ต้องไปปิดเอง และแม้ Muse จะไม่แชร์บทสนทนากับระบบโฆษณา เอกสารก็ยอมรับว่าเมื่อ Muse ท่องเว็บ “มันจะปรากฏเป็นกิจกรรมของคุณ” ดังนั้นการที่เอเจนต์ไปเปิดเว็บร้านเสื้อผ้าอาจทำให้คุณเห็นโฆษณาร้านนั้นบน Instagram ได้อยู่ดี

ห้า — ไม่มี API สำหรับนักพัฒนาและไม่มีน้ำหนักโมเดลในประกาศนี้ Muse เป็นผลิตภัณฑ์ปลายทาง ไม่ใช่แพลตฟอร์ม และเปิดเฉพาะสหรัฐฯ

มุมมอง AI Curator

ตัดเรื่องผลิตภัณฑ์ออกไปก่อน แล้วมองสิ่งที่ Meta ปล่อยวันนี้ในฐานะ เอกสารอ้างอิงสถาปัตยกรรม — นี่คือครั้งแรกที่บริษัทใหญ่ส่งเอเจนต์ผู้บริโภคออกมาพร้อมกับ threat model ที่เขียนละเอียดพอจะเอาไปลอกได้ และคุณค่าของมันไม่ได้ผูกกับสเกลของ Meta เลย

ทีมไทยที่กำลังสร้างเอเจนต์ให้ลูกค้าองค์กรลอกได้อย่างน้อยสี่ข้อโดยไม่ต้องมีงบระดับนี้: (1) เอเจนต์ไม่ควรเห็น credential จริง — วาง proxy ที่ฉีดโทเคนตอนขอบเน็ตเวิร์ก แล้วให้โค้ดฝั่งเอเจนต์ถือแค่ตัวแทน ข้อนี้ตัดคลาสการโจมตี exfiltration ทิ้งไปทั้งคลาสด้วยงานวิศวกรรมไม่กี่วัน (2) แยกผู้อนุมัติออกจากผู้ขอ — ถ้าไดอะล็อกยืนยันวิ่งผ่านบทสนทนาเดียวกับที่โมเดลเขียนได้ มันก็ปลอมได้ (3) ให้ซับเอเจนต์เบราว์เซอร์เห็น accessibility tree แทน DOM ดิบ ซึ่งลดพื้นที่ฉีดคำสั่งลงมหาศาลและทำได้ด้วย Playwright/CDP วันนี้ (4) กรอง OTP กับลิงก์รีเซ็ตรหัสผ่านออกจากคอนเนกเตอร์อีเมล — ข้อนี้ถูกมองข้ามบ่อยที่สุด และเป็นข้อที่พังแล้วเจ็บที่สุด เพราะกล่องอีเมลคือกุญแจของทุกบัญชี

ในทางกลับกัน ควรอ่านประกาศนี้อย่างมีระยะห่างด้วย โครงสร้างนี้ปลอดภัยขึ้นจริงในเชิงวิศวกรรม แต่มันไม่ได้แก้คำถามเชิงความไว้ใจ: ผู้ใช้ยังต้องยกกล่องอีเมล ปฏิทิน รหัสผ่าน และบัตรเครดิตให้เครื่องที่บริษัทเป็นคนดูแล โดยค่าเริ่มต้นให้เอาบทสนทนาไปเทรนโมเดล และโหมดที่ผู้ให้บริการเข้าถึงไม่ได้จริง ๆ ยัง “จะมาภายในปีนี้” การที่ Meta เขียนข้อจำกัดพวกนี้ไว้เองอย่างตรงไปตรงมาเป็นเรื่องดีและควรชม — แต่ตรงไปตรงมาไม่เท่ากับแก้แล้ว

สำหรับผู้อ่านไทย ผลกระทบระยะสั้นคือศูนย์ เพราะเปิดเฉพาะสหรัฐฯ แต่ผลระยะกลางไม่ใช่ศูนย์เลย: เมื่อเอเจนต์ผู้บริโภคที่ จ่ายเงินแทนคุณได้ กลายเป็นของปกติ เว็บอีคอมเมิร์ซและระบบธนาคารไทยจะเริ่มเจอทราฟฟิกที่เป็นคนจริง มีตัวตนจริง แต่ไม่ได้นั่งอยู่หน้าจอ คำถามว่า “จะแยกเอเจนต์ที่ผู้ใช้อนุญาตออกจากบอตที่ควรบล็อกอย่างไร” จะเป็นโจทย์ของทีม fraud และทีม platform ไทยภายในปีสองปีนี้ ไม่ใช่ปัญหาไกลตัว

แหล่งข่าว

• Introducing Muse: The World’s First Personal AI Agent Built for Everyone — Meta Newsroom (8 ก.ย. 2026)
• How We Built Safety Into Muse — Meta AI Research
• The lethal trifecta for AI agents — Simon Willison (มิ.ย. 2025)
• Meta Bug Bounty