Meta ออกแบบความปลอดภัย AI agent ของ Muse อย่างไร และจุดที่ต้องเชื่อใจ

โดย Nokka (นก-กา) | 19 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka ข้อความในเครื่องหมายคำพูดที่เป็นคำแปลเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ

Meta เปิดตัว Muse agent ส่วนตัวเมื่อวันที่ 8 กันยายน 2026 แล้ววันที่เดียวกันก็เผยแพร่เอกสารยาว 20 นาทีอ่าน อธิบายว่าพวกเขาออกแบบความปลอดภัยไว้อย่างไร [1][2]

⇒ เอกสารชิ้นนั้นน่าสนใจเพราะเขียนโดยทีมที่ยอมรับว่าเคยให้ agent เข้าถึงกล่องอีเมล ปฏิทิน และเชลล์ของตัวเอง แล้วพบว่ามัน "ไม่ได้เป็นไปตามแผนเสมอไป" [1]

และเปิดเผยสถาปัตยกรรมละเอียดกว่าที่บริษัทส่วนใหญ่ยอมเปิด ทั้งชื่อโปรเซสภายใน ชื่อกลไก และตัวเลขรางวัล [1]

สถาปัตยกรรม: คอมพิวเตอร์หนึ่งเครื่องที่คุณแชร์กับ agent

Muse ให้ผู้ใช้แต่ละคนได้เครื่องเสมือน (VM) ส่วนตัวบนคลาวด์ ที่นั่นคือที่เก็บข้อมูลและ credential ทุกอย่างที่ผู้ใช้เชื่อมต่อ เป็น Linux ที่แยกออกมาพร้อมเบราว์เซอร์ พื้นที่เก็บ และพลังประมวลผลพอจะคอมไพล์โค้ดที่ agent เขียนได้ [1]

เอกสารระบุว่า VM นี้เป็น ระบบบันทึกหลัก ของทุกอย่างที่ผู้ใช้ใส่เข้าไป Muse ส่งข้อมูลออกจาก VM เฉพาะเท่าที่จำเป็นต่อการ inference และ telemetry [1]

เอกสารยังระบุด้วยว่า connector ของบริการภายนอกที่ผู้ใช้เลือกเชื่อม เช่น อีเมล รถยนต์ หรือบ้านอัจฉริยะ ทำงานผ่าน API ที่ทีมงานเขียนร่วมกับผู้ให้บริการนั้น [1]

หลังเปิดตัว บริการนี้เริ่มให้ใช้ในสหรัฐก่อน และมีรายงานเรื่องระดับราคาแยก ตัวเลขระดับราคาผมไม่ได้ยืนยันกับประกาศของ Meta จึงไม่ระบุในบทความนี้ [5]

ภาพรวมสถาปัตยกรรมที่ Meta อธิบายไว้ในเอกสาร [1]

ชั้น	ทำหน้าที่อะไร	อยู่ที่ไหน
คอนเทนเนอร์ systemd-nspawn	รัน harness และเครื่องมือของ agent	ข้างในเซลล์ที่แยกออกมา
Sentinel	อนุมัติการกระทำและเครือข่ายขาออก	ฝั่งโฮสต์ นอกคอนเทนเนอร์
authd	เก็บและสลับ credential	ฝั่งโฮสต์ นอกคอนเทนเนอร์
privsep worker	รันตรรกะของ connector	sandbox แยก มี allowlist ของตัวเอง
hatch-safety	ตรวจคำขอและคำตอบของการ inference	ฝั่งโฮสต์ นอกคอนเทนเนอร์

ภาพที่ 1: การแยกสองโดเมนความปลอดภัยที่ Meta ใช้ใน Secure VM

หลักคิดที่ทีมงานเขียนไว้ชัด

มีประโยคหนึ่งในเอกสารที่ผมอ่านแล้วคิดว่าเป็นหัวใจของเรื่องทั้งหมด

"แบบจำลองทางความคิดที่ถูกต้องคือ มีโดเมนความปลอดภัยสองโดเมนแยกกันบนเครื่องเดียว ไม่ใช่ agent ที่ขับเคลื่อนด้วย LLM ซึ่งถือสิทธิ์ root" [1]

และอีกประโยคคือ "เราออกแบบระบบโดยสมมติว่า agent อาจถูกโจมตีอยู่ และจำกัดความเสียหายที่อาจเกิดขึ้น" [1]

