AgentCore Runtime のセキュリティのベストプラクティス

• 分離境界を理解する — 各ユーザーセッションは、分離された CPU、メモリ、ファイルシステムを備えた専用のmicroVM で実行されます。コマンドとエージェントコードは、他の顧客のワークロードにアクセスしたり、VM の境界からエスケープしたりすることはできません。セッションが完了すると、microVM 全体が終了し、メモリがサニタイズされます。

• バックエンドでsession-to-userマッピングを適用する — AgentCore はsession-to-userマッピングを適用しません。クライアントバックエンドは、ユーザーとそのセッション IDs の関係を維持し、ユーザーあたりのセッションの最大数などのライフサイクル管理を実装する必要があります。

• ファイルシステムのアクセス許可の動作に注意する — 永続ファイルシステムを使用する場合、アクセス許可はセッション内に保存されますが、強制されません。 chmodおよび は正しくstat動作しますが、マイクロmicroVM 内の唯一のユーザーとしてエージェントが実行されるため、アクセスチェックは常に成功します。

• VM 内の認証情報の公開を理解する — microVM 内で実行されているコードまたはアクターは、メタデータエンドポイント (MMDS) を呼び出して実行ロールの認証情報にアクセスできます。実行ロールのアクセス許可の範囲を慎重に設定します。詳細については、「認証情報管理」を参照してください。

• CLI で生成されたポリシーを本番環境で使用しない — AgentCore CLI によって作成された IAM ポリシーは、開発およびテストを目的として設計されています。これらのアクセス許可は広範なアクセスを許可し、本番稼働には適していません。必要な特定のリソースとアクションのみにアクセス許可を制限するカスタム IAM ポリシーを作成します。完全なリファレンスについては、AgentCore ランタイムの IAM アクセス許可」を参照してください。

• 特定のランタイム ARNs へのアクセス許可の範囲 — ワイルドカードリソースステートメントは避けてください。IAM ポリシーResourceフィールドでランタイムリソースの完全な ARN を使用します。

• 制限 InvokeAgentRuntimeForUser — 信頼されたプリンシパルのみがこのアクセス許可を持つ必要があります。IAM リソース条件を使用して、特定のランタイムリソースにスコープします。

• 不要なユーザー ID の委任を拒否する — ユーザー ID の委任が不要なランタイムの場合は、明示的に アクションを拒否します。

  {
     "Statement": [
        {
           "Sid": "DenyUserIdDelegation",
           "Effect": "Deny",
           "Action": "bedrock-agentcore:InvokeAgentRuntimeForUser",
           "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*"
        }
     ]
  }

• 権限のエスカレーションの防止 — ランタイムに関連付けられた実行ロールの権限が、それを呼び出すことができるプリンシパルと同等以下であることを確認します。詳細については、「認証情報管理」を参照してください。

• IAM 条件キーを使用して VPC デプロイを適用する — bedrock-agentcore:subnetsおよび bedrock-agentcore:securityGroups条件キーを使用して、すべてのランタイムが承認された VPCs。例については、AgentCore ランタイムで VPC 条件キーを使用する」を参照してください。

• IAM Access Analyzer を使用する — IAM ポリシーを検証して、ベストプラクティスと最小特権の原則に準拠していることを確認します。

• 階層認可を理解する — InvokeAgentRuntime、InvokeAgentRuntimeCommand、 などのランタイム API オペレーションの場合InvokeAgentRuntimeCommandShell、 はエージェントランタイムとエージェントエンドポイントの両方のポリシー AWS を評価します。どちらも アクションを許可する必要があります。

• クロスアカウントアクセス用に両方のリソースを設定する — クロスアカウントアクセスを許可するには、エージェントのランタイムとエージェントエンドポイントの両方でリソースベースのポリシーを作成します。いずれかのリソースに明示的な許可がない場合、リクエストは拒否されます。

• 明示的な拒否は常に成功することに注意してください — いずれかのポリシー (アイデンティティベースまたはリソースベース) がアクションを明示的に拒否した場合、アクセスは他のポリシーに関係なく拒否されます。

