In Silico

AIエージェント

Strands Boxとは：操作の履歴で権限を決めるサンドボックスの仕組み

2026/10/28 （更新: 2026/11/3）

🤖 AIを使用して執筆

  • Strands Box
  • AIエージェント
  • サンドボックス
  • Dogwood
  • Cedar
  • Strands Shell
  • Monty
  • MCP
  • MicroVM
  • AgentCore
  • 実行履歴
  • 既定拒否
  • TCB
  • 履歴規則
  • 判定点
  • システムコール
  • 認証情報
  • git push
  • npm test
  • gVisor
  • TLS
  • スタック検査
  • OTLP
  • 改ざん耐性
  • マルチテナント
目次
背景・問い・要点
背景

AIエージェントの一種であるコーディングエージェントは、シェルでコマンドを実行し、Python のコードを動かし、外部の API を呼び、MCP（Model Context Protocol、エージェントに外部のツールをつなぐ仕様）のツールを使う。技術者は、こうした操作をエージェントに任せたいが、リポジトリへの push や有料の API の呼び出しのように、間違えると困る操作もある。そこで、エージェントを隔離した環境（サンドボックス）に入れ、できる操作を規則で絞る。

規則で絞りたい条件の多くは、操作の中身だけでは決まらない。「テストが通った後でだけ push してよい」「この API は 1 時間に決まった回数まで呼んでよい」は、それまでに何が起きたかに依る。要求を一つずつ見て許可か拒否かを決める規則では、操作の順序や回数を条件にできない。

本稿は、AWS が 2026年10月に開発者プレビューで公開した Strands Box を取り上げる。Box は、操作の中身と、それまでの操作の履歴の両方を条件にして許否を決めるサンドボックスで、作り手が設計判断と限界を文書に書き、コードもオープンソースで確かめられる。エージェントのサンドボックスには、接続先だけを許可リストで絞る方式や、セッションごとに MicroVM（軽量の仮想マシン）を割り当てる方式もある。本稿は Box の仕組みを説明し、MicroVM との関係は作り手の説明の範囲で触れる。

問い

Strands Box は、AI エージェントの操作を何によってどう制限し、何を守らないのか。

要点

Strands Box は、エージェントを OS のサンドボックスに入れ、シェル・Python・外部への通信・MCP の操作をサンドボックスの外で規則に照らして許否を決める。規則は、それまでの操作の履歴も条件にできる。

Box が許否を決めるのは Box を通った操作だけで、エージェントが直接読み書きするファイルは OS の許可で決まる。Box は改ざん耐性を主張せず、Apple silicon の macOS だけで動く開発者プレビューである。

モデル・例示

バグ修正を頼まれたエージェントが、テストして push するまで

※ この節の例は、説明のために作った架空のものです。

Box は、エージェントの操作を、サンドボックスの外にある四つの判定点（シェルの Strands Shell・Python の Monty・外部への通信のゲートウェイ・MCP のブローカー）で一つずつ規則に照らし、同じ操作でも、それまでの履歴によって許すか断るかを変える。技術者がエージェントにバグ修正を頼み、修正をリポジトリへ push させるとする。技術者は、エージェントに許す環境を設定ファイル box.toml に、操作の規則を policy.dw に書く1。規則には、許可の条件を書く permit と、拒否の条件を書く forbid がある。一致する permit が無い操作は拒否され（既定拒否）、一致する forbid は permit に優先する1。

まず、履歴を使わない一回の操作を見る。エージェントは、テストのために外部の API を呼ぶ。

  1. エージェントBox の判定点1. 認証情報を付けずに、外部の API へ HTTP 要求を送る
  2. Box の判定点2. policy.dw の規則で、送り先・メソッド・パスを確かめて許可する
  3. Box の判定点外部の API3. 設定された認証情報を付けて要求を送る
  4. 外部の APIBox の判定点4. 応答を返す
  5. Box の判定点エージェント5. 応答を渡す

エージェントは認証情報を一度も持たない。Box の判定点の一つであるゲートウェイが、許可した要求にだけ認証情報を付ける1。

次に、履歴を使う規則を見る。この例では、git add・npm test・git push を許す permit に加えて、作り手のブログが示す次の forbid を使う。「最後の git add 以降、15 分以内に、終了状態 0 で終わった npm test の応答が無ければ、git push を拒否する」2。エージェントは、シェルのコマンドを判定点の一つであるシェルのインタプリタ Strands Shell で実行する。

  1. エージェントBox の判定点1. 10:00 にシェルで git add を実行する
  2. Box の判定点Dogwood の履歴2. 10:00 の git add の応答を記録する
  3. エージェントBox の判定点3. 10:01 に npm test を実行する。テストは失敗する
  4. Box の判定点Dogwood の履歴4. npm test の応答を終了状態 1 で記録する
  5. エージェントBox の判定点5. 10:02 に git push を要求する
  6. Box の判定点Dogwood の履歴6. 最後の git add（10:00）以降の事象を問い合わせる
  7. Dogwood の履歴Box の判定点7. npm test の応答は終了状態 1 の一件だけと返す
  8. Box の判定点エージェント8. 拒否する。git push は実行されない