นี่คือการยอมรับว่า prompt injection แก้ให้หมดไม่ได้ จึงเปลี่ยนเป้าหมายจากการป้องกันไม่ให้เกิด เป็นการทำให้ความเสียหายมีขอบเขต [1]

แยกสองโดเมนด้วยอะไร

agent ทำงานในคอนเทนเนอร์ systemd-nspawn โดยมีรายละเอียดที่ทีมงานระบุไว้ตรง ๆ [1]

• สิทธิ์ root ในคอนเทนเนอร์ถูกแมปเป็นผู้ใช้ธรรมดาของโฮสต์ ⇒ ไม่ใช่ root ของเครื่องจริง
• คอนเทนเนอร์มีระบบไฟล์รากของตัวเอง (อิมเมจ Debian เต็มชุด) แยกจากโฮสต์
• มีการกรอง system call เช่น ไม่มี io_uring
• จำกัด kernel capability เช่น ไม่มี CAP_SYS_PTRACE และไม่มี CAP_NET_ADMIN

ส่วนบริการที่อ่อนไหวต่อความปลอดภัย อยู่ข้างนอกคอนเทนเนอร์ ทีมงานให้เหตุผลว่าคอนเทนเนอร์นั้นถูกออกแบบให้ประมวลผลข้อมูลที่ไม่น่าเชื่อถือ ถ้าโจมตีเข้ามาได้ ก็ไม่ควรปิดการป้องกันได้จากข้างใน [1]

ตัวอย่างบริการข้างนอกที่ระบุชื่อไว้คือ hatch-safety ซึ่งรันโมเดลและตัวจำแนกอีกชุดหนึ่ง คอยตรวจคำขอและคำตอบที่เข้า ออกจากการ inference [1]

และการสื่อสารระหว่างคอนเทนเนอร์กับบริการอื่นใน VM ทำผ่าน Unix domain socket ที่ตรวจสอบตัวตนด้วย SO_PEERCRED และ ACL ทีมงานเขียนว่าวิธีนี้ทำให้การสื่อสารยืนยันตัวตนได้จากเคอร์เนล จำกัดสิทธิ์ขั้นต่ำ และ ไม่มี secret ให้ขโมย [1]

Sentinel: ผู้มีอำนาจอนุมัติแต่เพียงผู้เดียว

สองชั้นที่ตรวจทุกคำขอ

Sentinel เป็น agent แยกตัวหนึ่งที่อยู่ฝั่งโฮสต์ ไม่ใช่ตัว Muse เอง และเป็น ผู้มีอำนาจอนุมัติแต่เพียงผู้เดียว สำหรับการกระทำผ่าน connector และการออกสู่เครือข่ายภายนอก [1]

⇒ Muse เสนอการกระทำได้ แต่ มีแค่ Sentinel ที่ให้สิทธิ์ได้ [1]

กลไกทำงานแบบนี้ Muse เรียก tool ในคอนเทนเนอร์ tool ส่งคำขอไปที่ Sentinel โดยบอกว่าเป็น connector ตัวไหน จะเรียกเมธอดอะไร อยู่ในกลุ่มการกระทำแบบใด ขอบเขตแค่ไหน และบริบทที่ผู้ใช้สั่งไว้คืออะไร Sentinel จะสร้างคำอธิบายที่ผู้ใช้เห็นได้จากข้อมูลนั้น แล้วตัดสินว่าอนุญาต ปฏิเสธ หรือต้องถามผู้ใช้ โดยอ้างนโยบายที่ผู้ใช้ตั้งไว้เอง [1]

ทุกคำขอเครือข่ายถูกตรวจที่จุดออก การจราจรจากคอนเทนเนอร์ไปถึง Sentinel ผ่าน forward proxy ที่ตั้งค่าด้วยกลไกเครือข่ายของ Linux ทั้ง userns ขอบเขต veth และการกรองด้วย eBPF [1]

Sentinel ดูได้ทั้ง ชั้น 4 และชั้น 7 ทั้ง hostname ไอพีปลายทางที่ resolve ได้และไอพีจริง พอร์ต โปรโตคอล HTTP method เส้นทาง และ เนื้อคำขอที่ถอดรหัสแล้ว [1]

