jai - Công cụ cô lập đơn giản cho AI agent

 (jai.scs.stanford.edu)
3 điểm bởi GN⁺ 24 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Công cụ nhẹ cho phép chạy cô lập AI agent trong môi trường Linux, cung cấp ranh giới thực thi an toàn chỉ với một lệnh mà không cần cấu hình container phức tạp
  • Nhu cầu về môi trường thực thi an toàn ngày càng được nhấn mạnh khi liên tiếp xuất hiện các trường hợp công cụ AI truy cập hệ thống tệp thực và xóa hoặc làm hỏng dữ liệu
  • Bảo vệ thư mục home bằng copy-on-write overlay và tách riêng /tmp·/var/tmp để ngăn thay đổi lên tệp gốc
  • Cung cấp ba chế độ cô lập là Casual, Strict và Bare để có thể chọn mức độ bảo mật và phạm vi truy cập
  • Là dự án mã nguồn mở do nhóm nghiên cứu Stanford phát triển, cung cấp biện pháp bảo vệ thực tiễn để sử dụng công cụ AI an toàn hơn

jai - công cụ nhẹ để cô lập AI agent

  • jai là công cụ được thiết kế để giúp cô lập (containment) AI agent một cách dễ dàng trong môi trường Linux
    • Cung cấp ranh giới thực thi an toàn chỉ với một lệnh mà không cần cấu hình container hay VM phức tạp
    • Có thể áp dụng ngay vào workflow hiện có như hỗ trợ lập trình hoặc chạy script

  • Các trường hợp sự cố thực tế

    • Nhiều người dùng đã báo cáo thiệt hại mất tệp và xóa thư mục khi sử dụng công cụ AI
      • Nick Davidov cho biết 15 năm ảnh gia đình đã bị xóa bằng lệnh terminal
      • Claude Code của Anthropic đã xóa thư mục home, khiến các dự án phát triển bị mất
      • Cursor được báo cáo đã làm trống working tree, khiến “mọi thứ biến mất”
      • Một người dùng Reddit nói rằng Antigravity đã xóa toàn bộ ổ D
      • Một người dùng Cursor khác báo cáo đã bị xóa 100GB dữ liệu
    • Các trường hợp này cho thấy lỗ hổng an toàn phát sinh khi cho phép công cụ AI truy cập vào tài khoản thực

  • Tính năng cốt lõi của jai

    • Tự động thiết lập ranh giới giữa tài khoản thực thi và thư mục home
      • Thư mục làm việc vẫn giữ đầy đủ quyền đọc/ghi
      • Thư mục home được bảo vệ bằng copy-on-write overlay, nên tệp gốc không bị thay đổi
      • /tmp và /var/tmp được tách thành không gian độc lập, các tệp còn lại bị giới hạn chỉ đọc
    • Có thể chạy cô lập chỉ bằng cách thêm jai trước câu lệnh
      • Ví dụ: jai codex, jai claude, hoặc chỉ jai để mở shell
    • Có thể sử dụng ngay mà không cần Dockerfile hay quá trình build image
      • Không cần thiết lập các cờ bwrap phức tạp hay viết script

  • Lựa chọn chế độ cô lập

    • Cung cấp ba chế độ Casual / Strict / Bare
      • Casual: bảo vệ thư mục home bằng copy-on-write, có thể đọc phần lớn tệp
      • Strict: chạy bằng người dùng jai riêng, thư mục home ở trạng thái trống để cung cấp mức cô lập mạnh
      • Bare: thư mục home ở trạng thái trống nhưng vẫn giữ nguyên UID của người dùng
    • Mỗi chế độ khác nhau về tính bảo mật (confidentiality), tính toàn vẹn (integrity) và khả năng hỗ trợ NFS
      • Chế độ Strict cung cấp mức cô lập mạnh nhất nhưng không hỗ trợ home trên NFS

  • So sánh với các công cụ thay thế

    • Docker
      • Phù hợp để tái tạo môi trường dựa trên image, nhưng quá nặng cho sandbox tạm thời với công cụ trên host
      • Không có tính năng overlay cho thư mục home
    • bubblewrap
      • Là sandbox namespace mạnh mẽ nhưng phải tự chỉ định cấu hình filesystem
      • jai loại bỏ sự phức tạp này
    • chroot
      • Không phải là biện pháp cô lập bảo mật, thiếu khả năng mount, PID namespace và tách quyền, nên ngay cả trên Linux cũng không được khuyến nghị cho mục đích sandbox

  • Giới hạn bảo mật

    • jai không đảm bảo bảo mật tuyệt đối
      • Là một “casual sandbox”, giúp giảm phạm vi thiệt hại nhưng không chặn được mọi cuộc tấn công
      • Chế độ Casual bảo vệ tính bí mật còn yếu, và chế độ Strict cũng khác với mức cô lập của container hay VM
      • Trong môi trường đa tenant hoặc tình huống rủi ro cao, nên dùng container hoặc máy ảo

  • Bối cảnh dự án

    • Được đồng phát triển bởi nhóm nghiên cứu Stanford Secure Computer Systems(SCS) và Future of Digital Currency Initiative(FDCI)
    • Được cung cấp dưới dạng phần mềm mã nguồn mở miễn phí, hỗ trợ người dùng sử dụng AI an toàn hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 24 ngày trước
