Bonnes pratiques de sécurité pour AgentCore Runtime

• Comprenez la limite d'isolation — Chaque session utilisateur s'exécute dans une microVM dédiée avec un processeur, une mémoire et un système de fichiers isolés. Les commandes et le code de l'agent ne peuvent pas accéder aux charges de travail des autres clients ni échapper aux limites des machines virtuelles. Une fois la session terminée, l'ensemble de la microVM est arrêté et la mémoire est nettoyée.

• Appliquez les mappages session-utilisateur dans votre backend, mais pas les mappages session-utilisateur. AgentCore Le backend de votre client doit maintenir la relation entre les utilisateurs et leurs identifiants de session, et mettre en œuvre une gestion du cycle de vie, telle que le nombre maximum de sessions par utilisateur.

• Soyez conscient du comportement des autorisations du système de fichiers : lorsque vous utilisez des systèmes de fichiers persistants, les autorisations sont stockées mais ne sont pas appliquées au cours de la session. chmodet stat fonctionnent correctement, mais les contrôles d'accès réussissent toujours car l'agent s'exécute en tant que seul utilisateur de la microVM.

• Comprenez l'exposition des informations d'identification au sein de la machine virtuelle : tout code ou acteur exécuté dans la microVM peut accéder aux informations d'identification du rôle d'exécution en appelant le point de terminaison des métadonnées (MMDS). Délimitez soigneusement les autorisations de votre rôle d'exécution. Pour plus d'informations, consultez la section Gestion des informations d'identification.

• N'utilisez pas de CLI-generated politiques en production : les politiques IAM créées par la AgentCore CLI sont conçues à des fins de développement et de test. Ces autorisations accordent un accès étendu et ne sont pas adaptées à la production. Créez des politiques IAM personnalisées qui limitent les autorisations aux seules ressources et actions spécifiques requises. Pour une référence complète, consultez la section Permissions IAM pour AgentCore Runtime.

• Élargissez les autorisations à des ARN d'exécution spécifiques : évitez les instructions de ressources génériques. Utilisez l'ARN complet de vos ressources d'exécution dans les Resource champs de politique IAM.

• Restreindre InvokeAgentRuntimeForUser — Seuls les principaux de confiance devraient avoir cette autorisation. Appliquez-le à des ressources d'exécution spécifiques à l'aide des conditions de ressources IAM.

• Refuser la délégation d'identifiant d'utilisateur lorsque cela n'est pas nécessaire — Pour les environnements d'exécution où la délégation d'identifiant d'utilisateur n'est pas requise, refusez explicitement l'action :

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

• Empêcher l'augmentation des privilèges : assurez-vous que le rôle d'exécution associé à votre environnement d'exécution dispose de privilèges égaux ou inférieurs à ceux des principaux habilités à l'invoquer. Pour plus d'informations, consultez la section Gestion des informations d'identification.

• Utiliser des clés de condition IAM pour appliquer les déploiements de VPC : bedrock-agentcore:subnets utilisez bedrock-agentcore:securityGroups des clés de condition pour exiger que tous les environnements d'exécution soient déployés dans des VPC approuvés. Pour des exemples, consultez Utiliser les clés de condition VPC avec AgentCore Runtime.

• Utilisez IAM Access Analyzer : validez vos politiques IAM pour vous assurer qu'elles respectent les meilleures pratiques et les principes du moindre privilège.

• Comprendre l'autorisation hiérarchique : pour les opérations d'API d'exécution telles queInvokeAgentRuntime, et InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, AWS évalue les politiques à la fois sur le runtime de l'agent et sur le point de terminaison de l'agent. Les deux doivent autoriser l'action.

• Configurer les deux ressources pour un accès entre comptes : pour accorder un accès entre comptes, créez des politiques basées sur les ressources à la fois sur le runtime de l'agent et sur le point de terminaison de l'agent. Si l'une des ressources ne dispose pas d'une autorisation explicite, la demande est refusée.

• N'oubliez pas que le refus explicite gagne toujours : si une politique (basée sur l'identité ou basée sur les ressources) refuse explicitement une action, l'accès est refusé quelles que soient les autres politiques.

