- NanoClawとDockerの協業により、1行のコマンドで各AIエージェントを分離されたDockerサンドボックス内で実行できるようになった
- 各エージェントはマイクロVM内の独立したコンテナで動作し、ホストシステムへのアクセスなしに完全な分離環境を持つ
- 二重のセキュリティ境界構造により、コンテナ脱出が起きてもVMレイヤーで遮断され、ホストのファイル・認証情報・アプリケーションが保護される
- NanoClawのセキュリティモデルは**「不信を前提にした設計」**であり、エージェントを潜在的な悪意あるアクターとみなして被害を最小化する構造を採用している
- 今後はコンテキスト共有の制御、永続エージェント、きめ細かな権限ポリシー、人間による承認プロセスなど、大規模なエージェントチーム運用のための機能拡張を目指す
Dockerサンドボックス統合の概要
- NanoClawはDockerとの協業を通じて1行コマンドでのサンドボックス実行をサポート
- macOS（Apple Silicon）とWindows（WSL）で対応し、Linuxも近日追加予定
- インストールスクリプトがクローン、設定、サンドボックス構成を自動処理
- 各エージェントはマイクロVM内の独立したコンテナで実行
- 別個のハードウェアや複雑な設定は不要
- 各コンテナは独自のカーネルとDockerデーモンを持ち、ホストへのアクセスは遮断される
動作方式
- Dockerサンドボックスはハイパーバイザーレベルの分離を提供し、ミリ秒単位の高速な起動速度を持つ
- NanoClawはこの構造に自然にマッピングされる
- 各エージェントは独立したファイルシステム・コンテキスト・ツール・セッションを保有
- 例: 営業エージェントは個人メッセージにアクセスできず、サポートエージェントはCRMデータにアクセスできない
- マイクロVM層が第2のセキュリティ境界を形成
- コンテナ脱出が起きてもVMの壁で防がれ、ホストシステムを保護
セキュリティモデル: 不信ベースの設計
- NanoClawはAIエージェントを信頼しない構造を前提として設計されている
- プロンプトインジェクション、モデルの誤動作など予測不能なリスクを考慮
- エージェント環境に秘密情報や認証情報を入れないよう設計
- セキュリティはエージェント外部から強制される構造であり、正しい動作に依存しない
- OpenClawと異なり、NanoClawはエージェント間の完全な分離を提供
- OpenClawは同一環境を共有するため、個人データと業務データが混在する可能性がある
- エージェントを協業相手であると同時に潜在的な攻撃者とみなすセキュリティエンジニアリングの原則を強調
今後の発展方向
- 大規模なエージェントチーム運用のための新たなインフラとランタイムレイヤー構築の必要性を提示
- NanoClawはすでに複数のSlackチャンネルと接続し、業務別の独立エージェント運用が可能
- 次の段階として示された4つの主要機能
- 制御されたコンテキスト共有: チーム内での自由な情報共有と、チーム間での選択的共有を両立
- 永続エージェントの生成: 単発のサブエージェントではなく、永続的なID・環境・データを持つチームメンバーの形態
- きめ細かな権限ポリシー: メールの読み取りのみ許可、特定リポジトリへのアクセス制限、支出上限の設定などの細かな制御
- 人間による承認プロセス: 取り消せない操作は人間のレビュー後に実行
- NanoClawはセキュリティ中心のランタイムおよびオーケストレーションレイヤー、Dockerサンドボックスはエンタープライズ級インフラ基盤として位置づけられる
- 目標は基本的な分離、制御された協業、組織レベルの可視性とガバナンスを同時に提供するエージェント実行スタックの構築
NanoClawの概要
- NanoClawはオープンソースのセキュアなランタイムおよびオーケストレーションレイヤーであり、チーム単位のAIエージェント運用を支援
- GitHubでプロジェクトを確認し、スターで参加可能
1件のコメント
Hacker Newsのコメント
小さなディテールのように見えるが、いくつかの新しい設計判断が業界全体に広がれば、革新的な変化をもたらしそうだ
Karpathy が言うように、Slack・Discord のような統合を直接実装する代わりに、「統合を書く方法」についてのスキル（spec）を提供するアプローチが核心だ
これは「Claude native development」と呼べるもので、従来の「batteries-included」フレームワークではなく、「fork and customize」方式へとエコシステムが移っていく気がする
ただし、テスト・検証・セキュリティのような spec をどう配布するかなど、解決すべき課題も多い
OS レベルでもこうした変化が起こり得るのか気になる。各インスタンスが強い免疫系を持てば、攻撃により強い異種的なエコシステムになりそうだ
セキュリティツールやサンドボックス化を論じるときは、必ず**脅威モデル（threat model）**を明示すべきだ
AI エージェントが機密データのあるホストで任意コードを実行できるという点が危険だ
たとえば、メールボックスの削除、カレンダーの流出、誤送金などは、サンドボックスだけでは防げない
したがって、サンドボックス化に加えて、作業単位・ツール単位の細粒度な権限制御が必要だ。例: 「このリクエストは Gmail の読み取りのみ可能で、書き込み・削除は不可であるべき」
NanoClaw が気に入っている。OpenClaw は複雑すぎたが、NanoClaw はずっと簡潔だ
Claude Code を設定インターフェースとして使う最初のプロジェクトだが、機能追加も楽しく、うまく動いている
セキュリティモデルも私のrootless Kubernetes 環境と合わず、毎回問題が起きる
そのため Nullclaw に移った。Zig 言語を学びながらデバッグできるので、学習面でも興味深い
Docker サンドボックスは Apple の
containerフレームワークと似ているmacOS では Docker よりずっと軽量なネイティブランタイムとして適している
ただ、Linux ではハイパーバイザーは使いたくない。Linux namespace だけでも十分に隔離できる
なぜ OpenClaw や NanoClaw が、きちんと構成された公式 Docker イメージを提供しないのか気になる
Container にはネットワークのバグが少しあるが、それでも価値は大きい。DNS 設定を直すだけでよい
Claude Code や Node.js をホストにインストールしなくて済むので満足している
コンテナかどうかより重要なのは、何をしたいのかだ
有用な作業にトークンを使う方法を見つけるまでは、ランタイムは二次的だ
セキュリティ面でも、LLM をコンテナに入れるだけでは不十分だ。重要なのはアクセス可能な情報の範囲である
エージェントがすべてのデータにアクセスできるなら、それこそが本当のリスクだ
細粒度の権限とポリシー制御が核心だ
単にどのツールを使えるかではなく、何ができるかまで定義しなければならない
例: メールは読み取り専用、特定のリポジトリだけにアクセス可能、支出上限を設定、など
Docker サンドボックス化だけでは、メッセージングアカウントのような機密資産を LLM に任せるには不安が残る
Docker サンドボックスは各エージェントごとに専用の MicroVM と Docker デーモンを起動し、柔軟な egress プロキシもあわせて構成する
リバースエンジニアリングしてみたが、かなり興味深い実装だ
NanoClaw はすぐに使える完成品ではない
コーディングエージェントを通じて iMessage のような機能を自分で追加する必要がある
つまり、Claude がコンパイラの役割を果たしているわけだ
コーディングエージェントもまだそのレベルだ。最近「コーディングエージェントはずっと良くなった」という話は誇張だ
いまだに Claude に「それは解決していない、やり直して」と繰り返し指示しなければならない
私は「claws」に近いアイデアに取り組んでいる
メッセージングアプリ統合の代わりに、エンドツーエンド暗号化された TUIを提供する方式だ
wingthing.ai / GitHub リポジトリ を参照
Docker サポートの方法を検討中なので、このプロジェクトも見てみる予定だ
Nano/Open-Claw の明確なユースケースが気になる。自分のデジタル生活を代わりに運営してくれるのか？
Apple Container に移し、LanceDB ベースの長期記憶機能も追加した。もう同じことを繰り返し言う必要がない