Ý kiến trên Hacker News

  • Chỉ cần thêm cấu hình sau vào .claude/settings.json

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

    Nếu muốn cho phép truy cập thư mục bên ngoài thì chỉnh phần allowRead
    Đây là tùy chọn sandbox mới được thêm vào 10 ngày trước

    • Tôi từng thấy claude nhầm thư mục hiện tại hoặc chạy lệnh như rm -rf *
      May là chưa xảy ra cùng lúc, nhưng chỉ nghĩ tới thôi cũng đã rợn người
      Ý tưởng sandbox thì hay, nhưng phải được ép buộc ở tầng thấp thì mới hiệu quả
      Bản thân claude là một chương trình khổng lồ do AI tạo ra, nên việc thêm một lớp bảo mật dưới 3000 dòng do con người tự viết có thể là một biện pháp phòng thủ đáng kể
    • Các phiên bản tương lai của claude-code có thể lặng lẽ đổi tên hoặc bỏ hẳn cấu hình này
      Vì vậy mọi người có thể thích dùng phần mềm sandbox riêng biệt hơn
    • Có người chia sẻ một ví dụ cấu hình đùa vui kiểu cho dùng GPU nhưng chỉ chặn việc xóa /
      Đây là cấu hình cho phép truy cập thiết bị /dev/nvidia*, chấp nhận rủi ro rò rỉ dữ liệu như một thiết lập mang tính châm biếm
    • Đã có những công cụ bảo mật truyền thống được kiểm chứng qua hàng chục năm
      Nếu chạy claude bằng một người dùng có quyền hạn chế, thì việc cô lập cũng sẽ tự động được kế thừa sang các tiến trình con
    • Tính năng sandbox đã không hoạt động đúng trên Linux (Arch) và macOS (Tahoe)
      Đã có issue liên quan được mở
      bubblewrap và seatbelt tự chạy riêng thì ổn, nhưng khi chạy qua claude-code thì trông như bị vô hiệu hóa

  • Thật đáng ngạc nhiên khi mọi người cài AI agent lên máy tính cá nhân dễ dàng đến vậy
    Chúng ta đã bảo vệ an ninh hệ thống suốt hàng chục năm, vậy mà giờ lại trao toàn quyền cho phần mềm khó đoán trước

    • Trước đây, khi công cụ build tự động kéo dependency về, người ta cũng đã phớt lờ cảnh báo, và giờ thì tấn công chuỗi cung ứng cứ lặp lại
      Sự tiện lợi ngắn hạn đang được ưu tiên hơn bảo mật dài hạn
    • Thực ra, những người chấp nhận kiểu rủi ro này và những người coi trọng bảo mật là hai nhóm khác nhau
    • Trong môi trường công ty thì quyền truy cập vốn đã bị hạn chế, nên đây chủ yếu là vấn đề nhạy cảm hơn trên PC cá nhân
      Trên VM phát triển từ xa của tôi chỉ có dữ liệu mà Claude xem cũng không sao
    • Những ngày đầu của Docker cũng từng có không khí kiểu “cứ tải image về là xong!”
      Nhưng ngành này nhanh chóng nhận ra rủi ro bảo mật và đã phản ứng

  • Chỉ cần tách quyền Unix đơn giản là cũng đủ
    Tạo hai tài khoản người dùng, rồi chỉ gom các thư mục muốn chia sẻ với AI vào cùng một group là được
    Xem bài blog liên quan

  • Trang chủ ghi “đừng tin tưởng mù quáng”, nhưng cách cài là build thủ công thay vì curl | bash

    • Tự giải nén file tar và cài bằng makepkg -i an toàn hơn nhiều
      PKGFILE chỉ ngắn khoảng 30 dòng, còn hàm build cũng chỉ có 7 dòng
      Trong khi đó các script như rustup (910 dòng), claude (158 dòng), opencode (460 dòng) phức tạp hơn nhiều
    • Ngược lại, nối curl | tar | makepkg thành một dòng lại là cách không đáng tin cậy

  • Dự án này được thiết kế tốt và có vẻ an toàn hơn một chút, lại tiện hơn cách tôi đang làm
    Tôi tạo một tài khoản người dùng riêng để cô lập agent
    Tuy vậy đôi khi quyền bị rối nên tôi phải sửa bằng script
    Cuối cùng thì cách chắc chắn nhất vẫn là đưa hẳn một chiếc laptop riêng
    Không gì an toàn bằng phần cứng tách biệt vật lý

    • Nhưng nếu cần giao tiếp với dịch vụ bên ngoài thì vẫn phải cấp API key, và key đó có nguy cơ bị lộ
      Agent có khả năng ngang mức kiểm thử xâm nhập bảo mật, nên chỉ tách người dùng đơn thuần thôi vẫn thấy chưa yên tâm
    • Hiện tại tôi cũng đang dùng cách tách người dùng
      Nếu dùng container thì agent lại dễ bị rối khi tự tạo container cho chính nó

  • Trang web trông như “vibe-coded” nên có vẻ chất lượng thấp, nhưng công cụ thực tế lại do một giáo sư Stanford tự triển khai
    Xem liên kết FAQ

    • Chính tác giả đây: tôi không giỏi web design, nhưng là chuyên gia hệ điều hành
      Tôi đã sửa nội dung tài liệu cho chính xác nên có thể tin được
      Cũng hơi mỉa mai là tôi giữ nguyên phần website do AI làm ra
    • Tác giả là David Mazieres, người đã nghiên cứu filesystem ở mức người dùng từ đầu những năm 2000
      Ông đang dẫn dắt nhóm Stanford Secure Computer Systems
    • jai là công cụ rủi ro cao, nhưng website thì đơn giản nên dù có vibe-coded cũng không sao
    • Dù vậy cá nhân tôi vẫn nghĩ một trang HTML gọn gàng sẽ tốt hơn

  • Điều đáng lo là nếu agent có quyền ghi vào thư mục dự án thì có thể tạo ra khai thác dai dẳng
    Các file như .pyc, .venv, .git/hooks có thể bị dùng để chạy bên ngoài sandbox
    Cuộc trò chuyện ChatGPT cũng xác nhận kiểu lỗ hổng này
    Vì vậy cách an toàn nhất là truyền file dựa trên git patch
    Nên để các file được sửa trong sandbox chỉ được xuất ra ngoài nếu chúng thuộc những mục đã commit trong git

    • Sẽ hay hơn nếu có thêm tùy chọn đặt thư mục .git/ ở chế độ chỉ đọc
      Có thể dùng jai -D để biến CWD thành overlay, nhưng việc hợp nhất thay đổi lại khá phiền
    • Tôi thì chạy code chỉ bên trong sandbox (cấp VM)
      Agent làm việc trên một nhánh git worktree riêng, và chỉ merge sau khi review
      Cách này giúp duy trì luồng bảo mật dựa trên review
    • Tuyệt đối không được cho phép git hook

  • Một cách thay thế đơn giản là chạy agent qua ssh trong tài khoản người dùng riêng
    Bind mount thư mục dự án để kiểm soát quyền truy cập
    Cách này rất hợp với tính năng ssh remote của VSCode

    • Tôi cũng đã dùng tài khoản chuyên dụng suốt 6 tháng nay, chỉ cần quản lý các thư mục được phép truy cập
      Đây là cách cô lập hiệu quả và đơn giản hơn nhiều so với các hệ thống bảo mật phức tạp

  • Trên thực tế còn nhiều vấn đề tinh vi hơn cả rm -rf
    Có lần claude-code tạo thư mục /public/blog/ để lưu SVG, khiến routing của Apache bị hỏng
    Không phải lỗi xóa dữ liệu hay phân quyền, nhưng vì hành vi ngoài ý muốn mà blog trả về 404
    jai có thể ngăn những sai sót lớn kiểu này, nhưng các lỗi tinh vi như vậy thì vẫn khó

  • Dự án rất tuyệt nhưng tiêu đề thì chưa ổn
    Tôi thích cấu trúc cho phép toàn quyền trong thư mục hiện tại, chỉ đọc ở các nơi khác, còn thư mục home thì dùng copy-on-write
    Kiểu tiếp cận này nên trở thành mô hình bảo mật mặc định cho AI agent

    • Vì trên site không có tiêu đề, cái tên kiểu “jai - filesystem containment for AI agents” có vẻ hợp hơn