• Utilisez aws:SourceArn et aws:SourceAccount — Ajoutez les conditions suivantes à votre politique de confiance en matière de rôle d'exécution pour limiter AgentCore les ressources pouvant assumer ce rôle :

  {
    "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:*"
          }
        }
      }
    ]
  }

• Utilisez l'ARN complet lorsque cela est possible : si vous connaissez la ressource d'exécution spécifique, utilisez son ARN complet aws:SourceArn plutôt que des caractères génériques.

• Policy-based autorisation — Utilisez le moteur de politique de la passerelle pour contrôler quels appelants peuvent invoquer quelles cibles et dans quelles conditions. Pour plus d'informations, voir Utiliser des politiques pour contrôler l'accès aux cibles de passerelle.

• Garde-corps : appliquez Amazon Bedrock Guardrails via le moteur de politiques pour filtrer les demandes et les réponses. Pour plus d'informations, voir Utiliser des barrières de sécurité dans les politiques.

• Intercepteurs de demandes et de réponses : inspectez ou transformez le trafic à l'aide des fonctions Lambda d'interception configurées sur la passerelle.

• Runtimes IAM (SigV4) : associez une politique basée sur les ressources qui limite l'invocation au rôle d'exécution de la passerelle. Consultez Restreindre l'appel entrant IAM (SigV4) à votre passerelle.

• Runtimes OAuth (JWT) : configurez allowedWorkloadConfiguration sur l'autorisateur du moteur d'exécution. Consultez Restreindre l'invocation à votre passerelle.

• Choisissez la bonne méthode d'authentification : utilisez IAM SigV4 pour les appels interservices internes. AWS Utilisez l'authentification par jeton porteur JWT lorsque les utilisateurs finaux s'authentifient directement via un fournisseur d'identité. Un environnement d'exécution peut prendre en charge une méthode à la fois ; créez des versions distinctes pour différents types d'authentification.

• Préférez JWT-based l'identification de l'utilisateur pour la production — Lorsque votre agent récupère des jetons OAuth pour le compte des utilisateurs finaux, préférez le chemin du jeton porteur JWT (GetWorkloadAccessTokenForJWT), qui valide l'émetteur, la signature et l'expiration du jeton. Le UserId chemin (X-Amzn-Bedrock-AgentCore-Runtime-User-Iden-têteGetWorkloadAccessTokenForUserId/) traite l'identifiant utilisateur comme une chaîne opaque sans vérification de l'IdP. Utilisez-le uniquement pour le développement, les scénarios de démarrage rapide ou les architectures d'entreprise qui résolvent l'identité des utilisateurs en amont. Pour plus d'informations, voir Obtenir un jeton d'accès à la charge de travail.

• Configuration complète des autorisateurs JWT : lorsque vous utilisez l'authentification JWT, configurez tous les champs de validation disponibles : URL de découverte, audiences autorisées, clients autorisés, étendues autorisées et demandes personnalisées requises.

• Ne codez jamais de jetons en dur dans le code de production : utilisez des mécanismes sécurisés de récupération de jetons. Les jetons codés en dur constituent un risque de sécurité pour le contrôle des sources et les artefacts déployés.

• Dériver l'identifiant utilisateur du principal authentifié : si vous utilisez l'X-Amzn-Bedrock-AgentCore-Runtime-User-Iden-tête, la valeur doit être dérivée du contexte du principal authentifié (identité de l'appelant IAM ou revendications de jeton d'utilisateur), et non de valeurs arbitraires fournies par le client. Cela empêche les utilisateurs authentifiés de se faire passer pour d'autres utilisateurs.

• Refuser ForUserId là où cela n'est pas nécessaire : pour les charges de travail pour lesquelles un JWT est toujours disponible, refusez explicitement bedrock-agentcore:GetWorkloadAccessTokenForUserId et bedrock-agentcore:InvokeAgentRuntimeForUser dans les politiques IAM. Cela garantit que toutes les identifications des utilisateurs passent par le chemin JWT vérifié cryptographiquement.

