Agent Safehouse – เครื่องมือแซนด์บ็อกซ์สำหรับเอเจนต์ภายในเครื่องบน macOS

 (agent-safehouse.dev)
16 คะแนน โดย GN⁺ 2026-03-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือที่แยกการทำงานของ AI เอเจนต์ภายในเครื่องผ่าน แซนด์บ็อกซ์แบบเนทีฟของ macOS เพื่อไม่ให้สามารถแก้ไขสิ่งที่อยู่นอกระบบได้
  • เอเจนต์ทุกตัวทำงานใน สภาพแวดล้อมแซนด์บ็อกซ์ที่แยกอิสระ ทำให้ไม่สามารถเข้าถึงโฮมไดเรกทอรีของผู้ใช้หรือโปรเจ็กต์อื่นได้
  • ใช้ โมเดลการเข้าถึงแบบ Deny-first โดยอนุญาตให้อ่านและเขียนได้เฉพาะไดเรกทอรีที่ระบุอนุญาตไว้อย่างชัดเจนเท่านั้น
  • ติดตั้งเสร็จได้ด้วย สคริปต์ Bash เพียงไฟล์เดียว และสามารถรันได้ทันทีโดยไม่ต้องบิลด์เพิ่มหรือมี dependencies อื่น
  • มีฟีเจอร์สร้างโปรไฟล์ด้วย LLM เพื่อทำให้การตั้งค่า sandbox-exec แบบสิทธิ์ต่ำสุดที่จำเป็น เป็นอัตโนมัติ

ภาพรวม

  • Agent Safehouse คือ ระบบแซนด์บ็อกซ์สำหรับ macOS โดยเฉพาะ ที่ช่วยปกป้องไม่ให้ AI เอเจนต์ที่รันในเครื่องทำความเสียหายกับไฟล์ระบบ
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • ป้องกันความเสี่ยงจากการรันคำสั่งที่ไม่คาดคิดอันเกิดจากธรรมชาติแบบความน่าจะเป็นของ LLM
  • เอเจนต์หลักทุกตัว สามารถทำงานได้สมบูรณ์ภายในแซนด์บ็อกซ์ โดยไม่ส่งผลกระทบต่อระบบภายนอก
  • ใช้ โมเดลการเข้าถึงแบบ Deny-first ที่บล็อกทุกการเข้าถึงเป็นค่าเริ่มต้น และอนุญาตเฉพาะเส้นทางที่ระบุไว้ชัดเจนเท่านั้น
    • ตัวอย่าง: ~/my-project อนุญาตให้อ่าน/เขียนได้ แต่ ~/.ssh, ~/.aws, ~/other-repos จะถูกปฏิเสธการเข้าถึง

การติดตั้งและการรัน

  • การติดตั้งเสร็จสิ้นได้ด้วยการดาวน์โหลด เชลล์สคริปต์ เพียงไฟล์เดียว
    • ใช้คำสั่ง curl เพื่อดาวน์โหลดสคริปต์ไปเก็บที่ ~/.local/bin/safehouse แล้วให้สิทธิ์รัน
  • จากนั้นใช้คำสั่ง safehouse เพื่อรันเอเจนต์ที่ต้องการ
    • ตัวอย่าง: safehouse claude --dangerously-skip-permissions
  • โดยค่าเริ่มต้น Safehouse จะให้สิทธิ์อ่าน/เขียนกับ ไดเรกทอรีทำงานปัจจุบัน (git root) และอนุญาตการเข้าถึง ไดเรกทอรี toolchain แบบอ่านอย่างเดียว

ตัวอย่างการตรวจสอบแซนด์บ็อกซ์

  • เมื่อพยายามเข้าถึงไฟล์สำคัญ ระบบจะ บล็อกในระดับเคอร์เนล
    • เมื่อรัน safehouse cat ~/.ssh/id_ed25519 จะเกิดข้อผิดพลาด “Operation not permitted”
    • จะมองไม่เห็นไดเรกทอรีของโปรเจ็กต์อื่น (~/other-project)
    • แต่ยังเข้าถึงไดเรกทอรีของโปรเจ็กต์ปัจจุบันได้ตามปกติ

