jai - เครื่องมือแยกการทำงานอย่างง่ายสำหรับ AI Agent

 (jai.scs.stanford.edu)
3 คะแนน โดย GN⁺ 2026-03-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือขนาดเบาสำหรับ รัน AI agent แบบแยกสภาพแวดล้อม บน Linux โดยให้ขอบเขตการรันที่ปลอดภัยด้วยคำสั่งเดียวโดยไม่ต้องตั้งค่าคอนเทนเนอร์ที่ซับซ้อน
  • มีกรณีที่เครื่องมือ AI เข้าถึงไฟล์ระบบจริงแล้ว ลบหรือทำให้ข้อมูลเสียหาย เกิดขึ้นต่อเนื่อง ทำให้ความจำเป็นของสภาพแวดล้อมการรันที่ปลอดภัยยิ่งชัดเจนขึ้น
  • ปกป้องโฮมไดเรกทอรีด้วย copy-on-write overlay และแยก /tmp·/var/tmp ออกต่างหากเพื่อป้องกันการเปลี่ยนแปลงไฟล์ต้นฉบับ
  • มี โหมดการแยก 3 แบบคือ Casual, Strict และ Bare ให้เลือกตามระดับความปลอดภัยและขอบเขตการเข้าถึง
  • เป็น โครงการโอเพนซอร์ส ที่พัฒนาโดยทีมวิจัย Stanford เพื่อเป็นเครื่องมือป้องกันเชิงปฏิบัติสำหรับการใช้งาน AI tools ได้อย่างปลอดภัยยิ่งขึ้น