エージェントがコードを直し、git add と npm test をやり直すと、判定は変わる。

  1. エージェントBox の判定点1. 10:05 に修正を git add し、10:07 に npm test を実行する
  2. Box の判定点Dogwood の履歴2. 二つの応答を記録する。npm test は終了状態 0
  3. エージェントBox の判定点3. 10:08 に git push を要求する
  4. Box の判定点Dogwood の履歴4. 最後の git add（10:05）以降の事象を問い合わせる
  5. Dogwood の履歴Box の判定点5. 10:07 の終了状態 0 の npm test の応答を返す
  6. Box の判定点エージェント6. 許可し、git push を実行する

10:07 のテストは 10:05 の git add の 2 分後で、push を要求した 10:08 からも 15 分以内にあるので、forbid は当たらない。

この例から言えること

  1. Box は、エージェントの外で操作を規則に照らす。エージェントが持たない認証情報は、許可した要求にだけ Box が付ける。
  2. 同じ git push の要求でも、許否は履歴の中身で決まる。10:02 の push は、10:00 の git add の後に成功した npm test が無いので拒否され、10:08 の push は 10:07 の成功があるので許可される。
  3. 履歴に入るのは、Box の判定点を通った操作だけである。判定点を通らずにソースが書き換わっても、履歴は増えず、規則の判定は変わらない。判定点を通った操作でも、規則が数える事象でなければ判定は変わらない。

Box の構成：OS のサンドボックスと、その外の四つの判定点

Strands Box は、AWS が Strands Agents プロジェクトの一部として 2026-10-07 に開発者プレビューで公開したオープンソースのサンドボックスである12。Apache-2.0 のライセンスで公開され、Rust で書かれ、GitHub のスターは 471 である1。プレビューでは、Apple silicon の macOS でのローカル実行だけに対応する1。Box は特定のエージェントに依らず、技術者は動かすエージェントのプログラムを選び、box.toml と policy.dw を書いて起動する。Rust のライブラリとして自分のアプリに組み込むこともできる1。

Box は二段で制限する1。

ゲートウェイは、接続と HTTP 要求をメソッドやパスまで確かめ、MCP のブローカーは、設定したツールの呼び出しを引数まで確かめる1。エージェントが git や cargo のようなプログラム、あるいはローカルの MCP サーバーを使うときは、Box が起動を規則に照らし、そのプログラムを別のサンドボックスで動かす1。作り手はカーネルによる隔離を併用し、判定の層をサンドボックスの外への唯一の出口にする2。ただし、利用者がツールやローカルの MCP サーバーに contain_egress = false を設定すると、その通信はゲートウェイの判定を通らない3。Box は判定の記録を OTLP（OpenTelemetry Protocol）の JSON 形式で残す1。

四つの判定点は一つの事象の履歴を共有する。そのため、シェルや Python でのファイルの読み取りが、後の HTTP 要求の拒否につながる1。ただし、規則はパスの前方一致を持たず、機密のデータに印を付ける仕組みも無いので、「機密のデータを読んだ後は送信しない」をディレクトリ単位では書けないと作り手は書く4。

規則の言語 Dogwood は、Cedar（AWS が開発した許可規則の言語）の上位互換で、since・formerly・once・集計といった過去の事象を見る条件を加える5。Dogwood の GitHub のスターは 498 である5。作り手は、Box の規則と AgentCore Policy（AWS のクラウド上のエージェント向けの許可規則の機能）が「同じ基盤技術」に基づくと書く2。

作り手は、OS より上の層に判定を置いた理由を、下の層では通信の中身や MCP の呼び出しの引数を読み取れず、それらを条件にした規則を書けないことに求める2。MicroVM は信頼できる計算基盤（TCB、Trusted Computing Base。安全性が依存するコードの総体）を小さく保てるが、ネットワークカードの層で見えるのはほぼ TLS の暗号文である。システムコールの層では「このファイルを開く」「このホストに接続する」が見え、作り手はこの層をパス単位の読み書きの規則に適した場所と書くが、通信は暗号文のままである。作り手によれば、gVisor のようにシステムコールを模倣する方式も、MCP の呼び出しの中身を条件にした規則を書くには、扱う情報の粒度が足りない2。

実行履歴で権限を決める考え方は、Box より古い。Abadi と Fournet は 2003 年に、コードの実行時の権限を、それまでに動いたコードの属性で決めるモデルを提案した6。二人は、実行スタックの状態で権限を決めるスタック検査が、現在のスタックに記録されない相互作用を見ないことを動機に挙げた6。Box の特徴は、シェル・Python・通信・MCP という異なる経路の操作を、一つの規則のエンジンで判定し、一つの事象の履歴で数えることである1。

Box が守らないもの：判定点を通らない操作、改ざん、許可した操作の中身

作り手の限界の文書は、ポリシーが見るのは届いた要求だけと書く3。エージェントが自分のシステムコールでファイルを読み書きすると、許否は OS が決め、ポリシーは見ない。エージェントが起動したツールやローカルの MCP サーバーが、それぞれのサンドボックスの中で行うファイル操作も、ポリシーは判定しない3。そのため、履歴規則はこれらの経路の操作を数えられない。