• aws:SourceArn と を使用する aws:SourceAccount — 実行ロールの信頼ポリシーにこれらの条件を追加して、ロールを引き受けることができる AgentCore リソースを制限します。

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "bedrock-agentcore.amazonaws.com"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "aws:SourceAccount": "123456789012"
          },
          "ArnLike": {
            "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"
          }
        }
      }
    ]
  }

• 可能な場合は完全な ARN を使用する — 特定のランタイムリソースがわかっている場合は、ワイルドカードaws:SourceArnの代わりに で完全な ARN を使用します。

• ポリシーベースの認可 — ゲートウェイのポリシーエンジンを使用して、どの発信者がどのターゲットをどの条件で呼び出すことができるかを制御します。詳細については、「ポリシーを使用してゲートウェイターゲットへのアクセスを制御する」を参照してください。

• ガードレール — ポリシーエンジンを介して Amazon Bedrock ガードレールを適用して、リクエストとレスポンスをスクリーンします。詳細については、「 ポリシーでガードレールを使用する」を参照してください。

• リクエストとレスポンスのインターセプター — ゲートウェイで設定されたインターセプター Lambda 関数を使用してトラフィックを検査または変換します。

• IAM (SigV4) ランタイム — ゲートウェイの実行ロールへの呼び出しを制限するリソースベースのポリシーをアタッチします。「ゲートウェイへの IAM (SigV4) インバウンド呼び出しを制限する」を参照してください。

• OAuth (JWT) ランタイム — ランタイムのオーソライザーallowedWorkloadConfigurationで を設定します。「ゲートウェイへの呼び出しを制限する」を参照してください。

• 適切な認証方法を選択する — 内のservice-to-service呼び出しに IAM SigV4 を使用します AWS。エンドユーザーが ID プロバイダーを介して直接認証する場合は、JWT ベアラートークン認証を使用します。ランタイムは一度に 1 つのメソッドをサポートできます。異なる認証タイプ用に個別のバージョンを作成します。

• 本番環境で JWT ベースのユーザー ID を優先する — エージェントがエンドユーザーに代わって OAuth トークンを取得する場合は、トークンの発行者、署名、有効期限を検証する JWT ベアラートークンパス (GetWorkloadAccessTokenForJWT) を優先します。UserId パス (GetWorkloadAccessTokenForUserId/ X-Amzn-Bedrock-AgentCore-Runtime-User-Idヘッダー) は、IdP 検証なしでユーザー識別子を不透明な文字列として扱います。ユーザー ID をアップストリームで解決する開発、クイックスタートシナリオ、またはエンタープライズアーキテクチャにのみ使用します。詳細については、「ワークロードアクセストークンの取得」を参照してください。

• JWT オーソライザーを完全に設定する — JWT 認証を使用する場合は、検出 URL、許可された対象者、許可されたクライアント、許可されたスコープ、必要なカスタムクレームなど、使用可能なすべての検証フィールドを設定します。

• 本番コードでトークンをハードコードしない — 安全なトークン取り出しメカニズムを使用します。ハードコードされたトークンは、ソース管理とデプロイされたアーティファクトのセキュリティリスクです。

• 認証されたプリンシパルから user-id を取得する — X-Amzn-Bedrock-AgentCore-Runtime-User-Idヘッダーを使用する場合、値は、クライアントが指定した任意の値からではなく、認証されたプリンシパルのコンテキスト (IAM 発信者 ID またはユーザートークンクレーム) から取得する必要があります。これにより、認証されたユーザーが他のユーザーになりすますことを防ぎます。

• 不要な場合は ForUserId を拒否する — 常に JWT を使用できるワークロードの場合は、IAM ポリシーbedrock-agentcore:InvokeAgentRuntimeForUserで明示的に bedrock-agentcore:GetWorkloadAccessTokenForUserIdと を拒否します。これにより、すべてのユーザー ID が暗号的に検証された JWT パスを通過するようになります。