การทำงานอัตโนมัติและการสร้างโปรไฟล์

  • สามารถเพิ่ม ฟังก์ชันเชลล์ เพื่อให้เอเจนต์ทั้งหมดรันภายใน Safehouse เป็นค่าเริ่มต้นได้
    • ตัวอย่าง: กำหนดฟังก์ชัน safe() ใน .zshrc หรือ .bashrc แล้วทำให้คำสั่ง claude, codex, amp, gemini ถูกแซนด์บ็อกซ์โดยอัตโนมัติ
    • หากต้องการรันโดยไม่ผ่านแซนด์บ็อกซ์ ให้เรียกในรูปแบบ command claude
  • มี ฟีเจอร์สร้างโปรไฟล์ด้วย LLM
    • โมเดลอย่าง Claude, Codex, Gemini จะวิเคราะห์เทมเพลตของ Safehouse แล้วสร้าง โปรไฟล์ sandbox-exec แบบสิทธิ์ต่ำสุดที่จำเป็น
    • บันทึกไปยังพาธ ~/.config/sandbox-exec.profile โดยอิงจากข้อมูลโฮมไดเรกทอรีและ toolchain
    • รวมสิทธิ์การเข้าถึงไดเรกทอรีทำงานปัจจุบันและคำสั่งลัดเฉพาะของแต่ละเอเจนต์

ความปลอดภัยและความสำคัญในการใช้งาน

  • ปกป้องไม่ให้เอเจนต์ภายในเครื่องที่ใช้ LLM ลบไฟล์หรือเปลี่ยนแปลงระบบโดยไม่ตั้งใจ
  • ใช้การควบคุมการเข้าถึงระดับเคอร์เนลของ macOS เพื่อมอบ สภาพแวดล้อมการรันที่ปลอดภัยโดยค่าเริ่มต้น
  • ใช้สคริปต์เพียงไฟล์เดียวจึง ผสานเข้ากับเวิร์กโฟลว์ของนักพัฒนาได้ง่าย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-09