และมีข้อจำกัด SSRF เพื่อกันกรณีที่ hostname ดูเป็นสาธารณะ แต่ resolve แล้วชี้ไปที่โครงสร้างพื้นฐานภายใน [1]

กลไกที่ผมคิดว่าฉลาดที่สุด: credential ปลอม

เบราว์เซอร์ใช้หลักเดียวกัน

ทุกคำขอที่ต้องใช้ secret หรือ token จะถูก ใส่ credential ให้ที่จุดออกของเครือข่าย โค้ดในคอนเทนเนอร์จะเห็นแค่ token ปลอม ที่ authd สร้างขึ้น [1]

⇒ พอคำขอได้รับอนุญาต Sentinel จะสลับ token ปลอมเป็น credential จริงที่ดึงจาก authd ณ ขอบเครือข่าย [1]

ทีมงานเขียนผลลัพธ์ไว้ตรง ๆ ว่า agent ไม่เคยเห็น token จริง ความพยายามบังคับให้ agent เปิดเผย secret ไม่ว่าจะด้วย prompt injection หรือวิธีอื่น จึงไร้ผล [1]

และหลักนี้ยังใช้กับเบราว์เซอร์ ตัว agent ควบคุมเบราว์เซอร์ผ่าน broker ที่อยู่นอกคอนเทนเนอร์ มันเห็นแค่ accessibility tree ของหน้า ไม่เห็น DOM ดิบ จึงอ่าน credential ที่กรอกจากที่เก็บไม่ได้ และไม่มีสิทธิ์รัน JavaScript ในหน้า เว้นแต่ผู้ใช้เข้าควบคุมเบราว์เซอร์เอง หรือระหว่างที่ระบบกำลังกรอก credential agent จะถูกหยุดและทำอะไรไม่ได้เลย [1]

ภาพที่ 2: กลไก token ปลอมที่ทำให้ agent เปิดเผย credential จริงไม่ได้

วิธีลดการรบกวนผู้ใช้: tainted egress

ปัญหาของระบบที่ถามทุกครั้งคือผู้ใช้จะเลิกอ่านคำเตือน [1]

⇒ Muse แก้ด้วยการติดตามการไหลของข้อมูลที่ระดับเคอร์เนล เรียกว่า "tainted egress" โปรเซสที่รัน tool จะเริ่มในสถานะสะอาด และจะกลายเป็น tainted ถ้ามันอ่านข้อมูลของผู้ใช้ [1]

คำขอเครือข่ายที่ยังสะอาด และเข้าเงื่อนไขนโยบายอนุญาตอัตโนมัติแบบแคบ พร้อมผ่านการตรวจ URL ขาออก ผ่านได้โดยไม่รบกวนผู้ใช้ [1]

แต่โปรเซสที่ tainted หรือตรวจสอบที่มาไม่ได้ จะเสียสิทธิ์ auto-allow และกลับเข้าสู่กระบวนการขออนุมัติปกติ [1]

การติดตั้งใช้โปรแกรม eBPF ระดับ cgroup เพื่อดักจับเครือข่ายและระบุตัวโปรเซส บวกกับโปรแกรม eBPF ที่ต่อกับ Linux Security Module hook ที่ทีมงานเพิ่มเองเพื่อแพร่สถานะ taint [1]

การอนุมัติเป็นสิทธิ์ ไม่ใช่คำแนะนำ

เมื่อ Sentinel ตัดสินว่าต้องถาม มันจะหยุดการทำงาน สร้างคำขออนุมัติ แล้วส่งตรงไปที่แอปของ Muse หน้าต่างยืนยันจะเด้งในตัวแอป ไม่ใช่ในบทสนทนากับ Muse และคำตอบวิ่งกลับไปที่ Sentinel โดยตรง [1]

⇒ ประโยคที่ผมคิดว่าสำคัญคือ เอกสารเขียนว่าการอนุมัติผ่านระบบนี้ "เป็นสิทธิ์ที่เข้มงวด ไม่ใช่คำแนะนำในบทสนทนา" คือผูกกับ connector ปลายทาง และกรณีการใช้งานนั้น ๆ [1]