履歴に入るかどうかとは別に、規則が何を数えるかも穴になる。たとえば git push の forbid が数えるのは git add と npm test の応答だけで、ファイルの書き込みの事象は条件に入っていない2。書き換えが判定点を通ったかどうかに関わらず、テストの後にソースを書き換えて git add を経ずにコミットすれば、テストしていないコードの push が通りうる（本稿の推論）。作り手自身も、git switch でこの規則の約束が崩れうるので、完全な規則ではないと書く2。Box は git を別のサンドボックスで動かし、その中のファイル操作は判定点を通らない13。

規則の対象にしたいファイルは、エージェントの直接の許可から外し、インタプリタを通してだけ触らせれば、その操作も履歴に入る1。ただし、履歴に入っても、上の push の規則のように規則がその事象を数えなければ、判定は変わらない。また、Strands Shell と Monty はサンドボックスの外で動くので、広いファイルの permit は、認証情報を保存する場所を含め、エージェント自身の許可では届かないパスにまで届く。作り手は、permit を仕事に要るパスに絞るよう書いている3。

作り手は、履歴規則を記録された履歴に対して強制すると書き、改ざん耐性は主張しないと明記する4。履歴に事象を書き込むのは信頼された判定点だけで、エージェント側のプロセスは書き込まない4。それでも、回数の規則は実際より少なく数えることがある。応答の事象が記録から欠けると、その分は数えられない。また、回数の規則は処理中の要求を数えないので、上限の直前で同時に出た二つの要求は、どちらも許可されうる4。

許可した操作が技術者の意図に合うかを、Box は判定しない3。書き込みを許したファイルを空にする操作は成功し、許可した送信先には、プログラムが読めるデータを何でも送れる。作り手の第一の原則は「エージェントは乗っ取られていると仮定する」で、テナント間の分離とカーネルの脆弱性への耐性は目標外とする7。作り手は、インタプリタやプロトコルの中継を含むので信頼できる計算基盤が大きくなると認め、クラウドのマルチテナントの運用では、セッションごとの MicroVM と組み合わせることを勧める2。

規則を書くときの注意：前提は応答で、上限は動作ごとの forbid で

作り手の設計文書は、履歴規則に次の落とし穴があると書く4。

作り手自身が、これらの規則は読みにくく書きにくいと認め、今後数か月の主な投資先とする2。作り手は、Dogwood の書き方をコーディングエージェントに教えるスキルのファイルも公開している1。利用者は、規則を書いた後に、判定点を通らない書き換え、拒否された要求、同時に出た要求を含む事象の列で、許可と拒否の両方を確かめてから使う。

出典7件

  1. strands-agents「box」README（2026-10-26 取得）. https://github.com/strands-agents/box — Apache-2.0、Rust、macOS のみのプレビュー、判定点の構成、共有の履歴、既定拒否。スター 471（2026-10-26 取得）、作成 2026-10-02。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  2. Marc Brooker「Strands Box: The Big Picture」Strands Agents Blog, 2026-10-07. https://strandsagents.com/blog/strands-box-the-big-picture/ — 公開の経緯、git push と MCP 回数上限の規則例、他の層を選ばなかった理由、MicroVM との併用の推奨。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  3. strands-agents「Limits of Box’s protection」（2026-10-26 取得）. https://github.com/strands-agents/box/blob/main/docs/design/limitations.md — ポリシーは届いた要求だけを見るので、エージェント自身やツールの読み取りを履歴規則が数えられないこと、インタプリタへの広い permit の危険、許可した操作でも害が出うること。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. strands-agents「Decisions」（2026-10-26 取得）. https://github.com/strands-agents/box/blob/main/docs/design/decisions.md — 改ざん耐性を主張しないこと、要求を対象にした前提条件の失敗、上限が動作のまとまりに及ばないこと、機密データ後の送信禁止が未対応であること、MCP のツールごとの判定が既定拒否でないこと。 ↩ ↩2 ↩3 ↩4 ↩5

  5. dogwood-policy「dogwood」README（2026-10-26 取得）. https://github.com/dogwood-policy/dogwood — Cedar の上位互換で過去の事象の条件を加えること、ログイン後読み取りの例、参照実装は本番向けでないこと。スター 498（2026-10-26 取得）、作成 2026-07-27。 ↩ ↩2

  6. Martín Abadi, Cédric Fournet「Access Control based on Execution History」NDSS, 2003. https://www.ndss-symposium.org/wp-content/uploads/2017/09/Access-Control-Based-on-Execution-History-Martin-Abadi.pdf — 実行履歴で権限を決めるモデルと、スタック検査が現在のスタックにない相互作用を見ないという指摘。 ↩ ↩2

  7. strands-agents「Tenets」（2026-10-26 取得）. https://github.com/strands-agents/box/blob/main/docs/design/tenets.md — エージェントは乗っ取られていると仮定する原則と、テナント間の分離とカーネル脆弱性への耐性を目標外とすること。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。