Chạy NanoClaw trong sandbox Docker

• Nhờ sự kết hợp giữa NanoClaw và Docker, giờ đây có thể chạy từng AI agent trong sandbox Docker cô lập chỉ với một lệnh duy nhất
• Mỗi agent hoạt động trong container độc lập bên trong microVM, có môi trường cô lập hoàn toàn mà không cần truy cập vào hệ thống host
• Với cấu trúc ranh giới bảo mật kép, ngay cả khi container bị thoát ra ngoài thì vẫn bị chặn ở lớp VM, giúp bảo vệ tệp, thông tin xác thực và ứng dụng trên host
• Mô hình bảo mật của NanoClaw được xây dựng theo thiết kế dựa trên giả định không tin cậy, xem agent là tác nhân có khả năng gây hại và áp dụng cấu trúc nhằm giảm thiểu thiệt hại
• Trong tương lai, dự án hướng tới mở rộng các tính năng để vận hành đội ngũ agent quy mô lớn như kiểm soát chia sẻ ngữ cảnh, agent bền vững, chính sách quyền hạn chi tiết và quy trình phê duyệt của con người

---

Tổng quan tích hợp sandbox Docker

• NanoClaw hỗ trợ chạy sandbox chỉ với một lệnh thông qua hợp tác với Docker
  • Hỗ trợ trên macOS (Apple Silicon) và Windows (WSL), Linux sẽ sớm được bổ sung
  • Script cài đặt tự động xử lý clone, thiết lập và cấu hình sandbox
• Mỗi agent chạy trong container độc lập bên trong microVM
  • Không cần phần cứng riêng hay cấu hình phức tạp
  • Mỗi container có kernel và Docker daemon riêng, đồng thời bị chặn truy cập host

Cách hoạt động

• Sandbox Docker cung cấp mức cô lập ở cấp hypervisor và có tốc độ khởi động nhanh ở mức mili giây
• NanoClaw ánh xạ rất tự nhiên lên cấu trúc này
  • Mỗi agent có filesystem, ngữ cảnh, công cụ và phiên làm việc riêng biệt
  • Ví dụ: agent bán hàng không thể truy cập tin nhắn cá nhân, còn agent hỗ trợ không thể truy cập dữ liệu CRM
• Lớp microVM tạo thành ranh giới bảo mật thứ hai
  • Ngay cả khi container escape xảy ra, hệ thống host vẫn được bảo vệ nhờ lớp chắn VM

Mô hình bảo mật: thiết kế dựa trên giả định không tin cậy

• NanoClaw được thiết kế dựa trên giả định không tin cậy AI agent
  • Tính đến các rủi ro khó lường như prompt injection và mô hình hoạt động sai
  • Môi trường agent được thiết kế để không chứa thông tin bí mật hay thông tin xác thực
• Bảo mật được cưỡng chế từ bên ngoài agent, không phụ thuộc vào việc agent có hành xử đúng hay không
• Khác với OpenClaw, NanoClaw cung cấp cô lập hoàn toàn giữa các agent
  • OpenClaw dùng chung một môi trường nên dữ liệu cá nhân và dữ liệu công việc có thể bị trộn lẫn
• Dự án nhấn mạnh nguyên tắc kỹ thuật bảo mật xem agent vừa là đối tượng cộng tác vừa là tác nhân tấn công tiềm tàng

Hướng phát triển tiếp theo

• Đưa ra nhu cầu xây dựng hạ tầng mới và lớp runtime để vận hành đội ngũ agent quy mô lớn
• NanoClaw hiện đã có thể kết nối với nhiều kênh Slack để vận hành các agent độc lập theo từng nghiệp vụ
• Bốn tính năng cốt lõi được đề xuất cho giai đoạn tiếp theo
  • Chia sẻ ngữ cảnh có kiểm soát: cho phép chia sẻ thông tin tự do trong cùng nhóm và chia sẻ có chọn lọc giữa các nhóm
  • Tạo agent bền vững: không phải sub-agent dùng một lần, mà là thành viên nhóm có ID, môi trường và dữ liệu tồn tại lâu dài
  • Chính sách quyền hạn chi tiết: kiểm soát tinh vi như chỉ cho phép đọc email, giới hạn truy cập kho lưu trữ cụ thể hoặc đặt hạn mức chi tiêu
  • Quy trình phê duyệt của con người: các tác vụ không thể hoàn tác sẽ chỉ được thực thi sau khi con người xem xét
