AWS Rex、エージェンティックAIセキュリティのランタイムレイヤーをオープンソース化

2026年5月4日、AWSはIntroducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humansを公開し、RexをApache 2.0ライセンスのもとでオープンソース化しました。アーキテクチャはシンプルで、スクリプトはRhaiという軽量な組み込み言語で記述され、OSへの直接アクセス機能はありません。スクリプトがホストにアクセスする唯一の方法は、専用に設計されたSDK経由です。すべての操作は、システムコールが許可される前にCedarポリシーで認可されます。ポリシーがアクションを拒否した場合、スクリプトはACCESS_DENIED_EXCEPTIONを受け取り、その操作はカーネルに到達しません。

AWSは本番コードで、セキュリティ研究コミュニティが2年間主張してきたことを認めています。すなわち、コードレビューや承認ワークフロー、許可リスト化されたコマンドでは、AIシステムが実行時に生成するコードを制御できないという点です。エージェント自身が作成者となる場合、従来のセーフティネットは機能しなくなります。

5つの重要なポイント

1. AWSは「実行時ポリシー強制」というカテゴリを導入

Trusted Remote Execution（Rex）は、AIが生成したスクリプトが試みるすべてのシステム操作を、エージェントではなくホスト所有者が定義したCedarポリシーで制御します。これは、エージェント型AIセキュリティの実行時レイヤーをエージェント自身に任せてはならないという、主要なハイパースケーラーによる初の公式な認識です。AWSがプロンプトインジェクション問題の解決を前提としない本番インフラを提供するということは、エンタープライズアーキテクトにとって「エージェントが不正行為をする前提で設計せよ」という明確なメッセージです。

2. 脅威モデルが明確かつ不安を伴うものに

AWSは、幻覚的なコード、プロンプトインジェクション、過度なタスク解釈を、Rexが封じ込めるべき具体的な障害モードとして明示しています。OpenAIはプロンプトインジェクションが「完全に解決されることはまずない」と述べており、Anthropicも「特にモデルが現実世界でより多くのアクションを取るにつれて、解決にはほど遠い」と認めています。Rexはこれらの前提で提供されており、AIガバナンスアーキテクチャも同様の前提で設計すべきです。

3. Rexはエージェントではなくホストを制約

多くのエージェント型サンドボックスは、モデルの出力を制限しようとします。Rexはその逆で、エージェントが何を生成しても、システムコールはポリシーが許可する範囲を超えられません。このアーキテクチャの逆転、すなわち「エージェントがホストに対して何ができるか」という強制の境界を移すことは、単なる漸進的な改善ではありません。信頼の所在を「エージェントの出力」から「ホストのポリシーエンジン」へ移すという根本的な転換です。

4. 実行時制御は必要だが、それだけでは不十分

システムコールに対するCedarポリシーでは、エージェントが「どのドキュメントを要求すべきでなかったか」「どのフィールドが最小限必要か」「取得がデータ分類で越境とされる法域をまたいでいないか」などを判断できません。これらはGDPR第5条、HIPAAの最小限基準、CMMCレベル2のアクセス制御ファミリーが求めるコントロールです。Rexはこれらに対応していません。

5. 監査証跡の防御層は実行時より下にある

規制当局、監査人、原告は「誰がどのデータアクセスを許可したか」の証拠を求めます。その証拠はデータが存在する場所、すなわち規制対象コンテンツへのAIインタラクションすべてをカバーする改ざん検知可能な監査証跡に残す必要があります。システムコールのリードを許可するポリシーは実行時レイヤーでは正しいですが、データレイヤーでは不適切です。両者は異なる管理策です。

AWSが認めたエージェント型AIの課題

AWSの発表で重要なのは、コードだけでなく3つのアーキテクチャ的な譲歩です。

1つ目は脅威モデルです。幻覚的なコード、プロンプトインジェクション、過度なタスク解釈が、理論的な例外ではなく、Rexが封じ込めるべき具体的な障害モードとして明示されています。ハイパースケーラーが「これらの問題は解決されない」という前提でインフラを提供する場合、エンタープライズアーキテクトはその前提で設計すべきです。

2つ目はアーキテクチャの逆転です。Rexは、エージェントの出力を制限するのではなく、エージェントがホストに対して何ができるかという強制の境界を移します。この表現は正確で、エージェントを制限するということは出力を信頼して制御できることを前提としています。ホスト側に移すことで、その制限が信頼できないことを前提とし、実際にシステムが実行される場所で強制を行います。これは機能の選択ではなく、信頼アーキテクチャの選択です。

3つ目はポリシーモデルです。Cedarは2023年5月にAWSがオープンソース化し、現在はCNCF Sandboxプロジェクトとなっています。RBACとABACの両方をサポートし、ポリシーはエージェントではなくホスト所有者が定義します。スクリプトとポリシーは別々にバージョン管理されます。これはシステムコールレイヤーに適用された「ポリシー・アズ・コード」であり、このパターンに最適なレイヤーであり、Rexが対応する唯一のレイヤーでもあります。

なぜ実行時制御が必要なのか

Rexは現実的な課題を解決します。多くのスクリプト実行環境では、スクリプトに実行コンテキストが持つすべての権限が与えられます。ログファイルを読む目的のスクリプトが、同じ権限でファイルを削除することも可能です。これがAIエージェントによって実行時に生成される場合、従来のレビューコントロールは機能しません。このような環境でエージェントが誤作動すれば、誤ったタスク解釈一つで本番環境に被害をもたらします。