Muse รองรับการให้สิทธิ์แบบครั้งเดียว ผูกกับเซสชัน ผูกกับงาน จำกัดเวลา หรือถาวร และ Sentinel เป็นตัวเลือกว่าควรเสนอแบบไหนให้ผู้ใช้เลือก พร้อมตรวจว่าการเรียกครั้งถัดไปตรงกับขอบเขตที่ให้ไว้เป๊ะหรือไม่ [1]

ตัวอย่างการใช้หลักสิทธิ์ขั้นต่ำ

ทีมงานยกตัวอย่างเรื่องการอ่านกับเขียน ผู้ใช้มักสบายใจที่จะให้ agent อ่าน ข้อมูลก่อน (เช่น "อ่านปฏิทินฉันแล้วเตือนถ้ามีเวลาชนกัน") และขอเวลาทำความเข้าใจระบบก่อนจะให้สิทธิ์เขียน [1]

และ Muse แยกสิทธิ์อ่านกับเขียนออกจากกันในกรณีที่บริการต้นทางรองรับ [1]

เอกสารยกตัวอย่างที่เฉพาะเจาะจงว่า ถ้าคุณให้สิทธิ์ Gmail แบบอ่านผ่าน OAuth คุณยัง ถอดความสามารถเข้าถึงการตั้งค่า Gmail ที่มักมาพร้อมกัน ออกได้ [1]

⇒ เหตุผลที่ต้องทำแบบนี้คือ วิธีมาตรฐานของ agent ทั่วไปคือให้ CLI ของ connector รัน ในสภาพแวดล้อมเดียวกับ harness ซึ่งมีความเสี่ยงว่า agent อาจถูก prompt injection หลอกให้แก้โค้ดของ tool เพื่อใช้ credential ที่ CLI เข้าถึงได้ไปทำเรื่องอื่น [1]

Muse จึงรันตรรกะของ connector นอกคอนเทนเนอร์ และให้สิทธิ์ credential แบบแคบผ่านกลไก privsep CLI ในคอนเทนเนอร์ทำแค่แปลง argument เปิดไฟล์ที่ผู้เรียกมีสิทธิ์อยู่แล้ว แล้วส่ง argument ที่มี type กับ file descriptor ผ่าน Unix socket จากนั้น worker ที่ถูก sandbox ด้วย systemd จึงรันตรรกะจริง [1]

ทีมงานสรุปการแบ่งหน้าที่ไว้สั้น ๆ ว่า privsep ตัดสินว่าโค้ดที่เข้าถึง credential ได้จะรันที่ไหน authd ตัดสินว่าผู้เรียกที่ยืนยันตัวตนแล้วจะได้ material อะไร Sentinel ตัดสินว่าการกระทำที่ขอมาอนุญาตได้หรือไม่ [1]

และแต่ละ worker ถูกระบุด้วย cgroup พร้อม allowlist credential ที่ชัดเจน worker ของปฏิทินขอ credential ของอีเมลไม่ได้เพียงแค่แก้พารามิเตอร์ในคำขอ [1]

เรื่องการจ่ายเงิน

การซื้อของผ่านเบราว์เซอร์เป็นกรณีใช้ที่นิยมที่สุดกรณีหนึ่ง และความผิดพลาดตรงนี้เสียเงินจริง [1]

⇒ ถ้าซื้อบนเว็บที่ผู้ใช้มีข้อมูลจ่ายเงินอยู่แล้ว ระบบมีการตรวจจับว่าอยู่หน้าชำระเงิน และขออนุมัติจากคนทุกครั้งพร้อมรายละเอียดการซื้อที่แน่นอน [1]

ส่วนเว็บที่ไม่เคยซื้อ Muse มีกระเป๋าเงินเก็บ credential การจ่ายอย่างเป็นระบบ ตอนเปิดตัวจับมือกับ Stripe Link และ Shop Pay กำลังจะตามมา [1]

เมื่อจ่าย ระบบจะออก หมายเลขบัตรแบบใช้ครั้งเดียว แล้วส่งหมายเลขนั้นให้เว็บ merchant แทนบัตรจริง credential ผูกกับ merchant รายนั้น จำนวนเงินนั้น และใช้ได้ในช่วงเวลาจำกัด ต่อให้ถูกขโมยผ่าน prompt injection ก็ไม่มีประโยชน์มากนักกับผู้โจมตี [1]

ตัวเลขที่ Meta ใส่ราคาไว้เอง