• Configurez les politiques de point de terminaison VPC pour votre méthode d'authentification : les politiques de point de terminaison VPC ne peuvent restreindre les appelants qu'en fonction des principes IAM, et non des utilisateurs OAuth. Pour les OAuth-based demandes, définissez ce paramètre Principal sur * dans la politique du point de terminaison. Pour SigV4-based l'authentification, spécifiez les identités IAM autorisées.

• Utiliser AgentCore Identity pour l'authentification sortante : AgentCore Identity gère les informations d'identification OAuth et les clés d'API de manière sécurisée, empêchant ainsi toute exposition des informations d'identification dans le code ou les journaux de l'agent. Utilisez-le pour accéder à tous les services tiers (Slack GitHub, Zoom).

• Comprenez l'exposition aux informations d'identification MMDS — Le service de métadonnées MicroVM (MMDS) fournit des informations d'identification de rôle d'exécution à tout code exécuté sur la machine virtuelle, de la même manière que l'IMDS d'EC2. Étendez les autorisations des rôles d'exécution uniquement à ce dont votre agent a besoin.

• Activer MMDSv2 — À compter du 30 juin 2026, MMDSv2 doit être activé sur les environnements d'exécution de votre agent. Les environnements d'exécution sans MMDSv2 ne peuvent pas être invoqués et renvoyer un. ValidationException Pour l'activer, appelez UpdateAgentRuntime avec requireMMDSV2 set to true inmetadataConfiguration. Pour plus d'informations sur la résolution de cette erreur, consultez la section Résolution des problèmes liés au MMDSv2 ValidationException .

• Exécuter les conteneurs en tant qu'utilisateurs non root : lorsque vous créez des images de conteneurs personnalisées, configurez-les pour qu'elles s'exécutent en tant qu'utilisateur non root. Cela limite l'impact des vulnérabilités potentielles liées à l'exécution du code.

• Séparez les informations d'identification déléguées par l'utilisateur et les informations d'identification autonomes : utilisez l'authentification déléguée par l'utilisateur (autorisation de code d'autorisation) lorsque votre agent agit pour le compte d'un utilisateur spécifique. Utilisez l'authentification autonome (Client Credentials Grant) lorsque l'agent fonctionne de manière indépendante.

• Déployez des environnements d'exécution dans un VPC pour accéder à des ressources privées : configurez la connectivité VPC pour accéder à des bases de données privées, à des API internes et à des services sans les exposer à Internet. Pour plus de détails sur la configuration, consultez Configurer l' AgentCore environnement d'exécution pour VPC.

• Utilisation AWS PrivateLink pour l'accès aux API : créez des points de terminaison VPC d'interface pour le plan de AgentCore données (com.amazonaws.region.bedrock-agentcore) et le plan de contrôle () afin d'éviter la com.amazonaws.region.bedrock-agentcore-control traversée d'Internet. Pour plus d'informations, consultez la section Utilisation AWS PrivateLink.

• Appliquer le moindre privilège aux groupes de sécurité : définissez des règles sortantes qui n'autorisent que le trafic minimum requis. N'ouvrez pas d'accès sortant étendu sauf si cela est nécessaire.

• Configurer les points de terminaison VPC requis pour les agents de conteneur : pour les agents de VPC-mode conteneur, configurez les points de terminaison VPC pour ECR (com.amazonaws.region.ecr.dkr,com.amazonaws.region.ecr.api), S3 (point de terminaison de com.amazonaws.region.s3 passerelle) et Logs (). CloudWatch com.amazonaws.region.logs Le point de terminaison de la passerelle S3 élimine les frais de traitement des données de la passerelle NAT pour les extractions de couches d'images ECR.

• Étendue de la politique de point de terminaison de la passerelle S3 pour les agents de conteneur : limitez la politique de point de terminaison de la passerelle S3 au seul compartiment qu'Amazon ECR utilise pour le stockage de la couche image :

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

  regionRemplacez-le par votre identifiant de AWS région (par exemple,us-east-2).

