ironclaw

信頼する必要のないセルフホスト型 AI エージェント。

各エージェントは、外部への通信、ホストの読み取り、独自ルールの書き換えが確実にできないサンドボックス内で隔離して実行されます。

IronClaw は、あなたが管理するインフラ上で自律型 AI エージェントを実行し、普段お使いのチャットアプリから利用できます。各エージェントは、どのアシスタントでもできるように、読み取り、書き込み、スケジュール設定、返信ができますが、network=none の隔離されたサンドボックス内で動作します。モデルへのアクセスはホストプロキシ経由に限られ、自身の設定を変更することはできません。 自律型プログラムに自分のマシンの鍵を渡すことなく、エージェントの機能を活用したいすべての方のためのものです。

GitHub Marketplace で公開中です。 封じ込め評価ツール ironctl scan は GitHub Action として利用できます。ワークフローに 1 行追加するだけで、すべてのプルリクエストに対して、0 から 100 までのサンドボックス分離スコアカードが 固定コメントとして投稿されます。ローカルで動作し、読み取り専用で、認証情報は不要です。

# .github/workflows/scan.yml
- uses: IronSecCo/ironclaw@v1
  with:
    target: my-container   # コンテナ、compose サービス、または k8s マニフェスト

デフォルトではレポートのみを出力します。マージを制限するには min-score: 90 を設定してください。CI でのスキャンをご覧ください。

_{実際の脱出が阻止される様子をご覧ください。実際のサンドボックス内にいる完全に脱獄したエージェントが、外部への通信、ホストのファイルシステムの読み取り、Docker ソケット経由でのホストの乗っ取りを試みます。各試みは分離境界で拒否され、その後、封じ込めの概要が表示されます。コマンドは 1 つ、認証情報は不要で、視差効果を抑える設定にも対応しています。examples/live-containment/run.sh}

⭐ 信頼する必要のないエージェントというアイデアに共感したら、リポジトリにスターを付けてください。進捗をワンクリックで追えるようになり、次の人にも見つけてもらいやすくなります。その後、上記のデモをそのまま、登録も API キーも不要で 30 秒で実行できます。

30 秒で試す（認証情報不要）

Docker デーモンが実行中であることを確認して（Docker Desktop を起動するか、Linux では sudo systemctl start docker を実行して）、次のブロックを貼り付けてください。

git clone https://github.com/IronSecCo/ironclaw.git && cd ironclaw
examples/live-containment/run.sh   # builds the sandbox once, engages a real sandbox, proves it holds

この 1 つのコマンドで、セキュリティ保護された一連の処理をすべてノート PC 上で実行します。オフラインのモックエージェント用コントロールプレーン（API キー不要）を起動し、セッションごとの実際のサンドボックスを有効にして、脱獄したエージェントに脱出を試みさせ、上でご覧いただいた封じ込めの概要を表示します。まずはブラウザーでエージェントとチャットしてみたいですか？hello-ironclaw または 認証情報不要のクイックスタートを実行してください。本番環境では、各サンドボックスを gVisor と network=none で隔離します。

警告

アルファ版ソフトウェアであり、開発中です。利用する前にお読みください。

• **アルファ版です。**フラグ、ディスク上の形式、HTTP／コントラクトのインターフェースは、予告や移行手段なしに変更される可能性があります。失っても構わないもの以外には使用しないでください。
• **すべての機能がエンドツーエンドでテストされているわけではありません。**コントロールプレーン、ゲートウェイ、暗号化キューのコアには実際のテストがあります（Go のテスト 800 件以上とブラックボックスのパリティテスト）。一方、チャネルアダプター、一部のツール、複数プロバイダーへのルーティング、サンドボックスの実起動は、より限定的なテストしか行われていません。テスト済みのコア以外は実験的なものとして扱ってください。

macOS では Linux＋gVisor よりサンドボックス境界が弱く、ネイティブの Windows ではエージェントのサンドボックスを実行できません（WSL2 を使用してください）。プラットフォームのサポートをご覧ください。

**セキュリティモデルを一言で言うと：**サンドボックス内の各エージェントは network=none で実行され、ホストプロキシ経由でのみモデルにアクセスし、**自身の設定を変更できません。**機能の変更はすべてゲートウェイで保留され、人間の判断を待ちます。設計の全容はアーキテクチャの概要と脅威モデルをご覧ください。

旅の全体を最初から最後まで見る

_{認証情報不要、コマンド1つ。オフラインの mock-agent が、APIキーなしでチャットからセッションごとのサンドボックスを経由して返信するまでの全経路を実行します。本番環境では各サンドボックスを gVisor と network=none で保護します。クイックスタート}

_{認証情報不要のデモ、実際のプロバイダーへの接続、初めての承認済みタスク。唯一の認証情報設定手順では、キーをホスト側に保持します。エージェントによる変更はすべて、人間による確認のためにゲートウェイで保留され、その後、追記専用の監査ログに記録されます。アニメーションは prefers-reduced-motion の設定時に最終フレームで停止します。クイックスタート}

2分以内に起動する

1つのコマンドで、ホスト用の2つのバイナリ（ironctl + ironclaw-controlplane）がインストールされます。開発モードでは、コントロールプレーンが http://127.0.0.1:8787 で API を提供します。初期状態のマシンから始めても、2分以内にセキュリティゲートウェイで機能の変更を確認できます。

# 1. Install — detects your OS/arch and verifies the SHA-256 checksum before installing
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

# 2. Start the control-plane in dev mode — API base URL: http://127.0.0.1:8787
export IRONCLAW_API_TOKEN=$(openssl rand -hex 32)
ironclaw-controlplane --dev --api-addr 127.0.0.1:8787 &

# 3. Your first command — submit a change; it is HELD at the gateway for a human decision
ironctl change submit --kind persona --group dev-agent --by you
ironctl change pending                       # see it waiting
ironctl change approve <change-id> --by you   # apply it

Windows では、irm https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.ps1 | iex でホスト用バイナリ（ironclaw-controlplane.exe + ironctl.exe）がインストールされ、--dev も実行できます。ただし、エージェントのサンドボックスには WSL2 または Linux が必要です。詳しくはWSL2 を使った Windows での利用をご覧ください。 バージョンの固定、システム全体へのインストール、ソースからのビルドについては、すべてインストールをご覧ください。

ワンクリックでクラウドにデプロイ

ローカルのツールを一切使わず、PaaS 上で強化されたコントロールプレーンを約2分で実行できます。承認ゲートウェイ、セッションごとの暗号化キュー、ホスト側での認証情報の管理、Web コンソールが含まれます。

これらの PaaS 環境で実行されるのはコントロールプレーンのみです。単一のコンテナには gVisor も Docker ソケットもないため、ここではエージェントのサンドボックスは起動しません（強化された Compose 環境と同じ制約です）。エージェントを完全に分離するには、gVisor ホストまたは k8s ノードを使用してください。詳細と環境設定については、デプロイガイド（パス D）をご覧ください。

CLI ファースト、API ファースト

これは機能であり、ダッシュボードがないことは欠落ではありません。すべての機能は、ドキュメント化された HTTP エンドポイントとironctl サブコマンドとして提供されるため、最初のコマンドから IronClaw をスクリプト化でき、監査可能で、CI にも適しています。フィッシングや設定ミス、公開したまま放置されるおそれのある公開ウェブ画面はありません。（現在は /ui/ にプライベートなメッシュ専用ウェブコンソールもあります。ただし、アクセス手段は追加されるだけで、これだけに限定されることはありません。同じ Tailscale にバインドされた API を利用するため、公開ポートは増えません。）