• NanoClaw được giới thiệu như lớp runtime và orchestration tập trung vào bảo mật, còn sandbox Docker là nền tảng hạ tầng cấp doanh nghiệp
• Mục tiêu là xây dựng một stack thực thi agent đồng thời cung cấp cô lập mặc định, cộng tác có kiểm soát, cùng khả năng quan sát và quản trị ở cấp tổ chức

Tổng quan về NanoClaw

• NanoClaw là lớp runtime và orchestration bảo mật mã nguồn mở, hỗ trợ vận hành AI agent theo nhóm
• Có thể xem dự án trên GitHub và tham gia bằng cách star

[GN⁺]

Ý kiến trên Hacker News

• Trông như những chi tiết nhỏ, nhưng nếu vài quyết định thiết kế mới này lan rộng trong toàn ngành thì có thể mang lại thay đổi mang tính cách mạng
  Như Karpathy đã nói, điểm cốt lõi là cung cấp một đặc tả kỹ năng (skill spec) về “cách viết tích hợp”, thay vì tự triển khai trực tiếp các tích hợp như Slack hay Discord
  Có thể gọi đây là “Claude native development”; dường như hệ sinh thái sẽ chuyển từ framework kiểu “batteries-included” sang cách làm “fork and customize”
  Tuy vậy, vẫn còn nhiều vấn đề phải giải quyết, như làm sao phân phối các đặc tả cho kiểm thử, xác minh và bảo mật
  Tôi cũng tự hỏi liệu sự thay đổi như vậy có thể diễn ra ở cấp độ OS không. Nếu mỗi instance đều có hệ miễn dịch mạnh, có lẽ nó sẽ trở thành một hệ sinh thái dị thể chống chịu tấn công tốt hơn

  • Mỗi người dùng đều phải lặp lại cùng một công việc nên có vẻ hiệu quả sẽ giảm. Tôi nghĩ triển khai một lần rồi chia sẻ cho mọi người vẫn tốt hơn
  • Điểm mạnh của mã nguồn mở là quy trình cộng tác và kiểm chứng. LLM lúc đầu tạo ra nhiều lỗi, nhưng con người cũng vậy. Tôi thấy tùy biến trên một nền tảng đã được kiểm chứng sẽ tốt hơn
  • Tôi cũng nghĩ có thể sẽ xuất hiện một thế giới nơi người ta triển khai tính năng bằng cách trao đổi các tệp đặc tả Markdown thay vì mã

• Khi bàn về công cụ bảo mật hay sandboxing thì nhất định phải nêu rõ mô hình đe dọa (threat model)
  Điểm nguy hiểm là AI agent có thể thực thi mã tùy ý trên host chứa dữ liệu bí mật
  Ví dụ, xóa hộp thư, rò rỉ lịch, chuyển khoản nhầm... là những thứ không thể chỉ ngăn bằng sandbox
  Vì vậy ngoài sandboxing còn cần kiểm soát quyền chi tiết theo từng tác vụ và từng công cụ. Ví dụ: “Yêu cầu này chỉ được đọc Gmail, không được ghi hay xóa”

  • Hoàn toàn đồng ý. Ngoài ra còn cần theo dõi luồng dữ liệu giữa các công cụ (IFC) và suy giảm quyền hạn (ocap). Ví dụ, phải biểu đạt được các chính sách như “không được gửi dữ liệu ra ngoài thread email gốc”
  • Như bài “Don’t Trust AI Agents” đã nói, AI agent phải được thiết kế với giả định không đáng tin cậy. Cần một cấu trúc giảm thiểu thiệt hại trong trường hợp lỗi vận hành hoặc prompt injection
  • Tôi đã tạo framework agent tập trung vào kiểm soát chính sách là smith-core và gateway là smith-gateway. Nhưng những thảo luận về thiết kế bảo mật như thế này hầu như không được cộng đồng chú ý
  • Tôi có đọc một bài thú vị; như OpenClaw Sandbox đề cập, quyền hạn là nhị phân còn hành vi của LLM lại mang tính xác suất, nên hai khái niệm này về bản chất xung đột với nhau
  • Thực ra các hệ thống phân quyền hiện có như IAM, WIF, Macaroons, Service Accounts đã tồn tại sẵn. Nếu hỏi đội bảo mật thì có lẽ trong công ty cũng đã có những giải pháp có thể tận dụng