• Étendue de la politique de point de terminaison de la passerelle S3 pour les agents de déploiement direct de code : pour les déploiements basés sur le zip, limitez la politique au compartiment d'artefacts de code interne appartenant au service. Ajoutez une aws:PrincipalServiceName condition pour garantir que seul le principal du AgentCore service peut accéder aux buckets via cette politique de point de terminaison :

  {
    "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"
          }
        }
      }
    ]
  }

  regionRemplacez-le par votre identifiant de AWS région (par exemple,us-west-2). Les compartiments d'artefacts de AgentCore code sont créés dans les compartiments à usage général de l'espace de noms régional du compte. AWS Seul le nom réel des compartiments utilisés par le service peut être propriétaire. Cette aws:PrincipalServiceName condition garantit que seul le principal du AgentCore service peut accéder aux buckets via cette politique de point de terminaison. Si vous utilisez également des systèmes de fichiers persistants, ajoutez le bucket de stockage de session à cette politique. Pour plus d'informations, consultez Configurer l' AgentCore environnement d'exécution pour VPC.

• Utiliser des sous-réseaux privés avec des passerelles NAT : les sous-réseaux publics ne fournissent pas d'accès à Internet pour Runtime. AgentCore Placez toujours les ENI d'exécution dans des sous-réseaux privés avec une route vers une passerelle NAT pour l'accès Internet sortant.

• Sécurité du transport : toutes les connexions utilisent le protocole TLS 1.2 ou supérieur. WebSocket les connexions, y comprisInvokeAgentRuntimeCommandShell, utilisent exclusivement WSS (WebSocket Secure) sur HTTPS. Les ws:// connexions en texte brut ne sont pas prises en charge.

• Appliquer les limites d'en-têtes : les en-têtes personnalisés sont limités à 4 Ko par valeur et à 20 en-têtes par exécution. L'Authorizationen-tête est réservé aux agents disposant d'un accès entrant OAuth.

• Chiffrement en transit : toutes les communications entre les clients et AgentCore Runtime, ainsi qu'entre AgentCore Runtime et ses dépendances, sont protégées par le protocole TLS 1.2 ou supérieur. Ceci est configuré par défaut et ne nécessite aucune configuration supplémentaire.

• Chiffrement au repos : les données au repos sont chiffrées par défaut à l'aide des AWS clés de chiffrement AWS détenues par le service de gestion des clés (AWS KMS).

• Utilisez le protocole TLS 1.3 dans la mesure du possible : le protocole TLS 1.2 est le minimum, mais le protocole TLS 1.3 est AWS recommandé pour améliorer la sécurité et les performances.

• Activer la CloudTrail journalisation : AWS CloudTrail enregistre les appels d'APIInvokeAgentRuntime, y comprisInvokeAgentRuntimeCommand,InvokeAgentRuntimeCommandShell, et les opérations du plan de contrôle. Chaque enregistrement inclut l'identité de l'appelant, l'horodatage, l'adresse IP source et l'état de la réponse.

• Utiliser CloudWatch les journaux pour l'audit des commandes : AgentCore Runtime envoie l'ID de demande et la commande d'entrée au groupe de CloudWatch journaux des journaux de votre agent. Utilisez ces journaux pour conserver une trace d'audit des commandes exécutées au cours de vos sessions.