ความคิดเห็นจาก Hacker News

  • ไม่คิดว่าโปรเจกต์ที่ฉันทำจะถูกเผยแพร่ออกมาเร็วขนาดนี้
    1️⃣ ฉันชอบ เอเจนต์ที่รันบนเครื่องโลคัลโดยตรง มากกว่า ไม่ใช่คอนเทนเนอร์หรือเซิร์ฟเวอร์ระยะไกล แต่เป็นการรันบนเครื่องของฉันเองที่ฉันปรับแต่งไว้อย่างละเอียด แบบนั้นอุ่นใจกว่า
    2️⃣ นี่คือ ตัวสร้างนโยบาย สำหรับ sandbox-exec โดยพฤตินัย ไม่มี dependency และไม่มี virtualization แต่ฉันใช้เวลามากในการหาสิทธิ์ขั้นต่ำที่เอเจนต์แต่ละตัวต้องใช้เพื่อทำสิ่งอย่างการอัปเดตอัตโนมัติ การผสานกับ keychain การวางรูปภาพ ฯลฯ รายละเอียดการสำรวจที่เกี่ยวข้องสรุปไว้ที่ agent-safehouse.dev/docs/agent-investigations
    3️⃣ ไม่จำเป็นต้องใช้ทั้งโปรเจกต์ก็ได้ ใช้แค่ Policy Builder อย่างเดียวก็สร้างนโยบาย sandbox-exec แล้วเอาไปใส่ใน dotfiles เพื่อใช้งานได้

    • ขอโทษที่เอามาเผยแพร่ก่อนกำหนด ฉันลองใช้หลังจากเห็นคอมเมนต์ที่คุณเคยเขียนไว้ แล้วพบว่ามันมีประสิทธิภาพมากพอที่จะควรเขียนแนะนำ
      ก่อนหน้านี้ฉันก็เคยเห็นเอกสารนโยบาย sandbox มาแล้ว แต่ครั้งนี้เป็นครั้งแรกที่เห็นมันมาในรูปแบบ แอปที่พร้อมใช้ได้ทันที
      แต่ก็ยังมีจุดไม่สะดวกอยู่บ้าง — การเข้าถึง .gitconfig, .gitignore ในโฮมไดเรกทอรีถูกจำกัด และเพราะข้อจำกัดการเข้าถึงโปรเซส ทำให้สั่ง Claude ให้รันคำสั่งอย่าง lldb หรือ pkill ไม่ได้ ถ้ามี การควบคุมสิทธิ์แบบละเอียด กว่านี้จะดีมาก
    • สงสัยว่าจะเอาไปใช้กับ openclaw ได้ไหม ถ้ารันในรูปแบบที่เข้าถึงได้จากเครื่องโลคัลก็สะดวกดี แต่ในขณะเดียวกันก็มีปัญหาเรื่องควบคุมได้ยากขึ้นด้วย
    • สงสัยว่าความแตกต่าง ที่เป็นรูปธรรมจริง ๆ ระหว่างการรันแบบโลคัลกับการรันแบบคอนเทนเนอร์คืออะไร
    • โอ้ นี่แหละสิ่งที่ฉันตามหาอยู่ พยายามปรับ microsandbox ให้เข้าที่มานาน แต่นี่ดูใช้งานได้จริงกว่ามาก
      ฉันไล่ดูทั้งเว็บไซต์และสคริปต์แล้ว ยังไม่เจอปัญหาอะไรเป็นพิเศษ มี ข้อควรระวัง ที่ยังไม่ได้เขียนไว้ในเอกสารหรือเปล่า?
    • น่าขำตรงที่ฉันสนใจโปรเจกต์แบบนี้เพราะไม่ไว้ใจ AI แต่พอจะติดตั้งกลับต้อง ดาวน์โหลดไฟล์ .sh จากเซิร์ฟเวอร์อะไรก็ไม่รู้มารัน
      ถ้ามีแบบ tarball แจกก็น่าจะดี tarball ทำให้ตรวจดูข้างในเองได้ และยังตรวจสอบได้ด้วยว่าสร้างอัตโนมัติจาก CI หรือเปล่า เลยน่าเชื่อถือกว่า

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

    • แต่เป็นไปได้ไหมว่านี่อาจเป็น ปัญหาที่แก้ไม่ได้โดยพื้นฐาน? ความสามารถใช้งานกับความปลอดภัยขัดกันเสมอ และสุดท้ายผู้คนก็มักเลือกอย่างแรก
    • การ sandbox ระดับไฟล์เป็นแค่พื้นฐาน สิ่งที่ยากจริง ๆ คือ credential และการควบคุมเครือข่าย
      ฉันใช้วิธีให้ local daemon ออก JWT อายุสั้นเพื่อไม่ให้เอเจนต์ต้องจัดการกับคีย์โดยตรง วิธีนี้เหมาะกับการเข้าถึง API มาก แต่ในระดับไฟล์ซิสเต็มก็ยังอาจสั่งเปิด EC2 instance ได้ไม่จำกัดอยู่ดี

  • ปัญหาคือการประเมินเปรียบเทียบหลาย ๆ sandbox ทำได้ยาก
    อันนี้ดูเหมือนเป็น wrapper ของ sandbox-exec และช่วงนี้ก็มี wrapper แบบนี้ออกมาเยอะ
    สิ่งที่ต้องการจริง ๆ คือ เอกสารยืนยันความน่าเชื่อถือและการทดสอบอัตโนมัติ sandbox ส่วนใหญ่มักมีเอกสารไม่พอ
    ถ้าจะให้เชื่อถือได้ ก็ต้องมีทั้งเอกสารรายละเอียดและหลักฐานการทำงาน

    • นั่นจึงเป็นเหตุผลที่ฉันทำมันด้วย Bash — เพื่อหลีกเลี่ยง ไบนารีแบบทึบแสง
      โปรไฟล์ sandbox-exec สำหรับเอเจนต์แต่ละตัวถูกแยกไว้ใน โฟลเดอร์โปรไฟล์บน GitHub และตรวจสอบได้ง่าย
      ตอนนี้ก็กำลังทำ การทดสอบ E2E กับเอเจนต์จริงอยู่
      ถึงไม่ใช้ Safehouse wrapper ก็ยังสามารถใช้ Policy Builder เพื่อสร้างนโยบายสิทธิ์ขั้นต่ำได้โดยตรง
      และยังมี ไฟล์คำแนะนำ สำหรับให้ LLM เขียนโปรไฟล์ sandbox ด้วย

  • นี่คือ wrapper script ของ sandbox-exec มี preset ที่จัดไว้ดีล่วงหน้าเยอะมาก เลยถือว่าดี
    90% ของ sandbox-exec คือการกำหนดขอบเขตให้ถูกต้อง และอีก 90% คือการทำความเข้าใจมัน
    แต่ถ้าสามารถทำ sandbox แบบ overlay หรือ copy-on-write ได้ก็น่าจะดี ฉันไม่ได้ต้องการแก้ .bashrc จริง ๆ แค่แก้สภาพแวดล้อมชั่วคราวก็พอ

    • ที่ใช้ Bash ก็เพราะเชื่อถือไบนารี Go หรือ Rust ได้ยาก
      overlay FS บน macOS ทำได้ยาก แต่ฉันแก้ด้วยการจำกัดให้อ่านนอก CWD ได้แบบ read-only แล้วบังคับให้ทำงานในโฟลเดอร์ชั่วคราวแทน
    • ฉันกำลังทำ OSS ชื่อ Amika เป็นเครื่องมือสำหรับเปิดใช้ sandbox แบบโลคัลและรีโมตได้อย่างรวดเร็ว และผสานกับ Git ได้ดี
      สามารถเปิดเผยพอร์ต TCP/UDP และแชร์กับเพื่อนร่วมทีมได้ด้วย ดูได้ที่ GitHub ลิงก์
    • ฉันทำโปรเจกต์ชื่อ Treebeard เป็นโครงสร้างที่รวม sandbox-exec, worktree และ COW filesystem เข้าด้วยกัน
      ทำให้เข้าถึงไฟล์ที่ถูก git-ignore ได้อย่างปลอดภัย ลิงก์ Treebeard
    • แต่ sandbox-exec นี่ deprecated ไปแล้วไม่ใช่หรือ?

  • ข้อเท็จจริงที่น่าสนใจ: sandbox-exec อยู่ในสถานะ deprecated อย่างเป็นทางการตั้งแต่ macOS Sierra (2016)
    ถึงอย่างนั้นมันก็ยังใช้งานได้มีประโยชน์อยู่ Apple App Sandbox ไม่เหมาะกับกฎแบบกำหนดเองลักษณะนี้
    หวังว่า Apple จะไม่ถอดทิ้งไปทั้งหมด

    • จริง ๆ แล้วดูเหมือนมันจะ deprecated มาตั้งแต่แรกเกิดด้วยซ้ำ เอกสารของภาษาโปรไฟล์ แทบไม่มีเลย และส่วนใหญ่เข้าใจกันจากการ reverse engineer

  • ยังมีโปรเจกต์ชื่อ Sandvault ด้วย เป็นวิธีที่รวม sandbox-exec เข้ากับระบบผู้ใช้ Unix
    ให้แต่ละเอเจนต์มีบัญชีผู้ใช้ไม่สิทธิพิเศษแยกกัน แล้วโต้ตอบกันผ่าน sudo, SSH และไดเรกทอรีที่แชร์
    Sandvault GitHub ลิงก์

  • ฉันทำแอป GUI สำหรับ macOS เพื่อให้จัดการ sandbox-exec แบบภาพได้
    มีทั้ง การกรองเครือข่ายตามโดเมน และ ฟีเจอร์ตรวจจับความลับ
    multitui.com

  • แชร์วิธีใช้คำสั่ง container ของ Apple เพื่อรัน Claude code ภายใน Apple container
    ตั้งค่าสภาพแวดล้อมตามลำดับ container system start → container run → container exec แล้วติดตั้ง Node.js กับ Claude

    • ขอบคุณมาก! เพิ่งรู้เป็นครั้งแรกว่าใน Homebrew ก็มี apple/container ด้วย

  • สงสัยว่าทำไมถึงคิดว่าการรันเอเจนต์บนเครื่องโลคัลดีกว่า
    สำหรับคนส่วนใหญ่ ฉันรู้สึกว่า การรันระยะไกล น่าจะมีประสิทธิภาพกว่า — เพราะไม่จำเป็นต้องเปิดทิ้งไว้ตลอดเวลา

    • ข้อดีของการรันแบบโลคัลคือ การควบคุมและความเป็นเจ้าของ คล้ายกับเหตุผลที่คนรัน Plex หรือเว็บเซิร์ฟเวอร์เอง
      แถมยังหลีกเลี่ยงค่าสมาชิกรายเดือนได้ด้วย
    • ฉันทำ pixels ขึ้นมาเพื่อแก้ปัญหานี้ มันรันบน TrueNAS SCALE หรือ Incus ได้
      ตอนนี้กำลังเสริมความปลอดภัยอยู่ และก็เพียงพอสำหรับเวิร์กโฟลว์ AI แล้ว
      pixels GitHub ลิงก์

  • สงสัยว่า “clunker” เป็นสแลงใหม่ของ “clanker” หรือเปล่า เพื่อนของเพื่อนฉันชื่อ Roku ถามมา
    ตอนนี้กำลังปวดหัวกับปัญหา sandboxing อยู่พอดี จังหวะเหมาะเลย

    • พิมพ์ผิดน่ะ เพิ่งแก้แล้ว