セキュリティモデル

Multica のタスクが実行マシン上で何にアクセスできるのか、そして本当の分離境界がどこにあるのかを説明します。

エージェントがタスクを受け取ると、デーモンは AI コーディングツール（Codex、Claude Code など）を子プロセスとして起動します。このプロセスが何に触れられるかを理解することが、セキュリティモデルのすべてです。

境界はデーモンを実行しているユーザー

デフォルトでは、タスクはデーモンを実行している OS ユーザーの全権限で動きます。そのユーザーが読み書きできるファイルはすべて読み書きでき、そのユーザーの認証情報を利用でき、ネットワークにも制限なくアクセスできます。

Multica はファイルシステムのサンドボックスを一切保証しません。現時点で例外は 1 つだけ、Windows で Codex のネイティブサンドボックスを明示的に有効にした場合です。そもそもどのプラットフォームと設定の組み合わせでサンドボックスが効くかはツールのバージョンとともに変わる互換性上の詳細です。すべてのタスクをサンドボックスなしとみなし、境界はデーモンの外側に用意してください。

Multica はファイルシステムのサンドボックスを提供しません。デーモンを個人アカウントで動かしている場合、タスクは SSH 秘密鍵を読み、シェルの設定を書き換え、ドキュメントを削除できます。分離はデーモンの外側に用意する必要があります。

これは意図的な設計です。エージェントには依存関係のインストール、ビルドの実行、クラウド CLI の利用が求められ、これらのツールは通常のホームディレクトリがあることを前提にしています。中途半端なファイルシステムサンドボックスは、こうした作業を診断しづらい形で壊します（ツールが「ログインしていません」と言う、あるいは黙って別のアカウントを使う）。しかも最も重要な部分は守れません。タスクが認証情報を読み取ってネットワーク経由で送信することは止められないからです。

そのため Multica は自らを境界とは称しません。外側に境界を用意してください。

推奨構成

インフラに合うものを選んでください。軽いものから順に挙げます:

専用 Unix ユーザー。 multica ユーザーを作成し、エージェントに必要なリポジトリと認証情報だけを与えて、そのユーザーでデーモンを実行します。自分のアカウントは影響を受けません。
コンテナ。 必要なマウントとシークレットだけを与えたコンテナ内でデーモンを実行します。
仮想マシン。 分離は最も強固ですが、マシンの用意が必要です。

いずれの場合も、その環境から到達できる認証情報は「エージェントが使う可能性のある認証情報」として扱ってください。トークンの権限は最小限にし、個人の SSH 鍵ではなく用途別のデプロイキーを使い、無関係な本番環境の認証情報をそのユーザーのホームに残さないようにします。

Multica が実際に分離しているもの

以下は実在する分離ですが、利便性と影響範囲の縮小のためのものであり、能動的に脱出を試みるタスクに対するセキュリティ境界ではありません:

タスクごとの作業ディレクトリ。 各タスクは ~/multica_workspaces/ 配下に専用の workdir を持ち、同時実行のタスクが同じチェックアウトで衝突しません。
タスクごとのエージェント状態。 Codex タスクはタスクスコープの CODEX_HOME を持ち、設定・セッション・スキルを保持するため、~/.codex/ を汚しません。
タスクスコープの API トークン。 タスクに渡される MULTICA_TOKEN はサーバー側でそのエージェントとタスクに紐づけられており、タスクが Multica API 上であなたや他のエージェントとして振る舞うことはできません。

境界ではないもの

コーディングツール自身のサンドボックスと承認設定。 Multica はエージェントを無人で実行するため、承認要求は自動的に応答されます。デフォルトの経路ではファイルシステムのサンドボックスも無効で、Codex は sandbox_mode = "danger-full-access"、Claude Code は --permission-mode bypassPermissions で動作します。例外は Windows です。Codex のネイティブサンドボックス（windows.sandbox = "unelevated" または "elevated"）を明示的に設定した場合、Multica はそのオプトインを尊重し、該当タスクでは workspace-write を維持します。使える場面では有効ですが、1 つのプラットフォームの 1 つのツールに限られる話であり、デーモンユーザーの権限をどこまで絞るべきかという判断は変わりません。
HOME ディレクトリの構成。 タスクはデーモンユーザーの実際の HOME と XDG_* 変数を引き継ぎます。だからこそ gh、aws、kubectl、gcloud、glab などのホスト CLI がシェルと同じようにタスク内で動作します。同時に、そのホーム配下のすべてに到達できるということでもあります。

Linux では以前、Codex タスクは workspace-write サンドボックスとタスクごとにリダイレクトした HOME の下で実行されていました。この仕組みは削除されました。ホスト CLI がタスク内で未設定状態になるうえ、書き込みしか制限しないため、認証情報の読み取りと持ち出しは元から防げていなかったからです。現在 Linux は macOS と Windows のデフォルトと同じ挙動です。

タスクが実際にどのモードで動いたかを確認する

タスクがサンドボックスなしで起動すると、デーモンは warn レベルでログを出します:

multica daemon logs --lines 200 | grep "codex sandbox"

Codex の実効設定を確認するには、そのタスクの CODEX_HOME にある config.toml の管理ブロックを見てください。# BEGIN multica-managed と # END multica-managed に挟まれた部分は、実行のたびにデーモンが書き込みます。