他との違い

一貫して重視しているのは、エージェントを信頼できないものとして扱い、セキュリティ境界を、ただ信頼するのではなく、自分で検証できるものにすることです。

⚖️ 選択肢を検討中ですか？ ホスト型エージェントプラットフォーム、コンテナと LLM を直接つなぐ方法、その他のセルフホスト型エージェントランタイムとの率直な比較は、IronClaw を選ぶ理由／代替製品との比較をご覧ください。

10 秒で自分のサンドボックスを監査する

この説明をそのまま信じる必要はありません。ironctl scan は、あらゆる稼働中のコンテナ、docker-compose サービス、Kubernetes ポッドの封じ込め状況を 0〜100 のスケールで評価します。IronClaw だけでなく、ご自身の環境でも使えるため、信頼できないコードにサンドボックスを渡す前に、実際にどの程度隔離できているかを測定できます。フェイルクローズド方式で、観測できない境界はすべて安全でないと評価し、決して見過ごしません。

ironctl scan my-container

また、デーモンもイメージのプルも不要で、作成時や CI 実行時に Dockerfile を静的に評価できます。これにより、認証情報の漏えい、ベースイメージのバージョン未固定、root のデフォルト設定を、本番環境ではなくレビュー時に検出できます。

ironctl scan --dockerfile Dockerfile --min-score 80

ironctl をソースからビルドする pre-commit フックを使えば、最初に何もインストールせずに、コミットごとに Dockerfile を自動評価できます。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/IronSecCo/ironclaw
    rev: v0.1.x
    hooks:
      - id: ironclaw-scan-dockerfile
        args: [--min-score=80]   # fail the commit below grade B

解説記事のDockerfile のセキュリティ問題をスキャンする方法では、意図的に問題を含めた Dockerfile を、修正を一つずつ加えながら **5/100（F）から 100/100（A）**へ引き上げます。

一般的な方法（root ユーザー、デフォルトのケイパビリティ、ブリッジネットワーク、docker.sock のマウント）で起動したコンテナの評価は 23/100、F です。一方、IronClaw の ic-sbx-* セッションサンドボックスは、申し分のない 100/100、A を獲得します。

不合格となった各項目には、具体的な穴と、それが重要な理由が記されています。ironctl scan --badge scan.svg で評価を取得して、ご自身の README に追加するか、ironctl scan --min-score 90 で CI をゲートしてください。

7 つの評価項目とすべてのフラグについては、スキャンのリファレンスをご覧ください。または、コンテナー分離スコアのディレクトリをご覧ください。これは、最も多くプルされている公開イメージ 150 種以上のデフォルト設定での評価をまとめたもので、現在実行しているコンテナーの安全性を確認できます。ランキングはコンテナー分離リーダーボード（殿堂入りと最悪の事例）で確認できます。また、インタラクティブなスコアエクスプローラーでは、条件を絞り込んでリポジトリ用のバッジを取得できます。

同じスキャンデータに基づく比較記事： Alpine と Debian と Ubuntu の比較（ベースイメージによって分離に違いはあるのか？）、 Docker のデフォルト設定と強化設定の比較（フラグごとの 48 ポイントの差）、 gVisor と runc の比較（ホストの共有カーネルが弱点になる場合）。 イメージごとの強化手順、デフォルトの評価、失敗する項目、そしてギャップを埋めるための正確な ironctl scan --fix フラグを紹介します。強化ガイドのハブからご覧いただくか、以下からお選びください。 Postgres、 MySQL、 MariaDB、 MongoDB、 Cassandra、 ClickHouse、 Redis、 Memcached、 Elasticsearch、 Kafka、 NATS、 RabbitMQ、 Vault、 Consul、 MinIO、 nginx、 Grafana、 Prometheus、 Traefik、 InfluxDB、 CockroachDB、 TimescaleDB、 Valkey、 HAProxy、 ZooKeeper、 信頼できない Node.js。

すべてのプルリクエストを評価する

同じ評価ツールは GitHub Marketplace でも IronClaw sandbox scanとして公開されています。ワークフローに 1 行追加するだけで、すべてのプルリクエストに、コメントとして固定され、内容がその場で更新される封じ込めスコアカードが付与されます。

# .github/workflows/scan.yml
- uses: IronSecCo/ironclaw@v1
  with:
    target: docker-compose.yml
    mode: compose
    min-score: 90        # omit / 0 = report-only, never blocks the check

認証情報もコントロールプレーンも不要で、標準の ubuntu-latest ランナー上で実行されます。mode: k8s を指定すると policy-check: true が追加され、--emit-policy が生成するルールに該当した場合、チェックは失敗します。また、 upload-sarif: true を指定すると、失敗した項目が Security タブに送信されます。入力と出力の全項目については、 CI でのスキャンをご覧ください。

スコアを表示する

カバレッジやビルドのバッジと同じように、README に封じ込め評価を掲載しましょう。 shields.io のエンドポイントファイルを生成してコミットし（サーバーを使わないため、バッジへのアクセスで リモートスキャンが実行されることはありません）、埋め込みます。

ironctl scan my-container --badge-json .ironclaw/sandbox-isolation.json
git add .ironclaw/sandbox-isolation.json && git commit -m "chore: add sandbox isolation badge"