• Corréler les journaux à l'aide des ID de demande : utilisez l'ID de demande pour corréler CloudTrail les enregistrements (qui a appelé l'API) avec CloudWatch les journaux (quelle commande a été exécutée).

• Configurer des filtres métriques et des alarmes : configurez CloudWatch les filtres métriques de Logs pour détecter des modèles de commande inattendus ou des tentatives d'accès non autorisées. Créez des alarmes pour signaler les anomalies à votre équipe.

• Enregistrez les relations de délégation d'identifiant utilisateur : lorsque vous utilisez l'X-Amzn-Bedrock-AgentCore-Runtime-User-Iden-tête, enregistrez la relation entre le principal IAM authentifié et la valeur de l'identifiant utilisateur à des fins d'audit.

• Activer les journaux de flux VPC : pour les environnements d' VPC-connected exécution, activez les journaux de flux VPC pour auditer le trafic au niveau du réseau et identifier les modèles de communication inattendus.

• Consultez régulièrement CloudTrail les journaux : vérifiez régulièrement les journaux pour détecter les tentatives d'accès non autorisées, en particulier pour les charges de travail sensibles.

AWS responsabilités :

• Infrastructure sécurisée et isolation des micromachines virtuelles au niveau du matériel

• Application de correctifs au noyau du système d'exploitation pour tous les modes de déploiement

• Correctifs d'exécution du langage pour les déploiements directs de code

• Sécurité de l'infrastructure réseau

• Disponibilité et résilience des services

Vos responsabilités :

• Sécurité du code agent et gestion des dépendances

• Contrôles d'accès et politiques de ressources IAM

• Sécurité des commandes exécutées lors des sessions d'exécution

• Session-to-user application de la cartographie

• Mises à jour des images de conteneurs (pour les déploiements de conteneurs) : reconstruisez régulièrement avec la dernière image de base sécurisée

• Validation des entrées et prévention des injections rapides, y compris la validation des InvokeHarness entrées lors de l'utilisation du harnais géré (voir Harness shares the AgentCore Runtime trust boundary)

• Configuration réseau (groupes de sécurité, points de terminaison VPC, tables de routage)

• InvokeAgentRuntimeCommand— One-shot, exécution de commande non interactive terminée. HTTP/2 Action IAM :bedrock-agentcore:InvokeAgentRuntimeCommand.

• InvokeAgentRuntimeCommandShell— Session WebSocket shell interactive avec accès PTY permanent. Action IAM :bedrock-agentcore:InvokeAgentRuntimeCommandShell.

• Comprenez les limites de sécurité — Les commandes ont un accès complet au système de fichiers du conteneur et à toutes les informations d'identification ou secrets configurés dans la microVM. La limite d'isolation est la microVM elle-même. Dans le cadre du modèle de responsabilité partagée, vous êtes responsable de la sécurité de tout code exécuté dans votre conteneur d'exécution.

• Utilisez des opérations déterministes pour les tâches déterministes : utilisez InvokeAgentRuntimeCommand ou InvokeAgentRuntimeCommandShell pour des opérations telles que les tests, git et les builds. N'acheminez pas les opérations déterministes via le LLM via. InvokeAgentRuntime

• Limiter les personnes autorisées à exécuter des commandes : utilisez les politiques IAM pour limiter les principaux autorisés à appeler InvokeAgentRuntimeCommand ou. InvokeAgentRuntimeCommandShell Tous les utilisateurs qui peuvent invoquer un agent ne devraient pas être en mesure d'exécuter des commandes arbitraires. Exemple d'ARN de ressource :arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent.

• WebSocket shell utilise wss ://uniquement — InvokeAgentRuntimeCommandShell les connexions sont établies exclusivement via WSS (WebSocket Secure). Les ws:// connexions en texte brut ne sont pas prises en charge. Les appelants s'authentifient via SigV4 lors de la mise à niveau. WebSocket

• Maintenez le trafic au sein de votre réseau : configurez les points de terminaison VPC pour éviter de traverser Internet pour les appels d'API d'exécution de commandes.

• Définissez des délais d'expiration appropriés : configurez les délais d'expiration des commandes en fonction de la durée d'exécution prévue afin d'éviter le gaspillage de ressources dû à des processus incontrôlables.

• Restreindre l'accès à localhost dans le code de l'agent : configurez votre agent et tous les outils réseau pour empêcher l'accès illimité à localhost. Le code de l'agent ne doit pas effectuer d'appels HTTP arbitraires à localhost, sauf si cela est nécessaire pour une intégration spécifique.

• Autoriser uniquement les ports requis pour les configurations de sidecar — Si votre architecture utilise un modèle conteneur-in-conteneur ou sidecar sur localhost, autorisez explicitement uniquement les ports spécifiques utilisés par vos services de side-car. N'ouvrez pas un accès étendu à localhost.

• Auditez les outils réseau pour vérifier la portée de l'hôte local : passez en revue tous les outils que vous fournissez à votre agent (tels que les outils de requête HTTP ou les utilitaires réseau généraux) pour vous assurer qu'il ne peut pas envoyer de demandes involontaires aux points de terminaison de l'hôte local. Appliquez un filtrage d'URL ou une liste d'autorisation au niveau de l'outil.