• 認証メソッドの VPC エンドポイントポリシーを設定する — VPC エンドポイントポリシーは、OAuth ユーザーではなく、IAM プリンシパルに基づいてのみ発信者を制限できます。OAuth ベースのリクエストの場合、エンドポイントポリシー*で を Principalに設定します。SigV4-based認証では、許可された IAM ID を指定します。

• アウトバウンド認証に AgentCore Identity を使用する — AgentCore Identity は OAuth 認証情報と API キーを安全に管理し、エージェントコードまたはログでの認証情報の漏洩を防ぎます。すべてのサードパーティーサービスアクセス (Slack、GitHub、Zoom) に使用します。

• MMDS 認証情報の公開を理解する — MicroVM メタデータサービス (MMDS) は、EC2 の IMDS と同様に、VM で実行されているコードに実行ロール認証情報を提供します。実行ロールのアクセス許可を、エージェントが必要とするもののみにスコープします。

• MMDSv2 を有効にする — 2026 年 6 月 30 日以降、エージェントのランタイムで MMDSv2 が有効になっている必要があります。MMDSv2 が有効になっていないランタイムを呼び出して を返すことはできませんValidationException。を有効にするには、 UpdateAgentRuntime で を requireMMDSV2に設定して を呼び出しtrueますmetadataConfiguration。このエラーの解決の詳細については、MMDSv2 ValidationException のトラブルシューティング」を参照してください。

• 非ルートユーザーとしてコンテナを実行する — カスタムコンテナイメージを構築するときは、非ルートユーザーとして実行するようにコンテナを設定します。これにより、潜在的なコード実行の脆弱性の影響が制限されます。

• ユーザー委任認証情報と自律認証情報を分離する — エージェントが特定のユーザーに代わって行動する場合は、ユーザー委任認証 (認可コード付与) を使用します。エージェントが独立して動作する場合は、自律認証 (クライアント認証情報付与) を使用します。

• プライベートリソースアクセス用の VPC にランタイムをデプロイする — インターネットに公開することなく、プライベートデータベース、内部 APIs、サービスにアクセスするように VPC 接続を設定します。設定の詳細については、「VPC の AgentCore ランタイムを設定する」を参照してください。

• API アクセス用の Use AWS PrivateLink — AgentCore データプレーン (com.amazonaws.region.bedrock-agentcore) とコントロールプレーン (com.amazonaws.region.bedrock-agentcore-control) のインターフェイス VPC エンドポイントを作成して、インターネットトラバーサルを回避します。詳細については、「Use AWS PrivateLink」を参照してください。

• セキュリティグループに最小権限を適用する — 最小の必要なトラフィックのみを許可するアウトバウンドルールを定義します。必要に応じて、広範なアウトバウンドアクセスを開かないでください。

• コンテナエージェントに必要な VPC エンドポイントを設定する — VPC モードのコンテナエージェントの場合は、ECR (、com.amazonaws.region.ecr.api)、S3 (com.amazonaws.region.s3ゲートウェイエンドポイント)com.amazonaws.region.ecr.dkr、CloudWatch Logs () の VPC エンドポイントを設定しますcom.amazonaws.region.logs。S3 ゲートウェイエンドポイントは、ECR イメージレイヤーのプルに対する NAT ゲートウェイデータ処理料金を排除します。

• コンテナエージェントの S3 ゲートウェイエンドポイントポリシーの範囲 — S3 ゲートウェイエンドポイントポリシーを、Amazon ECR がイメージレイヤーストレージに使用するバケットのみに制限します。

  {
    "Statement": [
      {
        "Sid": "AllowECRLayerAccess",
        "Principal": "*",
        "Action": [
          "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::prod-region-starport-layer-bucket/*"]
      }
    ]
  }

  を AWS リージョン識別子 ( などus-east-2) regionに置き換えます。

