【#も読】AIエージェント時代のセキュリティ - 隔離・パーミッション制御（@yusuktan）

「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？

みなさんこんにちは。

「あの人も読んでる」、第8回目の投稿です。maguro (X @yusuktan)がお届けします。

今回のテーマ: AIエージェント時代のセキュリティ

前回の投稿で、以下の内容をご紹介しました。

• OpenAIのコマンドラインツールであるcodexがRustでの書き換えを進めていること
• 書き換えの目的の1つが、Linuxのlandlock、macOSのseatbeltといった、OSが提供するセキュリティ機構を利用するためであること

このように、OpenAI Codex CLIチームは、自律的に動くAIに対しての与えるパーミッションを最小限にしようと試みていることが分かります。

この他にもAIとセキュリティという問題に対してさまざまな角度からアプローチがなされています。今回はそのような取り組みのうち、僕がおもしろいと思ったものを2つ紹介しようと思います。

1. microsandbox: AI生成コードのための軽量かつ強力に隔離されたサンドボックス環境
2. Cage4Deno: Denoから立ち上げられるサブプロセスに対してパーミッション制限を適用する実験的な試み

microsandbox

https://docs.microsandbox.dev/

1つ目は microsandbox です。これはAI生成コードなど、必ずしも信頼できないコードを実行するための環境として、

• VMレベルで隔離されている
• なおかつ高速な起動時間

というサンドボックスを提供するというものです。この技術の優位性を強調するため、他の従来からある技術との比較をしてみます。

まず、Dockerなどのコンテナレベルでの分離との違いを見てみましょう。コンテナレベルの分離では、OSのカーネルは共有されています。そのため隔離のレベルとしては必ずしも十分ではなく、コンテナ内で実行するコードが巧妙に仕組まれた攻撃を含んでいる場合、ホスト環境側に影響が及ぶ可能性があります。実際、このように「コンテナ内からホスト側にアクセスすることのできる」脆弱性―container escape―はこれまでにいくつも報告されています。（CVE-2024-21626など）

より安全な隔離として、伝統的なVMを利用するという方法が考えられます。この方式ではホストOSとゲストOSが分離されるため、安全性はより高まります。しかし起動に時間がかかるため、気軽に立ち上げたり停止したりするという使い方には向いていません。

microsandboxはこれら2つの良い点を兼ね備えています。VMレベルの隔離であるため安全度は高く、さらに200msほどという高速な起動時間を誇っています。これらの特長は、技術的にはlibkrunを利用することで実現されているようです。

加えて、MCPサーバーを内蔵しており、AI時代における新たな標準も的確にカバーしているのが興味深いです。今後登場するツールたちはMCPをサポートすることが「当たり前品質」になるのかと思わされます。MCPサポートにより、例えばClaudeを使って「マージソートとクイックソートをPythonで実装して実行時間を計測し、どちらがどれくらい早いのか教えて」のように指示を出せば、AIがコードを実装し、それを安全に隔離されたサンドボックス上で実行、計測までワンストップでやってくれるようになります。AIが実装したコードに万が一脆弱性があったとしても、隔離環境での実行のため安心できます。

Cage4Deno

続いては、イタリアのベルガモ大学の研究グループにより2023年に発表された論文です。これ自体は2年前のものですが、生成AIによるAgenticなコーディングが 爆発的に広がりを見せる今、おもしろみを増している研究テーマだと感じたため、紹介していきます。

https://dl.acm.org/doi/pdf/10.1145/3579856.3595799

この論文は、次世代のJavaScript/TypeScriptランタイムであるDenoをベースに使い、そのセキュリティをさらに強固なものにすることを目指しています。

まずDenoのセキュリティ機構について簡単に復習しておきます。Denoではファイルシステムへのアクセスやネットワークアクセス、環境変数へのアクセス、サブプロセスの起動など、さまざまな操作に対して「パーミッション」が要求されます（--allow-read, --allow-write, --allow-net, --allow-env, --allow-run など）。ただしサブプロセスを起動する --allow-run に関しては、サブプロセスとして起動されたプロセスに対してパーミッションの制約を課すことはできないという制限がありました。つまり --allow-run が与えられてしまうと、事実上攻撃者にとっては「何でもし放題」ということになってしまうということです。

この論文ではこの点に着目し、Denoから起動されるサブプロセスに対してもセキュリティ制御を適用する手法と実装について述べています。具体的には、前回のも読でも登場したLinuxのlandlockと、eBPFを組み合わせることによって実現が可能ということです。

Denoユーザーの立場から見ると、この機能を使うためのインタフェースは以下のようになります。まず「ポリシーファイル」と呼ばれるファイルにJSON形式でパーミッションの詳細を記述しています。以下は tar コマンドに対するポリシーの一例です。

{
  "policies": [
    {
      "policy_name": "tarPolicy",
      "read": [
        "/usr/bin/tar",
        "/home/user/input.tgz"
      ],
      "write": [
        "/home/user/output"
      ],
      "exec": [
        "/usr/bin/tar"
      ],
      "deny": [
        "/home/user/output/misc"
      ]
    }
  ]
}

続いて、Denoでサブプロセスを立ち上げるためのAPI Deno.Command に対して、以下のようにポリシーを渡します。

const cmd = new Deno.Command("tar", {
  args: ["xzf", "input.tgz", "-C", "output"],
  policyId: "tarPolicy", // 論文が提案する拡張
});

これで、Denoから立ち上がるサブプロセス tar に対して、指定したパーミッションが適用されます。

Denoユーザーの立場からすると、landlockやeBPFなど具体的な実装の詳細を知る必要なく手軽に利用できるAPIになっていることが分かります。

この論文で提案されている仕組みは、Deno本体には導入されていません。もし導入するとしても、Linux以外はどうするのかといった議論や、breaking changeを注意深く適用していくためのロードマップなど、課題は多くあります。ただDenoの「セキュリティファースト」な思想を自然に拡張する素晴らしい提案だと感じました。

おわりに

今回は、AI時代におけるセキュリティの課題に対する2つのアプローチをご紹介しました。microsandboxはVMレベルの隔離と高速起動を両立させることで、AI生成コードの安全な実行環境を提供します。一方、Cage4DenoはDenoのセキュリティ思想をサブプロセスにまで拡張する野心的な試みです。

「AIが自律的に動作する世界」において、いかにして安全性を担保するか。激動の過渡期にある今、AIの利便性を享受するだけではなく、少し立ち止まって足場を固めてみるのも良いのかもしれません。

また次回、おすすめコンテンツを紹介していきます。お楽しみに！

maguroさんの「も読」過去記事

• Rustの実践的な採用事例をながめる(6月13日公開)
• DockerなどのコンテナにおけるSIGTERMの取り扱い(5月30日公開)
• ライブコーディング視聴のすすめ(5月19日公開)
• 生成AIを使うか、使われるか - 学習を加速するための活用(5月8日公開)
• Rustの学習の難しさと取るべきルート(4月17日公開)
• MCPことはじめ / MCPサーバーのセキュリティリスク(4月4日公開)
• n月刊ラムダノート、実用Raft(3月21日公開)