Muse เปิดโปรแกรม bug bounty ให้คนนอกส่งรายงาน รางวัลสูงสุด 300,000 ดอลลาร์ ตามผลกระทบที่พิสูจน์ได้ [1]

และในนั้นมีอัตราเฉพาะสำหรับ ความพยายาม prompt injection ที่สำเร็จและกระทบผู้ใช้หนึ่งราย สูงสุด 130,000 ดอลลาร์ [1]

ทีมงานให้เหตุผลว่าจ่ายรางวัลเพราะเชื่อว่านี่คือแนวปฏิบัติที่ดีที่สุดที่จะช่วยให้พฤติกรรมจริงของ Muse ดีขึ้นเร็วที่สุด ไม่ใช่เพราะคิดว่าหาไม่เจอ [1]

⇒ การตั้งราคาแบบนี้ทำให้เห็นว่าบริษัทประเมินความเสี่ยงข้อนี้ไว้เท่าไร และเป็นการประกาศว่ายังไม่มีใครพิสูจน์ว่าโจมตีไม่ได้ [1]

หลักเกณฑ์การจ่ายรางวัลของ Meta ระบุว่าการประเมินขึ้นกับผลกระทบที่พิสูจน์ได้ [3] และ Muse ยังเป็นหนึ่งในกลุ่มผลิตภัณฑ์ที่ทีมวิจัย Meta เปิดให้ทดลองใช้ต่อจาก Muse Spark และ Muse Code [4]

จุดที่ต้องเชื่อใจ Meta เอง

นโยบาย กับคณิตศาสตร์ ต่างกัน

นี่คือส่วนที่ผมคิดว่าผู้อ่านควรรู้ และเอกสารทางการไม่ได้เขียนไว้

SiliconANGLE รายงานว่าในทางเทคนิค Meta เข้าถึงข้อมูลใน Secure VM ได้ โดยอ้างคำให้สัมภาษณ์ของ David Singleton รองประธานฝ่ายวิศวกรรมผลิตภัณฑ์ผู้บริโภคของ Meta Superintelligence Labs ที่ให้ไว้กับ Wired ถึงแม้นโยบายของบริษัทจะไม่อนุญาตให้ทำ [2]

เอกสารทางการของ Meta เขียนไว้ตรง ๆ ว่า สถาปัตยกรรมปัจจุบัน จำกัด การเข้าถึงข้อมูลของผู้ใช้โดยพนักงาน Meta ผ่านนโยบายการดำเนินงาน แต่ ไม่ได้ป้องกัน Meta จากการเข้าถึงเมื่อจำเป็นต่อการสนับสนุน รักษาความปลอดภัย หรือดำเนินการบริการ [1]

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

⇒ ผมคิดว่านี่คือความต่างที่สำคัญ การป้องกันข้อมูลด้วยนโยบาย กับการป้องกันด้วยคณิตศาสตร์ เป็นคนละระดับของความเชื่อใจ และ Meta เองก็ยอมรับเรื่องนี้ด้วยการสร้างผลิตภัณฑ์ที่สองมาแก้ [1][2]

เรื่องโฆษณาและการเทรน

ประเด็นที่คนถามมากและเอกสารตอบไว้ตรง ๆ [1]

Muse ไม่แชร์ บทสนทนาหรือข้อมูลใน VM ให้ระบบโฆษณาของ Meta [1]

แต่มีกรณีที่การใช้งานส่งผลต่อโฆษณาโดยอ้อม เมื่อ Muse ท่องเว็บ มันปรากฏเป็นการใช้งานของผู้ใช้ ถ้าสั่งให้ซื้อเสื้อจากเว็บดีไซเนอร์ เจ้าของเว็บอาจใช้การเข้าชมนั้นไปแสดงโฆษณาบน Instagram [1]

ส่วนข้อมูลการ inference ทั้งบทสนทนาและ trajectory ของ tool call ถูกใช้เทรน checkpoint ใหม่ของโมเดล โดยทีมงานระบุว่าผ่านการล้างข้อมูลส่วนบุคคลที่ระบุตัวตนได้ออกก่อนใช้ และมีสวิตช์ให้ opt-out ได้ในตั้งค่า [1]

ภาพที่ 3: ความต่างระหว่างการป้องกันด้วยนโยบายกับด้วยคณิตศาสตร์