• ダイレクトコードデプロイエージェントの S3 ゲートウェイエンドポイントポリシーの範囲を設定する — zip ベースのデプロイの場合は、ポリシーを内部サービス所有のコードアーティファクトバケットに制限します。aws:PrincipalServiceName 条件を追加して、AgentCore サービスプリンシパルのみがこのエンドポイントポリシーを介してバケットにアクセスできるようにします。

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": [
          "arn:aws:s3:::acr-code-*-region-an",
          "arn:aws:s3:::acr-code-*-region-an/*"
        ],
        "Condition": {
          "StringEquals": {
            "aws:PrincipalServiceName": "bedrock-agentcore.amazonaws.com"
          }
        }
      }
    ]
  }

  を AWS リージョン識別子 ( などus-west-2) regionに置き換えます。AgentCore コードアーティファクトバケットは、アカウントリージョン名前空間汎用バケットに作成されます。サービスで使用される実際のバケット名を所有 AWS できるのは のみです。このaws:PrincipalServiceName条件により、AgentCore サービスプリンシパルのみがこのエンドポイントポリシーを通じてバケットにアクセスできるようになります。永続ファイルシステムも使用する場合は、このポリシーにセッションストレージバケットを追加します。詳細については、「VPC の AgentCore ランタイムを設定する」を参照してください。

• NAT ゲートウェイでプライベートサブネットを使用する — パブリックサブネットは AgentCore ランタイムにインターネットアクセスを提供しません。ランタイム ENIs、常にアウトバウンドインターネットアクセスのために NAT ゲートウェイへのルートを持つプライベートサブネットに配置します。

• トランスポートセキュリティ — すべての接続で TLS 1.2 以降が使用されます。を含む WebSocket 接続はInvokeAgentRuntimeCommandShell、HTTPS でのみ WSS (WebSocket Secure) を使用します。プレーンテキストws://接続はサポートされていません。

• ヘッダー制限を適用する — カスタムヘッダーは、値あたり 4KB、ランタイムあたり 20 ヘッダーに制限されています。Authorization ヘッダーは、OAuth インバウンドアクセスを持つエージェント用に予約されています。

• 転送中の暗号化 — クライアントと AgentCore ランタイム間、および AgentCore ランタイムとその依存関係間のすべての通信は、TLS 1.2 以降を使用して保護されます。これはデフォルトで設定され、追加のセットアップは必要ありません。

• 保管時の暗号化 — 保管中のデータは、デフォルトで AWS Key Management Service (AWS KMS) の AWS 所有暗号化キーを使用して暗号化されます。

• 可能な限り TLS 1.3 を使用する — TLS 1.2 は最小限ですが、 ではセキュリティとパフォーマンスを向上させるために TLS 1.3 AWS を推奨しています。

• CloudTrail ログ記録を有効にする — AWS CloudTrail は、InvokeAgentRuntime、、InvokeAgentRuntimeCommandShell、および コントロールプレーンオペレーションを含む API InvokeAgentRuntimeCommandコールを記録します。各レコードには、発信者 ID、タイムスタンプ、送信元 IP アドレス、応答ステータスが含まれます。

• コマンド監査に CloudWatch Logs を使用する — AgentCore Runtime は、リクエスト ID と入力コマンドをエージェントの CloudWatch Logs ロググループに送信します。これらのログを使用して、セッションで実行されたコマンドの監査証跡を維持します。

• リクエスト IDs — リクエスト ID を使用して、CloudTrail レコード (API と呼ばれる) と CloudWatch Logs (実行されたコマンド) を関連付けます。

• メトリクスフィルターとアラームの設定 — CloudWatch Logs メトリクスフィルターを設定して、予期しないコマンドパターンや不正アクセスの試みを検出します。アラームを作成して、チームに異常を通知します。

• ユーザー ID 委任関係のログ記録 — X-Amzn-Bedrock-AgentCore-Runtime-User-Idヘッダーを使用する場合は、監査目的で、認証された IAM プリンシパルとユーザー ID 値の関係をログに記録します。

• VPC フローログを有効にする — VPC 接続ランタイムの場合、VPC フローログを有効にしてネットワークレベルのトラフィックを監査し、予期しない通信パターンを特定します。