Kiteworks 2026年予測では、このリスクが数値化されています。組織の63%がAIエージェントに対して目的限定を強制できず、60%が誤作動したエージェントを迅速に停止できず、55%がAIシステムを広範なネットワークアクセスから隔離できず、54%がAI入力の検証ができません。Rex型の実行時ポリシー強制は、これらのうち最初と最後のギャップを大きく埋めます。また、規制面でもEU AI法の影響下にある組織は、Rexが示す実行時・ID・ポリシーインフラを他の地域よりも早く構築しています。アドバイザリー環境も、すべての法域でこのギャップを急速に縮めています。

なぜ実行時制御だけでは不十分なのか

Rexは実行時コントロールであり、システムコールを制御します。しかし、エージェントが「そもそもどのドキュメントを要求すべきでなかったか」を判断したり、人間ユーザーが閲覧を許可されたフィールドだけを返すことを強制したり、取得がデータ分類で越境とされる法域をまたいでいないかを評価したりはできません。

これらは理論的な例外ではなく、GDPR第5条（目的限定、データ最小化、保存期間制限、説明責任）が要求するコントロールです。HIPAAの最小限基準やCMMCレベル2のアクセス制御ファミリーも同様です。CISA、NSA、Five Eyesによるエージェント型AI共同アドバイザリーでも、説明責任や特権リスクとして明示されています。

file_system::Action::"read"を/var/data/customer-records.csvに許可するポリシーは、実行時レイヤーでは正しいですが、データレイヤーでは不十分です。データレイヤーでは「このリードは正しい権限を持つユーザーのためか」「リクエスターは許可された範囲内で操作しているか」「記録はタスクに必要最小限か」「削除要求が未反映のデータが含まれていないか」「アクセスが十分な詳細で記録され、モデル廃止から3年後でも誰が何を許可したか再現できるか」など、別の問いが必要です。Rexはこれらには対応していません。

本当に機能するアーキテクチャ像

有効なパターンはレイヤー構造です。Rexのような実行時コントロールはホストが許可する範囲を強制し、IDコントロールはエージェントが誰の代理で動いているかを強制します。データレイヤーコントロール（分類・法域・同意に基づく属性ベースアクセス制御）は、エージェントが触れてよいデータを強制します。各レイヤーは異なる障害モードに対応し、単一レイヤーだけでは不十分です。

Kiteworks Secure MCP ServerとAI Data Gatewayは、このアーキテクチャのデータレイヤー要素を実装しています。すべてのAI操作はOAuth 2.0で認証され、Kiteworks Data Policy EngineのABACポリシーで評価され、FIPS 140-3認証暗号で暗号化され、改ざん検知可能な監査証跡として既存のSIEMインフラに記録されます。Kiteworks Private Data Networkは、メール、ファイル共有、MFT、SFTP、Webフォーム、API全体にガバナンスを拡張し、1つのポリシーエンジンと統合監査ログで管理します。

AWSは実行時レイヤー向けに強力なインフラを提供しましたが、IDレイヤーとデータレイヤーは今後も構築が必要です。Kiteworks 2026年予測によれば、中央集約型AIデータゲートウェイを導入している組織は43%にとどまります。

セキュリティ・コンプライアンス担当者が得るべき教訓

第一に、AWSの発表を重要なシグナルとして受け止めてください。ハイパースケーラーがエージェントとは独立したポリシーで全システムコールを制御する実行時ゲーティングをオープンソース化したことで、実運用AIにおける実行時ポリシー強制はもはやオプションではありません。Rexは多くの組織が放置してきた実行時レイヤーのギャップを埋めます。

第二に、実行時強制とデータガバナンスを混同しないでください。Rexはエージェントがホスト上で何ができるかを制御しますが、エージェントが触れてよいデータには関与しません。実行時コントロールだけを追加しても、データレイヤーのガバナンスがなければ監査ギャップは埋まりません。1つのレイヤーだけを記録し、もう1つを放置することになります。

第三に、レイヤー構造のアーキテクチャを明確に設計してください。実行時コントロール（Rex）、IDコントロール（OAuthや短期認証情報）、データレイヤーコントロール（ABAC、分類、法域、同意）を、それぞれが対応する障害モードにマッピングしましょう。各レイヤーは異なる問いを投げかけ、完全な答えにはすべてが必要です。

第四に、ポリシーバージョン管理を監査証拠として扱ってください。Cedarのポリシーとコードの分離は、監査人が検証できる成果物を生み出します。Rexの実行時証跡と、改ざん検知可能なデータレイヤー監査ログを組み合わせることで、完全な証拠パッケージが作成できます。実際に何が実行されたかと、どのデータにアクセスしたかの可視性のギャップが、多くの監査指摘の原因です。

第五に、Five Eyes共同アドバイザリーをアーキテクチャのテスト基準にしてください。CISA「Careful Adoption of Agentic AI Services」の5つのリスクカテゴリ（特権、設計・構成、行動、構造、説明責任）を現行AI導入に適用しましょう。Rexは特権と行動の一部に対応しますが、構造や説明責任カテゴリは、実行時だけではなくデータレイヤーのガバナンスが必要です。

AIエージェントの最適化と機密データのガバナンスについてさらに知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  ゼロトラスト戦略で実現する手頃なAIプライバシー保護
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレットをしている理由
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている