OsaurusのAgent Sandboxを実際に調べてみた
macOSとの隔離はどこまで本物なのか
macOS向けAIエージェント環境「Osaurus」には、Agentがコマンドやコードを実行するためのSandbox機能があります。
Osaurusの説明ではAppleのContainerization frameworkを利用したLinux環境で実行されることになっていますが、実際にどの程度macOSから隔離されているのかをShell Runnerから調査してみました。
結論から言うと、想像していた以上にしっかりした構成でした。
まず、本当にLinux VMで動いている
Shell RunnerからOSを確認すると、
Linux osaurus-sandbox 6.18.35 ... aarch64 GNU/LinuxOSは、
Alpine Linux v3.23でした。
つまりAgentが生成したshell commandをmacOS上で直接実行しているわけではありません。
Apple Silicon上で動作する独立したARM64 Linux環境です。
さらにOsaurusのProvision情報を見ると、Sandbox用として独自に、
- Linux kernel
- init filesystem
- 8GiBのroot filesystem
- Workspace
- Host bridge
- 仮想ネットワーク
などを管理していました。
重要なのは、OsaurusがAppleの container CLIを呼び出しているわけではないことです。
AppleのContainerization frameworkをアプリケーションから直接利用しているため、OsaurusのSandboxは container list などには表示されません。
Shell Runnerはrootではない
Shell Runnerから id を実行すると、
uid=1000(agent-<UUID>)
gid=1000(agent-<UUID>)となっていました。
つまりLLMから実行されるshell commandはrootではなく、Agent用に作られた一般ユーザーとして実行されています。
一方、VMのPID 1は、
sleep infinityで、こちらはUID 0、つまりrootでした。
構造としては、
Linux VM
│
├─ PID 1
│ └─ root
│
└─ Shell Runner
└─ uid=1000 agent-<UUID>となっています。
AgentにVMそのもののroot権限を渡しているわけではありません。
Agentには専用のHOMEが割り当てられる
Shell Runnerの $HOME は、
/workspace/agents/<Agent UUID>でした。
/workspace の中を見ると、
/workspace
├─ agents
│ ├─ <Agent A UUID>
│ │ ├─ SOUL.md
│ │ └─ plugins
│ │
│ └─ <Agent B UUID>
│ ├─ SOUL.md
│ └─ plugins
│
└─ sharedという構造になっています。
今回の環境ではOsaurusの「Agentごとの分離」設定を有効にしていないため、複数Agentのディレクトリ自体は同じWorkspace内から確認できました。
OsaurusにはさらにAgent単位で分離する設定も存在しますが、今回はOFFのため、そのモードについては検証していません。
macOSのホームディレクトリは見えない
Sandbox内から、
/Usersを確認すると、
No such file or directoryでした。
当然、
~/.sshも存在しません。
macOSのKeychainを操作する security コマンドもありません。
つまり少なくとも通常のLinux filesystem経由では、
~/Documents
~/.ssh
~/Library
macOS Keychainなどへ直接アクセスできる状態にはなっていません。
これはAgent Sandboxとして非常に重要なポイントです。
Linuxのroot filesystemも独立している
mount情報を確認すると、
/dev/vdb on / type ext4となっていました。
容量は約8GiBです。
つまりSandboxの / はmacOSのfilesystemではなく、Linux VM専用のext4 filesystemです。
一方、Workspaceだけは、
virtiofs on /workspace type virtiofsとなっています。
構造を単純化すると、
macOS
│
│ Osaurus管理領域
│
└── Workspace
│
│ virtiofs
▼
Linux VM
│
├─ / ← 独立したext4
│
└─ /workspace ← ホストとの共有領域となっています。
macOSのfilesystem全体をVMにmountしているわけではありません。
ホストとのファイル共有境界を /workspace に限定している設計と考えられます。
Host BridgeもAgentから直接触れないようになっている
さらに興味深かったのが、
/tmp/osaurus-bridge.sockです。
これはUNIX domain socketですが、所有者とpermissionは、
s--------- root rootつまり、
owner = root
group = root
permission = 0000でした。
一方、Shell RunnerはUID 1000の一般ユーザーです。
そのため通常のLinux permissionモデルでは、Agentがこのsocketへ直接接続することはできません。
さらに、
/run/osaurusというディレクトリも存在しますが、
Permission deniedとなり、Agentから内部を列挙できませんでした。
つまりHost Bridge関連と思われる内部機構とAgent実行環境の間にも権限境界が設けられています。
もう一つ謎のUnix socketが存在する
/proc/net/unix を確認すると、
/run/sockets/<UUID>.sockというSTREAM socketがLISTEN状態になっていました。
ところがAgentから、
/run/socketsをfilesystemとして確認すると存在しません。
また、通常のAgentプロセスのfile descriptorからも、このsocketとの明確な対応は確認できませんでした。
Apple ContainerizationまたはOsaurus内部のVM・ホスト間通信に利用されている可能性がありますが、今回の実測だけでは用途までは断定できませんでした。
ここはソースコードまで追わないと正確なことは言えません。
ネットワークもVMとして独立している
Sandboxのネットワークは、
eth0
192.168.66.2/24でした。
default gatewayは、
192.168.66.1です。
つまりmacOSと同じLAN interfaceを直接利用しているのではなく、
Agent
↓
Linux VM
192.168.66.2
↓
Virtual Gateway
192.168.66.1
↓
Host / Networkという仮想ネットワークになっています。
Osaurus側の設定でも、
network: outboundとなっていました。
そのためAgentから外部への通信は可能ですが、VM専用の仮想ネットワークを経由する構成になっています。
なお、今回の調査ではLAN内の他ホストへの到達性やネットワークフィルタリングの詳細までは検証していません。
実測から分かったSandbox構造
今回確認できた範囲をまとめると、おおよそ次のようになります。
┌─────────────────────────────┐
│ macOS │
│ │
│ Osaurus │
│ │ │
│ Apple Containerization │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Linux VM │ │
│ │ Alpine Linux │ │
│ │ │ │
│ │ /dev/vdb → / │ │
│ │ ext4 約8GiB │ │
│ │ │ │
│ │ Agent uid=1000 │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ /workspace/agents/ │ │
│ │ <UUID> │ │
│ │ │ │
│ │ eth0 │ │
│ │ 192.168.66.2 │ │
│ └────────┬────────────┘ │
│ │ │
│ virtiofs │
│ │ │
│ Osaurus Workspace │
│ │
└─────────────────────────────┘セキュリティ面で確認できたこと
今回の実測で確認できたのは以下です。
| 項目 | 結果 |
|---|---|
| Shell RunnerがmacOS上で直接動作 | しない |
| Sandbox OS | Alpine Linux |
| CPU Architecture | ARM64 |
| Shell Runner | 非root |
| Agent専用UID | あり |
| Agent専用HOME | あり |
macOS /Users |
見えない |
macOS ~/.ssh |
見えない |
| macOS Keychain CLI | 見えない |
| VM root filesystem | 独立ext4 |
| Hostとの共有 | /workspace がvirtiofs |
| Host Bridge socket | root所有・permission 0000 |
/run/osaurus |
Agentから列挙不可 |
| Network | VM専用仮想NIC |
| 外向き通信 | あり |
| Agent間の完全分離 | 今回は設定OFFのため未検証 |
もちろん「絶対安全」という意味ではない
ここは重要です。
VMで隔離されているからといって、Agentへ渡したデータまで安全になるわけではありません。
たとえば /workspace に、
.env
API key
秘密鍵
顧客データなどを置いてAgentから読み取れる状態にすれば、Agentも当然その内容を利用できます。
さらにSandboxにはoutbound networkがあります。
つまり、
「macOSのファイルを勝手に読む」ことと、
「Agentへ明示的に渡したファイルを外部へ送信できる」ことは別問題です。
VM isolationは前者に対する強力な防御になりますが、後者についてはAgentへ与えるfilesystem permissionやnetwork policy、利用するモデル・MCP・Pluginなども含めて考える必要があります。
またHost Bridgeの内部RPCや /run/sockets/<UUID>.sock の正確な役割については、今回のブラックボックス調査だけでは確定していません。
まとめ
今回一番確認したかったのは、
「AI Agentが生成したshell commandを、実はmacOS上でそのまま実行しているだけではないのか？」
という点でした。
結果としては、そうではありませんでした。
Osaurusは、
LLM / Agent
↓
Agent専用の非rootユーザー
↓
Alpine Linux VM
↓
独立したext4 root filesystem
↓
限定されたWorkspace共有
↓
仮想ネットワークという、かなり明確なSandbox境界を構築しています。
特に、
- Shell Runnerを非rootで実行
- macOSのHOMEを直接mountしない
- Linux rootfsを独立させる
/workspaceだけをvirtiofsで共有- Host Bridgeをroot権限側に置く
- Agent用HOMEを分離
- 仮想ネットワークを使用
という構成は、AI Agentに任意コードを実行させる環境としてかなり真面目に設計されている印象です。
今回はAgent単位の追加隔離をOFFにした状態で調査しましたが、それでも「Agent ↔ macOS」という最も重要な境界については、かなり明確な隔離を確認できました。
少なくとも「LLMにshellを渡してmacOS上で直接実行させているだけ」という実装とは、セキュリティモデルが大きく異なります。
今後さらに調べるなら、OsaurusのソースコードからHost Bridgeの実装を追い、osaurus-bridge.sock や /run/sockets/<UUID>.sock が具体的にどのRPCを提供しているのか確認すると、Sandboxの全体像がほぼ完成しそうです。