• CloudTrail ログを定期的に確認する — 特に機密性の高いワークロードでは、不正アクセスの試みがないかログを定期的に確認します。

AWS 責任:

• ハードウェアレベルでの安全なインフラストラクチャとmicroVM の分離

• すべてのデプロイモードの OS カーネルパッチ適用

• 直接コードデプロイの言語ランタイムパッチ適用

• ネットワークインフラストラクチャのセキュリティ

• サービスの可用性と耐障害性

お客様の責任:

• エージェントコードのセキュリティと依存関係の管理

• IAM アクセスコントロールとリソースポリシー

• ランタイムセッションで実行されるコマンドのセキュリティ

• Session-to-userマッピングの適用

• コンテナイメージの更新 (コンテナデプロイ用) — 最新の安全なベースイメージを使用して定期的に再構築する

• 入力の検証とプロンプトインジェクションの防止 — マネージドハーネスを使用する際InvokeHarnessの入力の検証を含む (「ハーネスが AgentCore ランタイムの信頼境界を共有する」を参照)

• ネットワーク設定 (セキュリティグループ、VPC エンドポイント、ルートテーブル)

• InvokeAgentRuntimeCommand — HTTP/2 経由のワンショット、非インタラクティブコマンド実行。IAM アクション: bedrock-agentcore:InvokeAgentRuntimeCommand。

• InvokeAgentRuntimeCommandShell — 永続的な PTY アクセスを持つインタラクティブな WebSocket シェルセッション。IAM アクション: bedrock-agentcore:InvokeAgentRuntimeCommandShell。

• セキュリティの境界を理解する — コマンドは、コンテナファイルシステム、およびmicroVM 内で設定された認証情報またはシークレットにフルアクセスできます。分離境界は microVM 自体です。責任共有モデルでは、ランタイムコンテナで実行されるコードのセキュリティはお客様の責任となります。

• 決定論的タスクに決定論的オペレーションを使用する — テスト、git、ビルドなどのオペレーションInvokeAgentRuntimeCommandShellに InvokeAgentRuntimeCommandまたは を使用します。決定論的オペレーションを LLM 経由でルーティングしないでくださいInvokeAgentRuntime。

• コマンドを実行できるユーザーを制限する — IAM ポリシーを使用して、 InvokeAgentRuntimeCommandまたは を呼び出すことができるプリンシパルを制限しますInvokeAgentRuntimeCommandShell。エージェントを呼び出すことができるすべてのユーザーが任意のコマンドを実行できるわけではありません。リソース ARN の例: arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent。

• WebSocket シェルは wss:// のみを使用します。InvokeAgentRuntimeCommandShell接続は WSS (WebSocket Secure) でのみ確立されます。プレーンテキストws://接続はサポートされていません。WebSocket のアップグレード時に、発信者は SigV4 を介して認証します。

• ネットワーク内にトラフィックを保持する — コマンド実行 API コールのインターネットトラバーサルを回避するように VPC エンドポイントを設定します。

• 適切なタイムアウトを設定する — 予想される実行期間に基づいてコマンドタイムアウトを設定し、リソースの浪費が暴走プロセスにならないようにします。

• エージェントコードでの localhost アクセスの制限 — localhost への無制限アクセスを防ぐために、エージェントとネットワークツールを設定します。エージェントコードは、特定の統合に必要でない限り、localhost に対して任意の HTTP 呼び出しを実行しないでください。

• サイドカー設定に必要なポートのみの許可リスト — アーキテクチャが localhost container-in-container内またはサイドカーパターンを使用している場合は、サイドカーサービスが使用する特定のポートのみを明示的に許可リストします。広範な localhost アクセスを開かないでください。

• localhost reach のネットワークツールを監査する — エージェントに提供するツール (HTTP リクエストツールや一般的なネットワークユーティリティなど) を確認して、localhost エンドポイントに意図しないリクエストを実行できないことを確認します。ツールレベルで URL フィルタリングまたは許可リストを適用します。