概要

• AIエージェント は信頼せず、常に悪意があるものとして扱うべきという原則
• NanoClaw はエージェントごとに分離されたコンテナを利用し、被害を最小化する設計
• OpenClaw はデフォルトでホスト上で動作し、十分な分離がないことが課題
• コードベースの小規模化と 明確な監査性 を重視
• セキュリティ対策はエージェントやユーザー、他グループも信頼しない設計思想

AIエージェントの信頼性問題と設計原則

• AIエージェント は「信頼しない」ことを前提とした設計が必要
• プロンプトインジェクション やサンドボックスの脱出など、既知・未知の攻撃リスク存在
• 権限チェックや許可リスト の強化だけではリスクを防げない
• 被害範囲を限定するアーキテクチャ の採用が重要

OpenClawとNanoClawの違い

• OpenClaw はデフォルトでホスト上で直接プロセスを実行
  • Dockerサンドボックスはオプションで、多くのユーザーは無効のまま利用
  • アプリケーションレベルの許可リストや確認プロンプトに依存
  • エージェントが悪意ある場合、これらの対策では防御が不十分
• NanoClaw はコンテナ分離を基本設計に組み込み
  • 各エージェントごとに独立したコンテナを割り当て
  • コンテナは一時的に生成・破棄され、 永続的な影響を防止
  • エージェントは非特権ユーザーとして動作、明示的にマウントされたディレクトリのみアクセス可能

エージェント間の分離

• OpenClaw のサンドボックスでは全エージェントが同一コンテナを共有
  • 複数エージェント間で情報漏洩のリスク
• NanoClaw は、エージェントごとに
  • 独自のコンテナ・ファイルシステム・セッション履歴を持つ
  • 他エージェントのデータへアクセス不可
  • コンテナ境界がOSによって強制され、 確実な分離 を実現

マウント許可リストと防御層

• ~/.config/nanoclaw/mount-allowlist.jsonでマウント可能なパスを制御
  • .ssh, .gnupg, .aws, .env, private_key, credentials等はデフォルトでブロック
  • 許可リストはプロジェクトディレクトリ外に配置、エージェントによる改ざん防止
  • アプリケーションコードは読み取り専用でマウント、 永続的な改変を防止

グループ・ユーザーの信頼性

• グループ内の他ユーザー も信頼しない設計
  • メイングループ以外はデフォルトで「信頼しない」扱い
  • 他グループのチャットやデータへのアクセス・タスクスケジューリング等は不可
  • プロンプトインジェクション への対策も考慮

コードベースのシンプル化と監査性

• OpenClaw は約40万行のコード・53個の設定ファイル・70以上の依存性
  • 大規模なコードベースは監査が困難、脆弱性の温床
• NanoClaw は1プロセス・数ファイルのみで構成
  • AnthropicのAgent SDK利用で、セッション管理やメモリ圧縮等を外部化
  • 全コードを1日でレビュー可能 な規模を維持
  • コントリビューションはバグ・セキュリティ修正・単純化のみ受け付け
  • 新機能は「スキル」として外部実装、オーナーが内容を確認してから導入
  • 導入したコードのみが攻撃対象となり、境界が明確

スキルベースの拡張と攻撃面の縮小

• 追加機能は「スキル」として分離実装
  • 例：WhatsAppサポートもスキル化し、コアの小型化を継続
• 必要な機能だけを選択的に追加 し、不要なコードを排除
• 攻撃対象範囲（アタックサーフェス）の最小化

セキュリティ設計思想のまとめ

• エージェントの誤動作や幻覚 がセキュリティ問題を引き起こす設計はNG
• セキュリティは「エージェント外」で強制されるべき
• コンテナ化・マウント制限・ファイルシステム分離 による被害範囲の限定
• AIエージェント利用自体が高リスク であることを前提に、信頼範囲を最小・可視化する設計
• NanoClaw のソースコードとセキュリティモデルは「短時間で読める」透明性を実現