AWSがAIエージェントの「暴走」を3層構造で封じ込める — Lambda MicroVMで実行を隔離し、Cedarポリシーでツール呼び出しを決定論的に制御

7月10日、Amazon Web Services（AWS）が「Secure code execution for AI agents with AWS Lambda MicroVMs」と題した記事を公開した。この記事では、AWS Lambda MicroVMを中心とした3層アーキテクチャを使い、AIコーディングエージェントが生成したコードを安全に実行・デプロイする手法について詳しく紹介されている。

AIコーディングエージェント（Claude Code、Kiro、Cursorなど）はコード生成・テスト・デプロイを自律的に行う。しかし現状では、そのほとんどが開発者自身の権限でそのまま動作する。エージェントが意図した範囲を逸脱した場合——ハルシネーションであれプロンプトインジェクションであれ——環境全体に影響が及ぶリスクがある。

こうしたリスクはもはや机上の話ではない。AIコーディングエージェントの実務導入が急速に広がる中、エージェントが過剰な権限でクラウドリソースを操作したり、意図せず本番環境へデプロイを試みたりといった事例が業界で報告され始めている。ツールの自律性が上がるほど、ガードレールの不在がそのままインシデントリスクに直結する構造だ。

この問題に対してAWSが提示する答えが、「実行の分離」「ドメイン知識の埋め込み」「ガバナンスの強制」の3層構造だ。

Layer 1：実行の分離（Lambda MicroVMs）

Lambda MicroVMsは、Firecrackerベースの軽量VMで、独自のカーネル・ファイルシステム・ネットワーク名前空間を持つ。LambdaがFirecrackerを内部で採用した当初から使われてきた同じ技術基盤が、スタンドアロンの実行環境として利用可能になったものだ。

MicroVMの中ではパッケージインストール、シェルコマンド実行、ビルドチェーン実行、テスト実行など、ローカルマシンと同等の操作が可能だ。エージェントが破壊的なコードを生成しても、影響は単一のエフェメラルな環境に閉じ込められる。

主な仕様：

vCPU・メモリ・ディスクを設定可能
エージェントセッションは最大8時間継続可能
ネットワークはパブリックまたはVPC限定を選択可能
サスペンド・レジューム対応で、セッションをまたいで状態を保持できる

Layer 2：ドメイン知識の埋め込み（Agent Toolkit for AWS）

実行環境の分離だけでは不十分だ。MicroVMの中で動くエージェントが、一般的な学習データからの即興でコードを生成すれば、IAMパーミッションが過剰に広かったり、オブザーバビリティ設定が抜けていたりと、プロダクション品質には程遠い結果になりやすい。

Agent Toolkit for AWSは、エージェントに「経験豊富なエンジニアが実際にどう構築するか」を教えるスキル集だ。2025年にAWSLabsからオープンソースとして公開されたもので、具体的には：

最小権限のIAMをデフォルトで適用（ワイルドカード権限を生成させない）
AWS X-Rayトレースをデフォルトで有効化
プロジェクト初期化からデプロイ・トラブルシューティングまでのライフサイクル全体をカバー

Claude CodeとCursorには「Agent Plugin for AWS Serverless」としてプラグイン提供される。KiroなどAgent Skills対応ツールでは直接利用できる。Lambda MicroVMs専用のスキルも含まれており、エージェントがMicroVM環境のプロビジョニングから操作までを自律的にこなせるよう設計されている。

Layer 3：ガバナンスの強制（Policy in AgentCore）

最も重要な層が、Amazon Bedrock AgentCoreのGatewayを通じたツール呼び出しの制御だ。エージェントのすべてのツール呼び出しはAgentCore Gatewayでインターセプトされ、Cedarポリシーによって評価される。

Cedarはオープンソースの認可ポリシー言語で、AWSが開発しオープンソースとして公開している（GitHubリポジトリ）。Rustで実装されており、形式的検証が可能な設計が特徴だ。Amazon Verified Permissionsなど複数のAWSサービスでも採用されているが、AWS以外のプロジェクトでも独立して利用できる汎用的なOSSである。人間が読みやすく、機械解析可能で、モデルのコンテキストやプロンプトに一切影響されず決定論的に評価される点が本用途において特に重要だ。エージェントの推論ループの完全に外側で動作するため、プロンプトを工夫してもポリシーは迂回できない。

記事ではポリシーの具体例として、ステージング環境へのデプロイのみを許可し、本番環境へは明示的に拒否する設定を示している：

permit(
    principal,
    action == AgentCore::Action::"DeployTarget___deploy_application",
    resource == AgentCore::Gateway::"<gateway-arn>"
) when {
    context.input.environment == "staging"
};

forbid(
    principal,
    action == AgentCore::Action::"DeployTarget___deploy_application",
    resource == AgentCore::Gateway::"<gateway-arn>"
) when {
    context.input.environment == "production"
};

常に拒否されるアクションはエージェントのツールリストから最初から除外されるため、エージェントは存在すら認識しない。全ての判定結果はAmazon CloudWatchに記録され監査に使える。

3層が連携する実際のワークフロー

記事では、注文処理APIをエージェントが構築・デプロイするシナリオを使ってウォークスルーを示している。

MicroVM内でコードを書いてテスト：エージェントはMicroVM内でアプリをスキャフォールドし、全テストが通るまで繰り返す。ホスト環境への影響はゼロ。
Agent Toolkitスキルを使いSAMテンプレートを生成：ワイルドカード権限の代わりにDynamoDBCrudPolicyなどのSAMポリシーテンプレートを使い、X-Rayトレースも自動で有効化されたテンプレートが生成される。
Gatewayを通じてデプロイを試みる：エージェントがenvironment: "production"でデプロイツールを呼び出すとCedarが拒否。エージェントはenvironment: "staging"に切り替えて再試行し、成功する。

このポリシー適用にエージェントのコード変更やプロンプト修正は一切不要だ。Gatewayに一度定義すれば、以後の全ツール呼び出しに自動で適用される。

運用上の推奨事項

記事が示す推奨事項はいずれも「段階的に適用する」「コードとして管理する」という原則に貫かれており、既存のDevSecOpsプラクティスとの親和性が高い。

CedarポリシーはまずLog-onlyモードで開始し、実際のエージェントワークフローに対して何が拒否されるかを確認してから段階的に適用する。いきなり全拒否ルールを適用すると正当なワークフローが止まるリスクがあるため、実運用に即したポリシー設計のためのウォームアップ期間として重要だ。
MicroVMのネットワークアクセスはVPC限定で十分なケースが多い（デプロイはGateway経由のため）。パブリックアクセスを許可する場合は、その必要性を明示的に判断すべきだ。
CedarポリシーはコードとしてGitで管理し、変更にはレビューを必須とする。ポリシーの変更履歴が監査証跡にもなる。
エージェントが作成したリソースには一貫したタグを付け、Cedarポリシーやコスト追跡・クリーンアップ自動化で活用できるようにする。エージェントが量産したリソースの把握はタグ戦略なしには困難になりやすい。

詳細はSecure code execution for AI agents with AWS Lambda MicroVMsを参照していただきたい。