[![Sandbox Isolation Score](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/OWNER/REPO/main/.ironclaw/sandbox-isolation.json)](https://ironsecco.github.io/ironclaw/scan/)

この README の上部にあるバッジは IronClaw 自身の評価で、.ironclaw/sandbox-posture.ymlに基づき、100/100 A を獲得しています。詳しい手順はこちらをご覧ください： リポジトリにライブの Sandbox Isolation Score バッジを追加する。

仕組み

メモリを共有せず、会話ごとに用意された暗号化 SQLite ファイル 2 つを介してのみ通信する、コンパイル済みの Go プログラム 2 つで構成されています。

flowchart TB
  CHAT["Chat platforms<br/>12 channel adapters"]
  CLI["ironctl CLI"]
  WEB["Web console"]

  subgraph host["Trusted host — control-plane (cmd/controlplane)"]
    API["HTTP API<br/>Tailscale mesh-only + bearer"]
    GW["Gateway<br/>deterministic verifiers · human approval"]
    CORE["Router · delivery · sweep · key custodian"]
    CHAD["Channel adapters"]
    MP["Model proxy<br/>holds provider keys"]
    ISO["Isolation launcher<br/>gVisor / runsc"]
  end

  subgraph queues["Encrypted SQLCipher queues · per session"]
    INQ[("inbound.db<br/>read-only to agent")]
    OUTQ[("outbound.db<br/>append-only by agent")]
  end

  subgraph box["Agent sandbox · gVisor · network=none"]
    LOOP["Agent loop · tools · model provider"]
  end

  PROV["Model providers<br/>Anthropic · OpenAI · OpenRouter"]

  CHAT <--> CHAD
  CLI -->|mesh only| API
  WEB -->|mesh only| API
  CHAD --> CORE
  API --> GW --> CORE
  CORE -->|write| INQ
  OUTQ -->|read| CORE
  ISO -->|launch| LOOP
  INQ -->|ro bind mount| LOOP
  LOOP -->|append| OUTQ
  LOOP -->|unix socket| MP -->|HTTPS · key injected host-side| PROV

  classDef host fill:#eaf2ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef store fill:#b9d4ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef box fill:#1d4ed8,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef control fill:#16224a,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef ext fill:#f4f9ff,stroke:#8fb4ff,stroke-width:1px,color:#16224a;

  class API,CORE,CHAD,MP,ISO host;
  class GW control;
  class INQ,OUTQ store;
  class LOOP box;
  class CHAT,CLI,WEB,PROV ext;

• control-plane はチャットを受信してルーティングし、キーを保持し、承認ゲートウェイを実行します。また、独自のチェックを行ったうえで、エージェントに代わってすべての特権操作を実行します。
• sandbox は会話ごとに 1 つ用意され、gVisor でラップされており、独自のネットワークはありません。暗号化された受信ボックスを読み取り専用で読み込み、ホストプロキシ経由で AI モデルを呼び出し、暗号化された送信ボックスに書き込みます。機能の変更を要求することはできますが、自ら適用することはできません。
• 固定された契約（internal/contract）は、双方がインポートする唯一のパッケージです。型付き ID、行の形式、埋め込み SQL スキーマ、固定された暗号パラメーター、ゲートウェイプロトコルが含まれています。

単一のメッセージはシンプルなループをたどります。エージェントが実行できることを変更する処理は、分岐した経路を通って、人間の承認を行うゲートウェイへ進みます。

flowchart LR
  SENDER["External sender<br/>Slack · email · …"]
  ADAPTER["Channel adapter"]
  ROUTER["Router<br/>authorize + fan-out"]
  INQ[("inbound.db")]
  LOOP["Agent loop"]
  MODEL["Model provider"]
  OUTQ[("outbound.db")]
  DELIVERY["Delivery"]
  GW{"Gateway<br/>human approval"}
  APPLY["Control-plane<br/>applies change"]

  SENDER -->|message| ADAPTER --> ROUTER
  ROUTER -->|write · encrypted| INQ
  INQ -->|ro| LOOP
  LOOP <-->|model call via host proxy| MODEL
  LOOP -->|reply · append| OUTQ
  OUTQ --> DELIVERY --> ADAPTER
  ADAPTER -->|reply| SENDER
  LOOP -.->|capability-change request| GW
  GW -.->|approved| APPLY

  classDef host fill:#eaf2ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef store fill:#b9d4ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef box fill:#1d4ed8,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef control fill:#16224a,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef ext fill:#f4f9ff,stroke:#8fb4ff,stroke-width:1px,color:#16224a;

  class ADAPTER,ROUTER,DELIVERY,APPLY host;
  class INQ,OUTQ store;
  class LOOP box;
  class GW control;
  class SENDER,MODEL ext;

設計の詳細については、docs/architecture.md、docs/threat-model.md、および平易な言葉で解説した docs/ironclaw-explained.md をご覧ください。

📚 ドキュメントサイトの全容： ironsecco.github.io/ironclaw — クイックスタート、アーキテクチャ、脅威モデル、チャネル、スキル、OpenAPI リファレンス、セキュリティ情報を、すべて一か所で閲覧できます（docs/ から構築され、main へのプッシュごとに公開されます）。

🧭 初めての方へ： 実践チュートリアルでは、git clone からエージェントの実行までを学べます。5 分で作る初めてのサンドボックス化エージェント、Slack の接続、カスタムチャネルアダプターの作成をご覧ください。

プラットフォームのサポート

IronClaw のセキュリティモデルは gVisor（runsc）を基盤としています。これはエージェントの Linux システムコールを傍受するユーザー空間カーネルであり、network=none、seccomp システムコール許可リスト、Linux ケーパビリティの削除、読み取り専用 rootfs を実際に強制するレイヤーです。gVisor は Linux 専用であり、この点がプラットフォーム全体の方針を決定します。

macOS では、システム全体をネイティブにビルド、スクリプト実行、デモ、開発でき、Docker Desktop 経由でエージェントを実行することもできます。ただし、その場合のサンドボックス境界はgVisor ではなく、Docker Desktop Linux VM 内の runc によって提供されます。 サンドボックスごとのシステムコール傍受はなく、調整済みの seccomp プロファイルは適用されず、network=none も自動では適用されません（Docker アイソレーターは、設定したネットワークをそのまま渡します。そのため、外部への通信を許可しないブリッジを IRONCLAW_DOCKER_NETWORK に自分で設定してください）。これは、脅威モデルで想定されているセキュリティ態勢よりも弱いものです。

WSL2 経由の Windows

install.ps1 PowerShell インストーラーを使うと、Windows 上でネイティブにホストプレーンを利用できます。 ironclaw-controlplane.exe と ironctl.exe が動作し、暗号化された SQLCipher キューが機能します。また、--dev モード（実際のサンドボックスなし）なら、エンドツーエンドで動作します。実際のエージェントサンドボックスはネイティブの Windows では動作しません。 gVisor（runsc）は Linux 専用であり、Docker フォールバックは Unix ソケット（/var/run/docker.sock）経由で Docker Engine に接続しますが、ネイティブの Windows 版 Docker Desktop はこのソケットを公開せず、代わりに Windows 名前付きパイプを提供します。そのため、ネイティブの Windows で利用できるのはコントロールプレーンと ironctl ですが、エージェントランタイムを起動する場所がありません。

Windows でエージェントを実際に動かすには、WSL2 を使用してください。

wsl --install -d Ubuntu          # one-time: install WSL2 + Ubuntu, then reboot

次に、WSL2 の Ubuntu シェル内で Linux ビルドをインストールし、Linux とまったく同じ手順で実行します。

curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

WSL2 内には /var/run/docker.sock があります（Docker Desktop の WSL 統合、またはディストリビューションにインストールした Docker）。そのため、IRONCLAW_RUNTIME=docker を設定すると、実際の Linux サンドボックスコンテナーが起動します。gVisor を使った完全な構成にするには、ベアメタル Linux の場合と同様に、WSL2 ディストリビューション内に runsc をインストールしてください。WSL2 ホストは、上記の Linux の行と同様に扱ってください。

ローカル開発を超える用途では、gVisor を使って Linux 上でサンドボックスホストを実行してください（ベアメタル、VM、または WSL2）。コントロールプレーンはネイティブの Windows を含め、任意の場所に配置できます。ただし、IronClaw が基盤とする境界を実現するには、エージェントサンドボックスに Linux と gVisor の基盤が必要です。

プロジェクトの状況

アルファ版です。 アーキテクチャは確定しており、コントロールプレーンとサンドボックスのパイプラインは完全に実装され、テスト済みです。暗号化キューのバインディングも接続されました。

• 暗号化 SQLite キューのバインディング — ✅ 接続済み（RFC-0001 適用済み）。contract.Open* は cgo 経由でセッションごとの SQLCipher データベースを開きます（github.com/mutecomm/go-sqlcipher/v4）。ラウンドトリップテストでは、書き込み→読み取り、読み取り専用での書き込み拒否、誤ったキーでの失敗、ディスク上に平文が残らないことを確認しています。ビルドには CGO_ENABLED=1（C ツールチェーン）が必要になりました。internal/host/queue は実際のバインディングを使用し、インメモリバックエンドは --dev とテスト用に引き続き利用できます。
• サンドボックスの rootfs プロビジョニング — ✅ プラグイン可能なプロビジョナー経由で接続済みです。isolation が強化された OCI 仕様を構築し、信頼ポリシーに基づくイメージダイジェスト／署名の検証を行いながらバンドルの rootfs をプロビジョニングし、runsc を実行します。実際に起動するには、環境内に runsc とプロビジョニング済み／署名済みイメージが必要です。
• 本番環境向けの強化（Wave 4） — 永続的／プラグイン可能なマスターキーの管理、Prometheus の /metrics エンドポイント、構造化ログ、ホストの再起動とサンドボックスプロバイダーのバックオフ、モデルプロキシのレート上限／監査／秘匿化が追加され、cmd/controlplane に組み込まれています。API サーバーの強化設定（任意の TLS、レート制限、ボディサイズ制限、/readyz による準備状態ゲート）は api.With* オプションとして存在しますが、まだエントリーポイントには組み込まれていません（ロードマップを参照）。

残っている項目についてはロードマップを参照してください。コントロールプレーンは、現在ビルド、テスト、実行できます。サンドボックスを実際に起動するには、runsc とプロビジョニング済みイメージが必要です。

前提条件

3 つの外部ランタイム依存関係（gVisor、Tailscale、暗号化 SQLite バインディング）は、 意図的に同梱されていません。ホストのセットアップについては、deploy/README.md を参照してください。

インストール

Homebrew (macOS / Linux)

brew tap IronSecCo/ironclaw https://github.com/IronSecCo/ironclaw
brew install ironsecco/ironclaw/ironclaw

これにより、数式が現在指定しているリリースから ironctl、ironclaw-controlplane、ironclaw-sandbox がインストールされます。数式は各アーカイブを、そのリリースの署名済み SHA256SUMS に記録された SHA-256 に指定しているため、Homebrew はインストール前にダウンロードを検証します。ironctl version で確認してください。

tap が保持するバージョンは常に 1 つだけです。自動プルリクエストによりリリースのたびに数式が更新され、必須の CI チェックで、そのリリースの cosign 検証済み SHA256SUMS から数式が再生成された後にのみマージされるため、tap が最新リリースに一時的に追いつかない場合があります。まず brew update を実行し、最新バージョンについてはリリースを参照してください。tap にまだ反映されていないバージョンを含め、特定のバージョンをインストールするには、インストーラースクリプトの IRONCLAW_VERSION を使用してください（下記）。

完全修飾名を使用してください。 homebrew-core には ironclaw という名前の無関係な数式もあり、core では修飾なしの名前が優先されます。そのため、ironclaw だけではなく ironsecco/ironclaw/ironclaw をインストールしてください。また、明示的な tap URL も必要です。私たちの tap はこのリポジトリにあり、homebrew-ironclaw リポジトリにはありません。

本番環境では通常、コントロールプレーンは GHCR コンテナイメージとして実行されます（デプロイガイドを参照）。ネイティブの ironclaw-controlplane バイナリは、ローカル実行や --dev 実行に便利です。

ビルド済みバイナリ（インストーラースクリプト）

1 つのコマンドで最新リリースの ironctl と ironclaw-controlplane をインストールできます。スクリプトは OS とアーキテクチャを検出し、GitHub Releases から対応するアーカイブをダウンロードして、インストール前に SHA-256 チェックサムを検証します。

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

Windows (PowerShell)

irm https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.ps1 | iex

これによりホストバイナリ（ironclaw-controlplane.exe + ironctl.exe）がインストールされ、ネイティブで --dev が実行されますが、実際のエージェントサンドボックスは実行できません — その実行には Linux が必要です。Windows でエージェントを実行するには、WSL2 内にインストールしてください。WSL2 経由での Windowsを参照してください。

新しいリリースは main へのプッシュごとに公開され、以下の OS 向けにビルド済みアーカイブが提供されます。

インストーラーは、いくつかの環境変数を読み取ります（パイプの sh 側に渡してください）。

# Pin a version instead of latest
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | IRONCLAW_VERSION=v0.1.102 sh

# Install system-wide (a normal user defaults to ~/.local/bin)
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sudo sh

# Choose the install directory
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | IRONCLAW_BINDIR="$HOME/bin" sh

次に、インストールした内容を確認します。

ironctl --version

ファイルを手動で取得したい場合は、最新リリースからお使いのプラットフォーム向けのアーカイブと SHA256SUMS をダウンロードしてください。

バージョンマネージャー（mise / asdf）

アカウントも sudo も不要で、mise または asdf を使ってプロジェクトごとに IronClaw のバージョンを固定できます。最も手軽な方法は、mise の ubi バックエンドを使って GitHub のリリースから ironctl CLI を直接インストールすることです（プラグインリポジトリは不要です）。

mise use -g "ubi:IronSecCo/ironclaw[exe=ironctl]@latest"
ironctl --version

ホストバイナリ（ironctl と ironclaw-controlplane）の両方を使い、.tool-versions でバージョンを固定するには、packaging/asdf-ironclaw/ の asdf 形式のプラグインを使用します。このプラグインはリリースの tarball をダウンロードし、公開されている SHA256SUMS と照合して検証したうえで、両方のバイナリを管理対象の PATH に配置します。

ironclaw 0.1.217

プラグインは独立したリポジトリとして解決されます（asdf は URL からプラグインをクローンします）。そのため、プラグインが独自の IronSecCo/asdf-ironclaw リポジトリに配置されると、asdf plugin add ironclaw と mise use asdf:... が使えるようになります。それまでは、packaging/asdf-ironclaw/ のスクリプトを直接実行できます（そのディレクトリの README.md を参照してください）。

リリースの検証

リリースは署名され、アテステーションが付与されています。SHA256SUMS に対する鍵不要の cosign 署名、SBOM（SPDX + CycloneDX）、すべてのアーカイブとコンテナーイメージのビルド来歴アテステーションが含まれます。リリースの作成、検証、取り消し方法については、リリース手順書を参照してください。

cosign verify-blob SHA256SUMS \
  --signature SHA256SUMS.sig --certificate SHA256SUMS.pem \
  --certificate-identity-regexp '^https://github.com/IronSecCo/ironclaw/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c SHA256SUMS        # then confirm your archive matches

gh attestation verify ironclaw_<version>_<platform>.tar.gz --repo IronSecCo/ironclaw
gh attestation verify ./ironctl --repo IronSecCo/ironclaw   # a binary extracted from the archive
gh attestation verify oci://ghcr.io/ironsecco/ironclaw-controlplane:latest --repo IronSecCo/ironclaw

gh attestation verify oci://ghcr.io/ironsecco/ironclaw-controlplane:latest \
  --repo IronSecCo/ironclaw \
  --predicate-type https://cyclonedx.org/bom

ソースからのビルド

Go 1.23 以降と C ツールチェーンが必要です（CGO_ENABLED=1 — 暗号化 SQLite バインディングは cgo 経由でビルドされます）。

# Clone
git clone https://github.com/IronSecCo/ironclaw.git
cd ironclaw

# Build all binaries
make build            # == go build ./...

# Or install the two host binaries onto your PATH
go build -o /usr/local/bin/ironclaw-controlplane ./cmd/controlplane
go build -o /usr/local/bin/ironctl               ./cmd/ironctl

システム全体にインストールするには、バイナリをビルドしてインストールし、/etc/ironclaw と /var/lib/ironclaw を用意して、サービス（Linux では systemd、macOS では launchd）を有効にする sudo deploy/install.sh を実行します。/etc と /var/lib に書き込むため、root 権限が必要です。このスクリプトが依存する外部ランタイム（containerd + gVisor、Tailscale）は別途セットアップします。詳しくは deploy/README.md を参照してください。

Docker（docker compose）を使用する場合

1つのコマンドでコントロールプレーンをセルフホストできます。クローンしたディレクトリから実行します：

cp .env.example .env          # fill in ANTHROPIC_API_KEY (optional to boot)
docker compose up -d          # builds locally on first run, or pulls the GHCR image
docker compose logs -f controlplane   # CLAIM the admin token printed once on first run

管理者/API トークンは初回起動時に生成され、ログに一度だけ出力されます（再取得できません）。自分で IRONCLAW_API_TOKEN を設定した場合を除きます。管理者 API は 127.0.0.1:8787 のみに公開されます。リモートアクセスには Tailscale を前段に配置してください。

公開イメージを使用しますか？リリースのたびに GitHub Container Registry にプッシュされます：

docker pull ghcr.io/ironsecco/ironclaw-controlplane:latest
# or pin a release: docker pull ghcr.io/ironsecco/ironclaw-controlplane:v0.1.102

.env で IRONCLAW_IMAGE を設定すると、そのタグを docker compose で固定できます。コントロールプレーンが読み込むすべての変数は .env.example に記載されています。エージェントのサンドボックス自体は compose サービスではありません。コントロールプレーンが gVisor（runsc）の子プロセスとして network=none で起動します。実際のサンドボックスを実行するには、runsc に対応したホストが必要です（deploy/README.md を参照）。

本番環境での運用をお考えですか？**デプロイガイド**では、強化された永続運用の構成について説明しています。TLS リバースプロキシ（deploy/Caddyfile）の背後に置く、制限を強化した deploy/docker-compose.prod.yml（読み取り専用 rootfs、ケイパビリティの削除、リソース制限）、env-file によるシークレット管理、暗号化された状態のバックアップ／復元、ダイジェストを固定したアップグレード、Prometheus /metrics が含まれます。

クイックスタート

ローカル環境での詳しい手順です。開発モードでコントロールプレーンをソースから実行し（gVisor は使用せず、ループバックにバインド）、管理者 CLI で操作します：

# Terminal 1 — start the control-plane in dev mode
export ANTHROPIC_API_KEY=sk-ant-...        # held host-side; never enters the sandbox
export IRONCLAW_API_TOKEN=$(openssl rand -hex 32)
go run ./cmd/controlplane --dev --api-addr 127.0.0.1:8787

# Terminal 2 — talk to the gateway with ironctl
export IRONCLAW_API_TOKEN=<same token as above>

# Submit a capability change — it is HELD pending a human decision (the gateway choke point)
ironctl change submit --kind persona --group dev-agent --by alice

# See what's waiting for approval, then approve or reject by id
ironctl change pending
ironctl change approve <change-id> --by alice

# Inspect the append-only audit log
ironctl audit --limit 20

ペルソナ、有効化するツール、パッケージ、接続設定、権限、マウントなど、すべての変更はこの同じゲートウェイを経由します。ゲートウェイを迂回してファイルを編集する方法はありません。

例

そのうち2つは認証情報なしで最初から最後まで実行できます。モデルキーもチャンネルトークンも不要で、Docker だけです。1行コピーして、動作を確かめてください。

_{hello-ironclaw — 代表的な「動作します」の例です。 1つのコマンドで、実際のセキュアな経路（エンゲージ → セッションごとのサンドボックス → 暗号化キュー → 返信）を通じてチャットを送り、返信が戻ることを検証します。認証情報は不要で、CI のスモークテストも兼ねています。アニメーションは prefers-reduced-motion の場合、最終フレームで停止します。}

_{live-containment — 実際の脱出を検知する様子をご覧ください。 60秒でセキュリティの要点がわかります。1つのコマンドで実際のサンドボックスを起動すると、完全に脱獄されたエージェントが脱出を試み（ネットワーク経由のデータ流出、ホストファイルシステムからの脱出、Docker ソケット経由のホスト乗っ取り）、ターミナルに各試行が拒否されたことと封じ込めの概要が表示されます。red-team-escape の厳選版です。認証情報は不要です。}

_{red-team-escape — 証明できる隔離です。 live-containment の基盤となる、6項目の完全なテストです。兄弟コンテナからの脱出とセッション間のキー管理のプローブを追加し、署名付きのバージョン管理された封じ込めレポートを出力します。すべてのプッシュで CI の封じ込めゲートとして実行されます。認証情報は不要です。}

実行可能なレシピは examples/ にあります。それぞれ README.md と setup.sh を含むディレクトリです。 そのうち3つには run-mock.sh が付属しており、オフラインの mock プロバイダー上で受信 → エージェント → 返信の全体のパイプラインを実行できます。そのため、新しくクローンした環境でもモデルキーやチャンネルトークンなしで動作します。

docker compose -f docker-compose.demo.yml up -d --build   # seeds the offline mock-agent
./examples/scheduled-report/run-mock.sh                   # cron-style self-scheduling summary
./examples/webhook-responder/run-mock.sh                  # inbound webhook → agent reply
./examples/slack-triage/run-mock.sh                       # classify/label every message

• scheduled-report/ — スケジュールに従って自動起動し（schedule_task）、要約してチャンネルに投稿します。(認証情報不要のデモ)
• webhook-responder/ — 受信した HTTP webhook を、返信するエージェントにルーティングします。(認証情報不要のデモ)
• slack-triage/ — 受信するすべての Slack メッセージを分類してラベル付けします。(認証情報不要のデモ)
• personal-assistant/ — Telegram 上の非公開 1:1 アシスタントと、必須の変更承認フローの手順解説です。
• channel-triage/ — @mention があり、送信者が既知の場合にのみ応答する Slack トリアージボットです。
• multi-agent-team/ — エンゲージモードと優先度で分離された、1つのチャンネルを共有する2つのエージェントです。

使用方法

ironclaw-controlplane — ホストデーモン

ironclaw-controlplane \
  --api-addr "$(tailscale ip -4):8787" \            # bind to the tailnet IP (no public port)
  --model-proxy-socket /run/ironclaw/modelproxy.sock \
  --runtime runsc \                                 # container runtime for sandboxes
  --state-dir /var/lib/ironclaw \
  --sweep-interval 60s

MCP サーバー

サンドボックスの安全性を損なうことなく、Model Context Protocol サーバー（ローカルの stdio サブプロセスまたはリモートの HTTPS エンドポイント）のツールでエージェントを拡張できます。MCP はホスト側のみで実行されます。ローカルサーバーは強化された network=none コンテナ内で隔離され、リモートサーバーには TLS 経由で接続します。サンドボックスはどちらにも直接アクセスせず、セッションごとのブローカーソケットを介して通信します。すべての呼び出しはツールごとに人間が承認した許可に照らして確認され、監査されます。これにより、参照設計にあった「盲目的な MCP 承認」の問題を解消します。--mcp-catalog で有効にし、コンソールの MCP タブでサーバーを追加してエージェントに許可を付与します。バンドルされている cmd/mcp-sample サーバーで、最初から最後まで動作を試せます。 詳細ガイド：docs/mcp.md。 IronClaw の sandbox_exec ツールを Claude Desktop、Cursor、または Windsurf に MCP サーバーとして公開する方法については、docs/mcp-server/ をご覧ください。

環境変数：ANTHROPIC_API_KEY（モデルプロキシの認証情報。ホストのみ）および IRONCLAW_API_TOKEN（設定すると、すべての API 呼び出しでベアラートークンが必要です）。

ウェブ検索

サンドボックスは network=none で、ホストを経由する監査付きエグレスブローカーを通じてのみホストにアクセスできます。web_search ツールはこのブローカーを使用するため、デフォルトでは無効で、--egress-socket と --search-backend の両方を指定した場合にのみ有効になります。

• duckduckgo — キー不要、シークレット不要。検索をすばやく使い始められますが、DuckDuckGo のキー不要 API は、ランキング付きの完全なウェブインデックスではなく、インスタントアンサーや関連トピックを返すため、人物名などの特定の検索では情報が少ないことがあります。
• brave[:cred] — 認証情報 Vault 経由で、名前を指定して Brave Search にアクセスします（vault://<cred>/…）。API キーはホスト側のインジェクターに保持され、サンドボックスには入りません。一致する認証情報を指定した --vault-endpoint が必要です。

--dev を指定すると DuckDuckGo バックエンドが自動的に有効になります（エグレスソケットはモデルプロキシソケットの隣に配置され、同じサンドボックスマウントを使用します）。Docker アイソレーターでは、サンドボックスからアクセスできるよう、これらのソケットを含むディレクトリが IRONCLAW_DOCKER_BINDS に含まれていることを確認してください。

ironctl — 管理者 CLI

コントロールプレーン API のシンクライアントです。--addr のデフォルトは http://127.0.0.1:8787 です。ベアラートークンは IRONCLAW_API_TOKEN または --token から取得します。

ironctl change submit  --kind <k> --group <g> --by <user>   # k: persona|enabled_tools|packages|wiring|permissions|mounts
ironctl change pending                                       # list changes awaiting a decision
ironctl change history                                       # all changes and their outcomes
ironctl change approve <id> --by <user>
ironctl change reject  <id> --by <user>
ironctl audit [--limit N]                                    # append-only gateway audit log

手軽にエージェントを定義する

ツール名を知っていたり、JSON を手書きしたりする必要はありません。スターターテンプレートを選んで調整すれば、CLI またはウェブコンソールの Agents → Create ビルダーから、1 ステップで作成できます。

ironctl tools                                  # browse every built-in tool, grouped, with descriptions
ironctl agent templates                        # list starter presets (assistant, researcher, …)

# Guided wizard (run in a terminal with no flags): name → template → persona → tools → confirm
ironctl agent create

# Or one-shot/scriptable — template + a couple extra tools, persona override, default model:
ironctl agent create --name "Research Bot" --template researcher --tool schedule_task
ironctl agent create --name "Helper" --template assistant --all-tools --yes

ironctl agent list                             # all agents, with model + live session/channel counts
ironctl agent show research-bot                # persona, model, enabled tools, installed skills

ペルソナを個別のドキュメントとして管理。 不透明な 1 つのプロンプトにまとめるのではなく、エージェントのペルソナを役割ごとに分けます。IDENTITY.md（どのような存在か）、SOUL.md（性格や話し方）、AGENTS.md（どのように動作するか）を組み合わせてシステムプロンプトを構成します。内容を直接設定するか、これらのファイルがあるディレクトリを指定できます（ビルダーには同じ 3 つのフィールドが表示されます）。

ironctl agent create --name "Atlas" \
  --identity "You are Atlas, a research assistant for the data team." \
  --soul     "Curious and precise. You cite sources and admit uncertainty." \
  --instructions "Search before answering; prefer primary sources; summarize with links."

ironctl agent create --name "Atlas" --persona-dir ./atlas/   # loads IDENTITY.md / SOUL.md / AGENTS.md

これにより、エージェント（名前＋ペルソナドキュメント＋モデル＋ツール）を、単一のオペレーター直接書き込みで定義します。ウェブ/API ツールを有効にすると、エージェントから見えるようになりますが、実際の外向き通信には引き続きゲートウェイ経由で承認済みホストが必要なため、ネットワークの状態は変わりません。

sandbox — サンドボックス内のエージェント

手動ではなく、コントロールプレーンのアイソレーターによって起動されます。セッションキーとキューのパスを受け取り、推論ループを実行します。主なフラグ（cmd/sandbox）：--inbound、--outbound、--key、--workspace、--heartbeat、--model-socket、--model-host、--model。

コントロールプレーン HTTP API

モデルプロバイダー

デフォルトでは、すべてのエージェントが Anthropic（Claude）と通信します。エージェントの接続先を OpenAI または OpenRouter に変更することも、IronClaw にモデルキーを一切保持させずに、OneCLI などオペレーターが運用する認証情報ゲートウェイ経由にすることもできます。ゲートウェイはリクエスト時に実際の認証情報を注入します。いずれの場合も、サンドボックスは network=none のままで認証情報を持ちません。モデルに接続するのはホスト側のモデルプロキシの Unix ソケット経由のみで、ホストプロキシが呼び出しを認証し、外向き通信の許可リストを適用します。バックエンドはエージェントグループごとにホスト側で選択され、サンドボックスがプロバイダーを選択したり変更したりすることはできません。

プロバイダーキーを直接設定する

ホスト側でキーを 1 つ以上設定します（デーモンの環境変数、または docker compose 用の .env）。プロバイダーの上流ホストは、そのキーが存在する場合にのみ許可リストに追加されます。

export ANTHROPIC_API_KEY=sk-ant-...     # default / primary
export OPENAI_API_KEY=sk-...            # optional
export OPENROUTER_API_KEY=sk-or-...     # optional

OneCLI などの認証情報ゲートウェイ経由（ChatGPT/Codex — IronClaw 内にキー不要）

認証情報ゲートウェイは、実際の認証情報を保持し、リクエストごとに注入するホストローカルの HTTP CONNECT プロキシです。そのため、コントロールプレーンもサンドボックスもモデルキーを目にすることはありません。 これを使うと、OneCLI 経由で ChatGPT/Codex アカウントを使ってエージェントを動作させられます。IronClaw の codex プロバイダーは ChatGPT Codex Responses API（chatgpt.com）を使用し、OneCLI が OAuth 認証情報を付加します。

ホスト上で OneCLI を実行し（デフォルトのアドレスは 127.0.0.1:10255）、モデルプロキシの接続先に指定して、OneCLI が提供するホストを許可リストに追加します。

# The gateway URL carries your per-agent OneCLI token as Basic userinfo — Go's HTTP
# client sends it as Proxy-Authorization on CONNECT. The gateway terminates TLS with
# its own CA, so upstream TLS verification is skipped (intended for a loopback gateway).
export IRONCLAW_MODEL_GATEWAY_URL="http://x:aoc_<your-onecli-agent-token>@127.0.0.1:10255"
export IRONCLAW_MODEL_GATEWAY_HOSTS="chatgpt.com"

# No ANTHROPIC_API_KEY needed — the gateway is the only credential path. Make the
# default backend Codex so every agent uses it out of the box:
export IRONCLAW_DEV_PROVIDER=codex
export IRONCLAW_DEV_MODEL=gpt-5.5

ironclaw-controlplane --api-addr 127.0.0.1:8787   # (+ your other flags)

ゲートウェイを設定した場合、そのゲートウェイが提供するホストのキーも設定しないでください。ゲートウェイが認証情報の経路となり、コントロールプレーンはゲートウェイのホストに対して何も注入しません。docker compose では、ゲートウェイがコンテナから到達可能である必要があるため、127.0.0.1 の代わりに host.docker.internal:10255（Docker Desktop）を使うか、OneCLI とコントロールプレーンを同じ Docker ネットワークに配置してください。

100％ローカルモデルを実行する（Ollama、LM Studio、vLLM）— クラウドキー不要

IronClaw をセルフホストの OpenAI 互換エンドポイントに接続すると、スタック全体をご自身の マシン上で クラウド認証情報ゼロで実行できます。マシンの外にデータが送信されることはありません。Ollama、LM Studio、vLLM、 llama.cpp はすべて OpenAI の /v1 API を公開しています（Ollama は http://localhost:11434/v1）。

ollama pull llama3.2                                # 1. run a model locally
export IRONCLAW_LOCAL_MODEL_URL=http://localhost:11434/v1
export IRONCLAW_LOCAL_MODEL=llama3.2                # 2. point IronClaw at it
ironclaw-controlplane --dev --api-addr 127.0.0.1:8787   # 3. chat — no API key

これによりローカルホストが許可リストに登録され、平文 HTTP で接続されます（これらのサーバーは TLS を提供しません）。また、デプロイ時のデフォルトモデルになるため、プロバイダーが固定されていないすべてのエージェントグループでローカルモデルが実行されます。キーは不要です。キーを必要とするまれなローカルサーバー（例：保護された vLLM）を使う場合に限り、IRONCLAW_LOCAL_MODEL_KEY を設定してください。docker compose では、サーバーは コントロールプレーンコンテナから到達可能である必要があるため、localhost の代わりに http://host.docker.internal:11434/v1（Docker Desktop）を使用してください。手順の詳細については、**100％ローカルモデル（Ollama）で IronClaw を実行する**をご覧ください。

エージェントごとにプロバイダーを選択する

IRONCLAW_DEV_PROVIDER / IRONCLAW_DEV_MODEL は、プロバイダーが固定されていないすべてのエージェントグループに対する、デプロイ全体のデフォルトを設定します（環境変数名には DEV_ 接頭辞が残っていますが、デプロイ全体に適用されます）。エージェントごとに選択するには、他の設定変更と同様、ゲートウェイの承認を受けて変更します。

ironctl agent create --name "Codex Bot" --provider codex  --model gpt-5.5
ironctl agent create --name "GPT Bot"   --provider openai --model gpt-4o
ironctl agent create --name "Local Bot" --provider local  --model llama3.2   # uses IRONCLAW_LOCAL_MODEL_URL

--provider に指定できる値は、anthropic（デフォルト）、openai、openrouter、codex、gemini、 vertex、local（セルフホストの OpenAI 互換エンドポイント — Ollama/LM Studio/vLLM/llama.cpp）、および mock（デモとテスト用の決定論的なオフラインバックエンド）です。それぞれ、model-proxy の許可リストに登録されたアップストリームに対応します。codex は chatgpt.com を対象とし、デフォルトで gpt-5.5 モデルを使用します。local は IRONCLAW_LOCAL_MODEL_URL のループバックホストを引き継ぎます。

設定

• 状態は --state-dir の下に保存されます。内容は、永続的なゲートウェイ変更ストア（再起動後も保持）、追記専用 JSONL 監査ログ、ホストのキーストアです。
• シークレットはホスト上だけに保持されます。モデル認証情報（Anthropic / OpenAI / OpenRouter のキー、または OneCLI などの認証情報ゲートウェイ — モデルプロバイダーを参照）は、ホストの modelproxy によって送信先のモデル呼び出しに適用されます。サンドボックスからこの情報を見ることはできず、network=none に設定されています。セッションごとの 256 ビットキーはホストで生成・保持され、起動時に tmpfs 経由でサンドボックスに渡されます。環境変数経由で渡したり、イメージに埋め込んだりすることはありません。
• メッシュ。 --api-addr を Tailscale インターフェースにバインドし、他のすべてのインターフェースでは API ポートをファイアウォールで遮断してください。deploy/README.mdを参照してください。

開発

make build     # go build ./...
make test      # go test ./...
make vet       # go vet ./...
make fmt       # gofmt -w .

暗号化 SQLite の CGo パスはゲートされていますが、標準ライブラリのみのツリーですべてのテストに合格します。ブラックボックスの振る舞いテストスイートは test/parity/ にあり、ルーティングのファンアウト、エンゲージモード、セッション解決、配信の重複排除、ゲートウェイの必須承認フロー、マウントをまたぐライブポーリング仕様を、観測可能なサーフェス（2 つのキューと API）のみを通じて検証します。

凍結されたコントラクト。 internal/contract/** は両側がインポートする唯一の接点であり、凍結されています。変更には docs/contract.md に記載する日付入り RFC と、両 CODEOWNERS の承認が必要です。ここでの不整合はビルドエラーではなく、実行時に復号やルーティングがサイレントに失敗する形で表面化するため、厳格に凍結しています。CONTRIBUTING.mdを参照してください。

リポジトリの構成

ironclaw/
  cmd/
    controlplane/   # host daemon entrypoint
    sandbox/        # in-sandbox agent entrypoint
    ironctl/        # admin CLI
  internal/
    contract/       # FROZEN SEAM — shared types, schema, crypto, gateway protocol
    host/           # control-plane: api gateway isolation router delivery sweep keys channels modelproxy registry scheduling queue
    sandbox/        # sandbox: loop provider tools queue
  api/              # control-plane API reference
  deploy/           # host install script + notes (gVisor, containerd, Tailscale, systemd)
  docs/             # architecture, threat-model, contract (+ RFC log), building
  test/parity/      # black-box behavioral suite over the queues + API

セキュリティ

IronClaw は、サンドボックス内のエージェントが侵害される可能性を前提とし、権限を昇格できないように境界を設計しています。脅威と対策の全一覧は docs/threat-model.md に記載されています。主な内容は次のとおりです。

• コンパイル済みの Go を使用し、サンドボックス内にインタープリターはありません → エージェントが自身のソースコードを読み取ったり編集したりすることはできません。
• すべての設定変更は、必須のゲートウェイ → 決定論的な検証チェーン → 人間による承認 → 冪等な適用の順に処理されます。未承認のアクション経路はありません（従来の script フィールドによる RCE の種類は、設計上排除されています）。
• セッションごとに暗号化されたキューを使用し、最小権限のアクセスを 3 つの方法で強制します（Go のインターフェース分離、PRAGMA query_only、読み取り専用の OS バインドマウント）。
• network=none のサンドボックスを使用し、モデルへの呼び出しは宛先の許可リストを備えたホストプロキシ経由に限定されます。

サプライチェーンについて、問題点をそのまま記録しています： 公開済みのコンテナーイメージの 1 つには、緑色の SLSA 来歴ステートメントが 2 つ付いていますが、正しいのはそのうち 1 つだけです。取り消すことができなかったため、その事実を記録しました： コンテナーイメージの 1 つには、緑色の来歴ステートメントが 2 つ付いています。正しいのはそのうち 1 つだけです。 では、ダイジェスト、緑色の gh attestation verify が必要でありながら十分ではない理由、そしてご自身のリリースパイプラインで確認すべきことを説明しています。

脆弱性を報告する場合は、公開 issue ではなく、非公開のセキュリティアドバイザリを作成してください。

ロードマップ

最新のロードマップはドキュメントサイトにあります： 1.0 への道のり — 唯一の正式な情報源です。ステータスが一目でわかる表とカテゴリとの比較を含め、1.0 に向けた 製品 の道のり（一般公開、ウェブ UI、チャネル、サプライチェーンの信頼性）を追跡しています。貢献者向けの簡潔な概要（方向性、1.0 の意味、協力を求めるテーマ）については、ROADMAP.md をご覧ください。以下のチェックリストは、セキュリティバックエンドのエンジニアリング構築ログ（Wave 0〜5）と、その後に行われた強化をまとめたものです。

• アーキテクチャと脅威モデル
• コンパイル可能な骨格：固定された契約、コントロールプレーンとサンドボックスのスタブ、CI
• インメモリバックエンド上のコントロールプレーン（ルーティング、ゲートウェイ、分離仕様、鍵の保管、配信、スイープ）
• サンドボックス（エージェントループ、モデルプロバイダー、キューアクセス、ツール）
• 暗号化 SQLite キューバインディング（RFC-0001）— セッションごとのライブ暗号化キュー
• 暗号化バックエンド上のマウント間ライブポーリング統合
• サンドボックス rootfs のプロビジョニング（プラグイン可能）＋グループごとの永続的なワークスペース／メモリ＋イメージの信頼ポリシー検証
• 具体的なチャネルアダプター：Telegram、Slack、Discord
• レジストリ管理 HTTP API ＋ ironctl のリソースサブコマンド
• 対話型 ask_user_question ＋タスク管理ツール（一覧表示／キャンセル／一時停止／再開／更新）
• エンドツーエンドのライフサイクル統合テスト（実際のスタック上でのフェイクアイソレーター／プロバイダー）

本番環境向けの強化（Wave 4）— デーモンに統合済み：

• 永続的／プラグイン可能なマスターキー保管（ファイル封印型キーストア＋KMS 接続点）— 接続済み
• Prometheus メトリクス（/metrics）と構造化（slog）ロギング — 接続済み
• ホストの再起動に対するクラッシュループバックオフ＋サンドボックスプロバイダーのバックオフ／サーキットブレーカー — 接続済み
• モデルプロキシのレート上限＋監査ログ＋シークレットの秘匿化 — 接続済み
• デーモンへの組み込み — 上記のサブシステムを cmd/controlplane に統合
• 本番環境向けデプロイユニット：systemd サービス＋launchd plist、インストーラー、コンテナーイメージ、docker compose
• エントリーポイントで API サーバーの強化オプション（TLS、レート制限、ボディサイズ制限、/readyz ゲート）を有効にする — api.With* オプションは存在しますが、まだ接続されていません
• プロビジョニング済みの署名付きイメージ環境で実際の runsc を起動する

リファレンス設計を超えて実装済み：

• 承認済み外部ホスト向けのエグレスブローカー — デフォルトで拒否、監査記録あり、サンドボックスは network=none のまま密閉（Unix ソケット経由でホストが仲介）。web_search ツールを支えます
• 同じ強化済み Isolator インターフェースの背後にある Kata Containers 分離バックエンド
• エージェント間（a2a）メッセージング＋承認ゲート付き create_agent（RFC-0004）
• 複数のモデルプロバイダー — Anthropic、OpenAI、OpenRouter — エージェントグループごとに選択可能
• MCP サーバー — ホストが仲介し、ツールごとに人間の承認を得た権限付与
• /ui/ にあるプライベートなメッシュ専用ウェブコンソール
• 最初の3つ以外のチャネルにも対応 — WhatsApp、Email/SMTP、Matrix、Google Chat、Microsoft Teams、Signal、iMessage、Webhook、および製品内のウェブチャットプレイグラウンド（配信先は合計12種類）

設計承認が必要（実装済み、デフォルトでは無効）：

• ゲートウェイの自動承認ポリシー＋RBAC — 検証者／承認者として実装されていますが、デフォルトでは無効です。オペレーターが有効にするまでは、人間による必須承認のみが有効です

コミュニティ

質問、アイデア、「これはバグ？ それとも使い方を間違えている？」といった疑問は、 GitHub Discussions にお寄せください。プロジェクトの Q&A、設計に関する議論、成果の共有の場であり、メンテナーが最初に回答する場所です。

• プロジェクトを始めたばかりですか？ 全体像を知りたいですか？ ドキュメントサイト をご覧ください。アーキテクチャ、脅威モデル、 クイックスタート、チャネル、スキルを、ひとつのナビゲーションしやすい場所にまとめています。
• バグを見つけた、または機能をリクエストしたいですか？ issue を作成してください。
• セキュリティに関する報告ですか？ 公開 issue は作成せず、SECURITY.md に従ってください。
• コードに貢献したいですか？ good first issue から始めるか、 対応可能なもの （good first issue + help wanted）に絞ってください。小規模で独立しており、メンターによるサポートもあります。また、すべてに、up-for-grabs.net や goodfirstissue.dev などのコントリビューター向けボードがインデックスする標準ラベルが付いています。最も取り組みやすいのは、最も独立性の高い2つのサブシステム、ironctl scan （封じ込めのスコアリング、internal/host/scan/）と 隔離スコアのデータセット（examples/isolation-survey/、 データのみの変更）です。ワークフローについては貢献方法をご覧ください。
• 初めて参加しますか？ プロジェクトに関わるすべての方に、 行動規範 に従って、お互いを尊重することをお願いしています。

コミュニティ全体を GitHub 上で運営しています。登録が必要な Discord や Matrix はありません。 Discussions がリアルタイムの交流の場です。カテゴリを購読して最新情報を追い、リポジトリをウォッチしてお知らせを受け取ってください。

貢献方法

CONTRIBUTING.md では、契約凍結ルール、コードの構成 （コントロールプレーンとサンドボックスのツリーは、凍結された境界に対してビルドされます）、脆弱性の報告方法 （SECURITY.md）、行動規範、プルリクエストの作成方法を説明しています。 初めての方は、good first issue （または、対応可能な help wanted の issue）に取り組んでみてください。 GitHub 以外にアカウントを作成したり、登録したりする必要はありません。

ライセンス

IronClaw はデュアルライセンスです。詳細は LICENSING.md をご覧ください。

• オープンソースでの利用には GNU AGPLv3 が適用されます。変更を加えた IronClaw をネットワークサービスとして実行すると、AGPL のコピーレフト条項が適用され、ユーザーに対応するソースコードを提供する必要があります。
• AGPL の義務を負わずにクローズドソース／プロプライエタリな用途で利用する場合は、商用ライセンス をご利用ください。LinkedIn でメンテナーにお問い合わせください（Omer Zamir または Topaz Aharon）。

© 2026 IronSecCo