AWSがAIエージェントの「野放し問題」に本気で対処 — 操作履歴に基づくポリシー制御で「10分に3回まで」を外部から強制する実行環境「Strands Box」

10月8日、AWSが「Introducing Strands Box: AI agent sandboxes powered by Dogwood」と題した記事を公開した。この記事では、AIエージェントの安全な実行環境を実現するオープンソースプロジェクト「Strands Box」の設計思想と実装について詳しく紹介されている。

AIエージェントが「野放し」になっている問題

AIエージェントはファイルの読み書き、シェルコマンドの実行、コード生成・実行、API呼び出しといった幅広い操作を行う。その自律性こそがエージェントの価値だが、同時に最大のリスクでもある。人間のレビューなしにすべての操作を承認する、いわゆる「YOLOモード」で動くエージェントが増えており、作業ディレクトリの外をさまよったり、危険なコマンドを実行したり、本来アクセスすべきでないクレデンシャルに触れるケースが現実に起きている。

従来の解決策はコンテナやmicroVMによる隔離だ。しかしこれは「何にアクセスできるか」の境界を引くだけで、「その中で何をしてよいか」というコンテキストに依存したルールは別途実装する必要がある。本番インシデントを調査するエージェントに、ログの読み取りは許可しつつ設定変更は禁止する、といった制御をコンテナだけで実現するのは難しい。

Strands Boxの構造：「隔離」と「ポリシー」の2層

Strands BoxはApache 2.0ライセンスのオープンソースプロジェクトとして開発者プレビューで公開された。構造は2層に分かれる。

第1層：隔離（Containment）
macOSのSeatbeltなどOSレベルの機能を使い、エージェントがホストマシンおよびネットワーク上で到達できる範囲を定める。これが「ハードな境界」となる。

第2層：ポリシー（Policy）
隔離の内側で、エージェントが具体的に何をしてよいかを統制する。ポリシーの評価には、以前公開されたオープンソースのポリシー言語**Dogwood**とDogwood Local Engineを使う。

DogwoodはAWSが独自に設計したポリシー記述言語で、Cedarと構文上の類似点を持つが、AIエージェントの操作履歴を扱うためのtemporal節など、エージェント制御に特化した拡張が施されている点が大きく異なる。permit/forbidによるallow/deny判定を基本としつつ、when節で条件を記述するスタイルは、Cedar経験者にとって比較的読みやすい構文になっている。

ポリシーが適用される強制ポイントは4つだ：

ネットワーク出口（Egress Gateway）：全アウトバウンドトラフィックを経由するプロキシ
Pythonインタープリタ：Monty for Pythonを採用
Shellインタープリタ：Strands Shellを採用
MCPブローカー：Model Context Protocolサーバーへのアクセスを管理

重要な設計上の特徴は、どの強制ポイントを経由した操作も統一されたイベント形式で記録される点だ。シェルコマンドからのファイル読み取りもPythonスクリプトからのファイル読み取りも、同じfs:readイベントとして扱われる。これにより「カスタマーデータディレクトリのファイルを読んだ後は、アウトバウンドHTTPリクエストをブロックする」といったルールを、ツールの種類を問わず書けるようになっている。

最も面白い機能：時間を考慮したポリシー（Temporal Policy）

単発の操作ごとにallow/denyを判断するだけなら、既存のツールでも対応可能だ。Strands Boxが際立つのは、エージェントがこれまでに何をしたかの履歴に基づいてポリシーを評価できる点にある。

記事が示す具体例が秀逸だ。本番インシデントを調査するエージェントが、Slackの障害対応チャンネルに進捗を投稿するケースを考える。エージェントが毎回の発見ごとに投稿したり、失敗と誤判断して再投稿を繰り返したりすると、人間の投稿が埋もれてしまう。そこで「10分間に3回までしか投稿できない」というレートリミットをポリシーで表現する：

@id("rate_limit_slack_posts")
forbid (principal, action == Box::Action::"http:request", resource)
when {
  context.input.host == "slack.com" &&
  context.input.method == "POST" &&
  context.input.path == "/api/chat.postMessage"
}
when temporal {
  (count for (t: Timepoint). where (
      formerly within 10m (
          Box::Action::"http:request"::response{
              input.host: "slack.com",
              input.method: "POST",
              input.path: "/api/chat.postMessage",
              output.status: 200
          } && tp(t)
      )
  )) >= 3
};

temporal節は「過去10分以内に200レスポンスを伴うSlack投稿が3回以上記録されていれば、次の投稿リクエストを拒否する」という意味になる。エージェント自身がカウントを覚えている必要はなく、Boxが外部から強制する。formerly within 10mという構文がDogwood固有の時間軸クエリであり、通常のポリシー言語では別途ストレージや集計ロジックを用意しなければ表現できない条件をポリシーファイル内で完結させられる点が、この言語設計の核心だ。

コンテナではなくOSレベルの隔離を選んだ理由

「なぜDockerやmicroVMではないのか」という疑問は当然浮かぶ。AWSの回答は明快だ。コンテナやmicroVMはゲストOSという別環境を用意・維持するコストが発生し、ローカルファイルやツールの公開方法についても別途判断が必要になる。Strands Boxは開発者の既存環境の中でエージェントを動かすことを目指しており、OSレベルの隔離でハードな境界を引きつつ、ポリシーで細かく統制するアプローチを選んだ。

なお、Shellインタープリタ・Pythonインタープリタ・MCPブローカーはサンドボックスの外側で動作する。これはポリシー強制を担うコードがサンドボックス内で改ざんされないようにするための意図的なトレードオフであり、Boxが信頼するコンピューティングベース（TCB）が広くなるという代償を伴う点も明示されている。

クレデンシャルの扱い

Egress Gatewayはクレデンシャル管理も担う。エージェントにはプレースホルダートークンを渡し、許可されたリクエストがゲートウェイを通過する際に本物のシークレットと差し替えて転送する。実際のクレデンシャルはエージェントの環境に入らない。

対応する認証方式はBearer Token、カスタムヘッダー、HTTP Basic、クエリパラメータ、そしてAWS SigV4だ。AWS CLIを使う場合は、エージェントはAWSクレデンシャルを受け取らず、ゲートウェイがホスト上のAWSプロファイルからセッションクレデンシャルを読み取って各リクエストに署名する。

設定の全体像

Boxの設定はbox.toml（環境・ツール・クレデンシャルの定義）とpolicy.dw（Dogwoodルール）の2ファイルで構成される。Box自体はハーネス非依存で設計されており、起動は以下の1コマンドだ：

box run --config box.toml

今後の方針として、macOSの将来バージョンで追加予定のEndpoint Security拡張など、OSの新機能を積極的に採用してポリシーのカバレッジを広げていく旨が明記されている。

詳細はIntroducing Strands Box: AI agent sandboxes powered by Dogwoodを参照していただきたい。