ハードウェア分離という土台
smolvmのセキュリティを支える第一の柱は、アーキテクチャ解説で述べたVM単位のハードウェア分離です。各ワークロードは専用カーネルを持つマイクロVMの中で実行され、ホストカーネルとはハイパーバイザの境界で隔てられます。コンテナエスケープの主要経路であるカーネル脆弱性の悪用は、smolvmにおいては「ゲストカーネルを掌握しても、その先にハイパーバイザの壁が残る」構図になります。
さらにlibkrunは最小構成のVMMであり、レガシーデバイスのエミュレーションを持たないため、QEMUで繰り返し発見されてきたデバイスエミュレータ起因の脆弱性クラスとも縁が薄い設計です。攻撃面が小さいことは、監査対象が小さいことでもあり、セキュリティレビューの負荷軽減にも寄与します。
既定オフのネットワークとegress許可リスト
第二の柱はネットワーク制御です。smolvmのVMは既定でネットワークが無効であり、何も指定しなければ完全にオフラインのまま実行されます。これは「まず全部許可し、後から絞る」一般的なコンテナ運用とは逆の、デフォルトデナイ（既定拒否）の思想です。
--netで有効化した場合も、--allow-host（Smolfileでは[network] allow_hosts）で列挙したホストへのegressのみが許可されます。加えて対応プロトコルはTCP/UDPに限定され、ICMPは通りません。
この仕組みは、悪意あるコードやマルウェアの動的解析、依存パッケージのサプライチェーン検証において特に有効です。「パッケージレジストリだけを許可してインストールを観察する」「完全オフラインで挙動を確認する」といった実験計画を、コマンドフラグまたはSmolfileの1行で表現できます。
秘密鍵をゲストに渡さないSSHエージェント転送
開発用途では、VM内からプライベートリポジトリをgit cloneしたい場面が頻繁にあります。安易な解決策は秘密鍵をVMにコピーすることですが、これはサンドボックスに秘密情報を持ち込む行為であり、隔離の意味を損ないます。
smolvmのSSHエージェント転送（[auth] ssh_agent = true）は、秘密鍵がゲストに一切入らない設計です。ゲスト内のSSHクライアントが発行する署名要求だけがホスト側エージェントへ転送され、署名結果のみが返されます。この境界はハイパーバイザによって強制されるため、ゲスト内のコードがどれほど悪意を持っていても、鍵そのものを読み出すことはできません。
AIコード実行サンドボックスとしての適性
AIエージェントがコードを生成し、実行し、結果を見て修正する——この開発様式の普及により、「信頼できないコードを安全に実行する場所」の需要が急拡大しています。AI生成コードは悪意がなくても、誤ってファイルを破壊したり、意図しない外部通信を行ったりする可能性を常に抱えています。
smolvmはこの要件に対して、複数の防御層を標準で積み重ねています。
200ミリ秒未満の起動時間は、この文脈で決定的に重要です。AIエージェントは1つのタスクで何十回もコードを実行するため、実行のたびに数秒待つサンドボックスでは対話のテンポが成立しません。smolvmなら実行ごとに新品のVMを起動して捨てる運用が現実的な速度で回り、前回実行の副作用が次回に混入する事故も原理的に発生しません。SDKとしてアプリケーションに組み込めるため、自社のAIエージェント製品へのサンドボックス機能内蔵にも適しています。関連する考察はブログ記事でも展開しています。
運用ガイドライン
smolvmをセキュリティ目的で導入する際の実務上の指針をまとめます。
- ネットワークは目的別に最小化する: 「とりあえず--net」を避け、必要なホストだけを
allow_hostsに列挙します。標準の許可セットをSmolfileテンプレートとして組織で管理すると統制が容易です。 - 秘密情報はVMに入れない: SSHはエージェント転送を使い、APIキー等は実行時に必要最小限のみ渡す方針を徹底します。
- 信頼できないコードは一時VMで: 永続マシンではなく
machine runを使い、実行のたびにクリーンな環境を用意します。 - ボリューム共有は読み取り範囲を意識する: 共有ディレクトリはゲストから書き込める領域です。ホストの重要ディレクトリを不用意に共有しないでください。
note
ハードウェア分離は万能ではありません。共有したボリューム、許可した通信先、VMに渡した認証情報は分離の「例外」として自ら開けた穴です。smolvmの価値は、その穴を明示的・宣言的に管理できる点にあります。