• Tôi thích NanoClaw. OpenClaw quá phức tạp, còn NanoClaw thì gọn gàng hơn nhiều
  Đây là dự án đầu tiên dùng Claude Code như một giao diện cấu hình, và việc thêm tính năng vừa thú vị vừa chạy tốt

  • Instance OpenClaw của tôi gần đây bị hỏng. Một bản cập nhật đã làm vỡ tích hợp OpenRouter, còn code thì quá phức tạp
    Mô hình bảo mật cũng không hợp với môi trường Kubernetes rootless của tôi nên lần nào cũng phát sinh vấn đề
    Vì thế tôi đã chuyển sang Nullclaw. Tôi có thể vừa học ngôn ngữ Zig vừa debug nên cũng thú vị về mặt học hỏi
  • Tôi tò mò không biết trong Nanoclaw có những workflow nào mà không thể dễ dàng tạo bằng Claude

• Docker sandbox khá giống với framework container của Apple
  Trên macOS, nó phù hợp như một runtime native nhẹ hơn Docker rất nhiều
  Nhưng trên Linux thì tôi không muốn dùng hypervisor. Chỉ với Linux namespace cũng đã có thể cô lập đủ tốt
  Tôi thắc mắc vì sao OpenClaw hay NanoClaw lại không cung cấp image Docker chính thức được cấu hình tử tế

  • Trên macOS tôi dùng Apple Container, còn trên các OS khác thì dùng Podman
    Container có một số lỗi mạng nhưng vẫn rất đáng giá. Chỉ cần chỉnh cấu hình DNS là được
    Tôi hài lòng vì không cần cài Claude Code hay Node.js trên host

• Điều quan trọng hơn chuyện có dùng container hay không là bạn đang định làm gì
  Runtime chỉ là thứ yếu cho đến khi tìm ra cách dùng token vào những công việc hữu ích
  Về mặt bảo mật, chỉ đưa LLM vào container là chưa đủ. Quan trọng là phạm vi thông tin mà nó có thể truy cập
  Nếu agent có thể truy cập mọi dữ liệu thì đó mới là rủi ro thực sự

  • Docker sandbox dùng MicroVM như một lớp cô lập bổ sung, chứ không chỉ là container đơn thuần

• Quyền hạn chi tiết và kiểm soát chính sách mới là cốt lõi
  Không chỉ là dùng được công cụ nào, mà còn phải định nghĩa cả được phép làm gì
  Ví dụ: chỉ được đọc email, chỉ truy cập một kho lưu trữ nhất định, đặt hạn mức chi tiêu...
  Chỉ sandbox Docker thôi thì vẫn không yên tâm để giao cho LLM những tài sản nhạy cảm như tài khoản nhắn tin

• Docker sandbox khởi chạy MicroVM và Docker daemon chuyên dụng cho từng agent, đồng thời cấu hình thêm egress proxy linh hoạt
  Tôi đã reverse engineer thử và thấy đây là một triển khai khá thú vị

• NanoClaw không phải là một sản phẩm hoàn chỉnh có thể dùng ngay
  Bạn phải tự thêm các tính năng như iMessage thông qua coding agent
  Nói cách khác, Claude đóng vai trò như compiler

  • Trước đây từng có thời người ta tự kiểm tra trực tiếp phần assembly do compiler tạo ra
    Coding agent hiện giờ vẫn đang ở mức đó. Những lời nói gần đây kiểu “coding agent đã tốt lên rất nhiều” là cường điệu
    Bạn vẫn phải liên tục bảo Claude rằng “cái đó vẫn chưa được giải quyết, làm lại đi”

• Tôi đang làm một ý tưởng tương tự “claws”
  Nhưng thay vì tích hợp ứng dụng nhắn tin, nó cung cấp TUI được mã hóa đầu cuối
  Tham khảo wingthing.ai / repo GitHub
  Tôi cũng đang cân nhắc cách hỗ trợ Docker nên sẽ xem thử dự án này

• Tôi tò mò về trường hợp sử dụng rõ ràng của Nano/Open-Claw. Có phải nó sẽ vận hành đời sống số của tôi thay không?

  • Thực ra khá đơn giản. Hoặc là cronjob cho LLM, hoặc là chat connector như Telegram hay email. Cái đầu thì cron thông thường làm được, cái sau thì cũng có thể làm bằng code thủ công hoặc Gemini Gems
  • Nó hữu ích để tự động hóa các công việc tri thức lặp lại như tóm tắt email, nhắc lịch, tài liệu briefing
  • Có thể nối với ứng dụng việc cần làm để bot quản lý qua tin nhắn. Cách này giúp tăng năng suất
  • Tôi dùng NanoClaw như một huấn luyện viên ăn uống và tập luyện. Nó phụ trách quản lý mục tiêu, lên kế hoạch bữa ăn, danh sách mua sắm và ghi chép luyện tập
    Tôi đã chuyển sang Apple Container và còn thêm bộ nhớ dài hạn dựa trên LanceDB. Giờ thì không cần phải lặp lại cùng một điều nữa