สิ่งที่ผมเห็นจากเอกสารชิ้นนี้

เอกสารนี้ต่างจากประกาศเปิดตัว agent ทั่วไปตรงที่มัน ให้รายละเอียดมากพอจะถูกตรวจสอบ ชื่อโปรเซส ชื่อกลไก และสิ่งที่ระบบทำไม่ได้ ถูกเขียนไว้ทั้งหมด [1]

และผมคิดว่าประโยคสำคัญที่สุดในเอกสารคือการยอมรับว่า prompt injection ยังเป็นปัญหาที่แก้ไม่ได้ในวงการ เพราะคำยอมรับนั้นเป็นตัวกำหนดการออกแบบทั้งหมดที่เหลือ [1]

⇒ แต่จุดที่ต้องไม่ลืมคือ ชั้นป้องกันทั้งหมดนี้ทำงานอยู่บน VM ที่ Meta เป็นเจ้าของ ไม่ว่าจะซับซ้อนแค่ไหน มันก็ยังเป็นการที่ผู้ใช้มอบความไว้วางใจให้บริษัทหนึ่ง และบริษัทนั้นยอมรับเองว่ายังเข้าถึงได้ในทางเทคนิค [1][2]

Muse Confidential VM จึงเป็นคำตอบที่ตรงคำถามที่สุด แต่ยังไม่เปิดให้ใช้ Meta ระบุเพียงแผนจะส่งมอบ "ภายในปีนี้" และตอนนี้ยังอยู่ในมือผู้ตรวจสอบภายนอก [1]

---

ถ้าคุณกำลังประเมินว่าจะมอบอีเมลและปฏิทินให้ agent ส่วนตัวไหม เอกสารชิ้นนี้เป็นตัวอย่างที่ดีของคำถามที่ควรถามผู้ให้บริการ ไม่ใช่ "ปลอดภัยไหม" แต่เป็น "ถ้า agent ถูกหลอกสำเร็จ อะไรคือความเสียหายสูงสุดที่เกิดขึ้นได้" [1]

สำหรับ Muse คำตอบที่ทีมงานให้คือ ความเสียหายถูกจำกัดด้วยการที่ agent ไม่เคยเห็น credential จริง ทุกการออกเครือข่ายต้องผ่าน Sentinel และการจ่ายเงินทุกครั้งต้องมีคนกดยืนยัน [1]

⇒ ส่วนคำถามที่ Meta ยังตอบไม่ได้ตอนนี้คือ เรื่องเจ้าของ VM เอง [1][2]

---

ถ้าคุณกำลังประเมินว่าจะมอบกล่องอีเมลหรือปฏิทินให้ agent ส่วนตัวไหม ลองถามผู้ให้บริการด้วยคำถามชุดเดียวกับที่ Meta ตอบไว้ในเอกสารนี้ agent เห็น credential จริงไหม ทุกอย่างที่ออกเครือข่ายผ่านจุดตรวจอะไร และการจ่ายเงินมีขั้นยืนยันจากคนหรือเปล่า [1]

คำตอบทั้งสามข้อจะบอกได้มากกว่าคำว่า "ปลอดภัย" ในหน้าขายสินค้า และถ้าผู้ให้บริการตอบไม่ได้ ตัวคำตอบนั้นก็เป็นข้อมูลแล้ว [1][2]

แหล่งอ้างอิง

[1] Meta AI Research — "How We Built Safety Into Muse" (Tarek Sheasha, Software Engineer & VP, Meta Superintelligence Labs), 8 กันยายน 2026 — https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse

[2] SiliconANGLE — "Meta debuts its 'secure by design' personal AI agent Muse, stock rises 6%", 8 กันยายน 2026 — https://siliconangle.com/2026/09/08/meta-debuts-its-secure-by-design-personal-ai-agent-muse

[3] Meta Bug Bounty — "Meta GenAI Payout Guidelines", กันยายน 2026 — https://bugbounty.meta.com/payout-guidelines/meta-genai/

[4] Meta AI Research — หน้าหลักงานวิจัย (Muse Spark, Muse Code, Muse Image), กันยายน 2026 — https://ai.meta.com/research

[5] TechNode Global — "Meta launches Muse personal AI agent in the US", 9 กันยายน 2026 — https://technode.global/2026/09/09/meta-launches-muse-personal-ai-agent-us