jai เครื่องมือขนาดเบาสำหรับการแยก AI agent

  • jai เป็นเครื่องมือที่ออกแบบมาเพื่อให้สามารถ แยกการทำงาน (containment) ของ AI agent บน Linux ได้อย่างง่ายดาย
    • ให้ขอบเขตการรันที่ปลอดภัยด้วยคำสั่งเดียว โดยไม่ต้องตั้งค่าคอนเทนเนอร์หรือ VM ที่ซับซ้อน
    • นำไปใช้กับเวิร์กโฟลว์เดิมได้ทันที เช่น งานช่วยเขียนโค้ดหรือการรันสคริปต์

  • กรณีปัญหาที่เกิดขึ้นจริง

    • ผู้ใช้หลายรายรายงานความเสียหายจาก ไฟล์สูญหายและไดเรกทอรีถูกลบ ระหว่างใช้งานเครื่องมือ AI
      • Nick Davidov รายงานว่ารูปครอบครัวตลอด 15 ปีถูกลบด้วยคำสั่งในเทอร์มินัล
      • Claude Code ของ Anthropic ลบโฮมไดเรกทอรีจนทำให้โปรเจกต์พัฒนาสูญหาย
      • มีรายงานว่า Cursor ล้าง work tree จน “ทุกอย่างหายไปหมด”
      • ผู้ใช้ Reddit รายหนึ่งกล่าวว่า Antigravity ลบไดรฟ์ D ทั้งหมด
      • ผู้ใช้ Cursor อีกรายรายงานว่าไฟล์ 100GB ถูกลบ
    • กรณีเหล่านี้แสดงให้เห็นถึง ช่องโหว่ด้านความปลอดภัย เมื่ออนุญาตให้เครื่องมือ AI เข้าถึงบัญชีผู้ใช้จริง

  • ความสามารถหลักของ jai

    • ตั้งค่า ขอบเขตระหว่างบัญชีที่ใช้รันกับโฮมไดเรกทอรี ให้อัตโนมัติ
      • ไดเรกทอรีทำงานยังคงมีสิทธิ์อ่าน/เขียนเต็มรูปแบบ
      • โฮมไดเรกทอรีได้รับการปกป้องด้วย copy-on-write overlay ทำให้ไฟล์ต้นฉบับไม่ถูกแก้ไข
      • /tmp และ /var/tmp ถูกแยกเป็นพื้นที่อิสระ ส่วนไฟล์อื่นถูกจำกัดให้อ่านได้อย่างเดียว
    • สามารถรันแบบแยกได้เพียงเติม jai ไว้หน้าคำสั่ง
      • ตัวอย่าง: jai codex, jai claude หรือรันเชลล์ด้วย jai เฉยๆ
    • ใช้งานได้ทันทีโดยไม่ต้องมี Dockerfile หรือขั้นตอนสร้างอิมเมจ
      • ไม่จำเป็นต้องตั้งค่าแฟลก bwrap ที่ซับซ้อนหรือเขียนสคริปต์เพิ่มเติม

  • การเลือกโหมดการแยก

    • มี 3 โหมดคือ Casual / Strict / Bare
      • Casual: ปกป้องโฮมไดเรกทอรีด้วย copy-on-write และอ่านไฟล์ส่วนใหญ่ได้
      • Strict: รันด้วยผู้ใช้ jai แยกต่างหาก พร้อมโฮมไดเรกทอรีว่าง เพื่อการแยกที่เข้มงวดกว่า
      • Bare: โฮมไดเรกทอรีว่าง แต่ยังคง UID ของผู้ใช้เดิมไว้
    • แต่ละโหมดแตกต่างกันในด้าน ความลับของข้อมูล (confidentiality), ความถูกต้องสมบูรณ์ (integrity) และ การรองรับ NFS
      • โหมด Strict ให้การแยกที่แข็งแรงที่สุด แต่ไม่รองรับ NFS home

  • เปรียบเทียบกับเครื่องมือทางเลือก

    • Docker
      • เหมาะกับการทำสภาพแวดล้อมแบบ image-based ให้ทำซ้ำได้ แต่หนักเกินไปสำหรับ sandbox ชั่วคราวของเครื่องมือบนโฮสต์
      • ไม่มีความสามารถด้านโฮมไดเรกทอรีแบบ overlay
    • bubblewrap
      • เป็น namespace sandbox ที่ทรงพลัง แต่ผู้ใช้ต้องกำหนดโครงสร้างไฟล์ระบบเอง
      • jai ช่วยตัดความซับซ้อนนี้ออก
    • chroot
      • ไม่ใช่มาตรการแยกเพื่อความปลอดภัย และไม่มีฟีเจอร์อย่าง mount, PID namespace หรือการแยกสิทธิ์ จึงไม่แนะนำให้ใช้ทำ sandbox แม้บน Linux

  • ข้อจำกัดด้านความปลอดภัย

    • jai ไม่ได้รับประกันความปลอดภัยแบบสมบูรณ์
      • ในฐานะ “casual sandbox” มันช่วยลดขอบเขตความเสียหาย แต่ไม่ได้ป้องกันการโจมตีทั้งหมด
      • โหมด Casual ปกป้องความลับของข้อมูลได้ไม่มาก และโหมด Strict ก็ยังแตกต่างจากการแยกระดับคอนเทนเนอร์หรือ VM
      • ในสภาพแวดล้อมหลายผู้เช่าหรือสถานการณ์ความเสี่ยงสูง แนะนำให้ใช้คอนเทนเนอร์หรือเครื่องเสมือน

  • เบื้องหลังโครงการ

    • พัฒนาร่วมกันโดยกลุ่มวิจัย Stanford Secure Computer Systems (SCS) และ Future of Digital Currency Initiative (FDCI)
    • ให้ใช้งานในรูปแบบ ซอฟต์แวร์โอเพนซอร์สฟรี และช่วยให้ผู้ใช้สามารถ ใช้งาน AI ได้อย่างปลอดภัยยิ่งขึ้น

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

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

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

  • แค่เพิ่มการตั้งค่าต่อไปนี้ใน .claude/settings.json

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    ถ้าต้องการอนุญาตการเข้าถึงไดเรกทอรีภายนอก ก็แก้ตรง allowRead ได้
    ฟีเจอร์นี้เป็น ตัวเลือก sandbox ใหม่ ที่เพิ่งเพิ่มเข้ามาเมื่อ 10 วันที่แล้ว

    • เคยเห็น claude สับสนเรื่องไดเรกทอรีปัจจุบัน หรือรันคำสั่งอย่าง rm -rf *
      โชคดีที่มันไม่ได้เกิดขึ้นพร้อมกัน แต่แค่นึกภาพก็ขนลุกแล้ว
      ไอเดียเรื่อง sandbox นั้นดี แต่จะได้ผลต้อง ถูกบังคับใช้ในระดับ low-level
      ตัว claude เองก็เป็นโปรแกรมขนาดใหญ่ที่ AI สร้างขึ้นมา ดังนั้นการเพิ่มชั้นความปลอดภัยที่มนุษย์เขียนเองไม่ถึง 3000 บรรทัด อาจเป็นแนวป้องกันที่มีความหมายได้
    • เวอร์ชันถัด ๆ ไปของ claude-code อาจเปลี่ยนชื่อการตั้งค่านี้หรือเอาออกไปแบบเงียบ ๆ ก็ได้
      เพราะงั้นคนจึงอาจชอบ ซอฟต์แวร์ sandbox แยกต่างหาก มากกว่า
    • มีการแชร์ตัวอย่างการตั้งค่าแบบติดตลกว่าให้ใช้ GPU ได้ แต่แค่กันไม่ให้ลบ /
      เป็นคอนฟิกที่อนุญาตให้เข้าถึงอุปกรณ์ /dev/nvidia* โดยยอมรับความเสี่ยงเรื่องข้อมูลรั่วไหล เป็น การตั้งค่าเชิงเสียดสี
    • มี เครื่องมือความปลอดภัยแบบดั้งเดิม ที่ผ่านการพิสูจน์มาหลายสิบปีอยู่แล้ว
      ถ้ารัน claude ด้วยผู้ใช้ที่มีสิทธิ์จำกัด การแยกก็จะถูกสืบทอดไปยัง subprocess โดยอัตโนมัติ
    • ฟีเจอร์ sandbox ทำงานไม่ถูกต้องบน Linux(Arch) และ macOS(Tahoe)
      มี issue ที่เกี่ยวข้อง เปิดไว้แล้ว
      bubblewrap กับ seatbelt ทำงานได้ดีเมื่อใช้งานเดี่ยว ๆ แต่พอรันผ่าน claude-code กลับดูเหมือนถูกปิดใช้งาน

  • น่าแปลกใจที่ผู้คนติดตั้ง AI agent ลงบนคอมส่วนตัวกันได้ง่ายขนาดนี้
    เราปกป้องความปลอดภัยของระบบกันมาหลายสิบปี แต่จู่ ๆ ก็เหมือนมอบสิทธิ์ทั้งหมดให้ซอฟต์แวร์ที่คาดเดาไม่ได้

    • สมัยก่อนตอนเครื่องมือ build เริ่มดึง dependency มาให้อัตโนมัติ ผู้คนก็เมินคำเตือนกันมาแล้ว และตอนนี้ supply chain attack ก็เกิดซ้ำ ๆ
      ความสะดวกในระยะสั้นถูกให้ความสำคัญมากกว่าความปลอดภัยระยะยาว
    • จริง ๆ แล้วคนที่ยอมรับความเสี่ยงแบบนี้กับคนที่ให้ความสำคัญกับความปลอดภัยคือ คนละกลุ่มกัน
    • ในสภาพแวดล้อมบริษัท การเข้าถึงมักถูกจำกัดอยู่แล้ว ดังนั้นจึงเป็นประเด็นที่อ่อนไหวกว่าบนพีซีส่วนตัว
      บน remote development VM ของฉันมีแต่ข้อมูลที่ Claude เห็นได้ก็ไม่เป็นไร
    • ตอน Docker ช่วงแรก ๆ ก็มีบรรยากาศแบบ “ก็แค่ดาวน์โหลด image มาใช้สิ!”
      แต่ไม่นานทั้งอุตสาหกรรมก็เริ่มตระหนักถึง ความเสี่ยงด้านความปลอดภัย และรับมือกับมัน

  • แค่ใช้ การแยกสิทธิ์แบบ Unix ธรรมดาก็เพียงพอแล้ว
    มีบัญชีผู้ใช้สองบัญชี แล้วจัดกลุ่มเฉพาะโฟลเดอร์ที่จะแชร์กับ AI ก็พอ
    ดู บทความบล็อกที่เกี่ยวข้อง

  • หน้าเว็บเขียนไว้ว่า “หยุดเชื่อแบบมืดบอด” แต่ขั้นตอนติดตั้งเป็นการ build เองแทน curl | bash

    • แตกไฟล์ tar เองแล้วติดตั้งด้วย makepkg -i จะปลอดภัยกว่ามาก
      PKGFILE สั้นแค่ราว 30 บรรทัด และฟังก์ชัน build ก็มีเพียง 7 บรรทัด
      ตรงกันข้าม สคริปต์อย่าง rustup(910 บรรทัด), claude(158 บรรทัด), opencode(460 บรรทัด) ซับซ้อนกว่ามาก
    • แต่ถ้าเชื่อม curl | tar | makepkg เป็นบรรทัดเดียว แบบนั้นก็เป็น วิธีที่ไม่น่าเชื่อถือ

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

    • แต่ถ้าจะให้มันคุยกับบริการภายนอก ก็ต้องให้ API key ด้วย ซึ่งเสี่ยงที่คีย์จะรั่วไหล
      agent มีความสามารถระดับการทดสอบเจาะระบบด้านความปลอดภัย ดังนั้นแค่แยกผู้ใช้อย่างเดียวก็ยังน่ากังวล
    • ตอนนี้ฉันก็ยังใช้วิธีแยกผู้ใช้อยู่
      ถ้าใช้ container agent จะสับสนเวลาไปสร้าง container เอง

  • เว็บดูเหมือน “vibe-coded” เลยทำให้รู้สึกว่าคุณภาพต่ำ แต่ตัวเครื่องมือจริง ๆ เป็นสิ่งที่ ศาสตราจารย์ Stanford ลงมือทำเอง
    ดู ลิงก์ FAQ

    • ในฐานะผู้เขียน ขอพูดเองเลยว่าฉันออกแบบเว็บไม่เก่ง แต่เป็น ผู้เชี่ยวชาญด้านระบบปฏิบัติการ
      ฉันแก้เนื้อหาเอกสารให้ถูกต้องแล้ว จึงเชื่อถือได้
      ส่วนเว็บไซต์ปล่อยให้ AI ทำไว้แบบนั้น จึงค่อนข้างย้อนแย้งอยู่เหมือนกัน
    • ผู้เขียนคือ David Mazieres คนที่ทำวิจัยระบบไฟล์ระดับ user-space มาตั้งแต่ต้นยุค 2000
      และเป็นผู้นำกลุ่ม Stanford Secure Computer Systems
    • jai เป็นเครื่องมือความเสี่ยงสูง แต่ตัวเว็บไซต์เรียบง่าย ดังนั้นถึงจะ vibe-coded ก็ยังพอรับได้
    • ถึงอย่างนั้นโดยส่วนตัวก็ยังคิดว่า หน้า HTML เรียบง่าย ดีกว่า

  • สิ่งที่น่ากังวลคือ ถ้า agent มีสิทธิ์เขียนใน project directory ก็อาจทำ persistent exploit ได้
    มันอาจรันนอก sandbox ผ่านไฟล์อย่าง .pyc, .venv, .git/hooks
    ใน บทสนทนา ChatGPT ก็ยืนยันช่องโหว่แบบนี้เช่นกัน
    เพราะงั้นวิธีที่ปลอดภัยที่สุดคือ การส่งไฟล์แบบอิง git patch
    ควรให้ไฟล์ที่แก้ใน sandbox ถูกส่งออกไปภายนอกได้เฉพาะรายการที่ commit ใน git แล้วเท่านั้น

    • น่าจะดีถ้ามีตัวเลือกทำให้ไดเรกทอรี .git/ เป็น read-only
      แม้จะทำ CWD เป็น overlay ได้ด้วย jai -D แต่การรวมการเปลี่ยนแปลงกลับเข้ามาทำได้ยุ่งยาก
    • ฉันรันโค้ดเฉพาะภายใน sandbox (ระดับ VM) เท่านั้น
      agent จะทำงานใน git worktree branch แยกต่างหาก และจะ merge หลัง review เท่านั้น
      แบบนี้จะรักษา กระบวนการความปลอดภัยแบบ review-based เอาไว้ได้
    • อย่าอนุญาต git hook เด็ดขาด

  • อีกทางเลือกง่าย ๆ คือรัน agent ผ่าน ssh บน บัญชีผู้ใช้แยกต่างหาก
    แล้ว bind mount project directory เพื่อควบคุมการเข้าถึง
    เข้ากันได้ดีกับฟีเจอร์ ssh remote ของ VSCode

    • ฉันเองก็ใช้บัญชีเฉพาะมา 6 เดือนแล้ว แค่จัดการไดเรกทอรีที่เข้าถึงได้ก็พอ
      มันง่ายกว่าระบบความปลอดภัยซับซ้อนมาก และเป็น วิธีแยกที่มีประสิทธิภาพ

  • ในความเป็นจริงมีปัญหาที่ละเอียดอ่อนกว่า rm -rf อีกมาก
    เคยมีครั้งหนึ่ง claude-code สร้างโฟลเดอร์ /public/blog/ เพื่อจะบันทึก SVG จน Apache routing พัง
    ไม่ใช่ปัญหาเรื่องการลบหรือสิทธิ์ แต่เป็น พฤติกรรมที่ไม่ได้ตั้งใจ ที่ทำให้บล็อกขึ้น 404
    jai อาจกันความผิดพลาดใหญ่ ๆ แบบนี้ได้ แต่ปัญหาละเอียดแบบนี้ก็ยังยากอยู่ดี

  • เป็นโปรเจกต์ที่ยอดเยี่ยม แต่ ชื่อเรื่องน่าเสียดาย
    ฉันชอบโครงสร้างที่ให้เข้าถึง current directory ได้ทั้งหมด, ที่อื่นเป็น read-only, และ home directory เป็นแบบ copy-on-write
    แนวทางแบบนี้ควรเป็น โมเดลความปลอดภัยพื้นฐานของ AI agent

    • ในเว็บไม่มีชื่อหัวเรื่อง จึงคิดว่าชื่ออย่าง “jai - filesystem containment for AI agents” น่าจะเหมาะกว่า