Meilleures pratiques de sécurité pour AgentCore Runtime

• Comprenez la limite d'isolation  : chaque session utilisateur s'exécute sur 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 de la machine virtuelle. Une fois la session terminée, l'intégralité de la microVM est arrêtée et la mémoire est nettoyée.

• Appliquez les mappages de session à utilisateur dans votre backend, mais n'impose AgentCore pas les mappages de session à utilisateur. 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éfinissez 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 large accès 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 la référence complète, consultez la section Autorisations IAM pour AgentCore Runtime.

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

• Restreindre InvokeAgentRuntimeForUser  : seuls les administrateurs de confiance doivent disposer de cette autorisation. Étendez-le à des ressources d'exécution spécifiques à l'aide des conditions de ressources IAM.

• Refuser la délégation de l'identifiant utilisateur lorsque cela n'est pas nécessaire — Pour les environnements d'exécution où la délégation de l'identifiant 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'escalade 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 qui peuvent l'invoquer. Pour plus d'informations, consultez la section Gestion des informations d'identification.

• Utilisez les clés de condition IAM pour appliquer les déploiements de VPC — Utilisez bedrock-agentcore:subnets et bedrock-agentcore:securityGroups conditionnez les clés pour exiger que tous les environnements d'exécution soient déployés dans des VPC approuvés. Pour des exemples, consultez la section 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 l'exécution de l'agent et sur le point de terminaison de l'agent. Les deux doivent autoriser l'action.

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

• N'oubliez pas que le refus explicite l'emporte toujours  : si une politique (basée sur l'identité ou 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 ces conditions à votre politique de confiance relative aux rôles d'exécution afin de limiter AgentCore les ressources qui peuvent 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 au aws:SourceArn lieu de caractères génériques.

• Appliquez le type de chaîne dans le champ d'invite  : payload votre point d'entrée reçoit est analysé à partir d'un code JSON arbitraire. Un appelant peut envoyer une valeur autre qu'une chaîne (telle qu'une liste ou un objet) dans le prompt champ. Si votre framework d'agent accepte des blocs de contenu autres que des chaînes, en particulier des toolUse blocs, le framework peut envoyer directement un outil. Cela permet de contourner le raisonnement des modèles, les garde-fous et l'application rapide du système. Vérifiez toujours que l'invite est une chaîne avant de la transmettre à l'agent :

  @app.entrypoint
  def invoke(payload, context):
      user_message = payload.get("prompt", "")
      if not isinstance(user_message, str) or not user_message.strip():
          return {"error": "Invalid input: 'prompt' must be a non-empty string"}
      result = agent(user_message)
      return {"response": result.message}

• Rejeter ou supprimer les blocs de toolUse contenu  : si votre agent accepte les tableaux de messages structurés (pour les conversations en plusieurs étapes), filtrez tous les blocs de toolUse contenu des messages fournis par l'utilisateur. Un toolUse bloc dans l'historique des messages peut entraîner l'exécution immédiate de l'outil nommé par la boucle d'événements de l'infrastructure de l'agent, sans évaluation du modèle.

• Validez la structure de la charge utile à l'aide d'un schéma  : utilisez Pydantic, Zod ou une bibliothèque de schémas équivalente pour vous assurer que le corps de la requête est conforme à la structure que vous attendez. Définissez prompt comme str (nonAny) dans votre schéma :

  from pydantic import BaseModel
  
  class InvocationRequest(BaseModel):
      prompt: str  # Enforces string type at the schema level

• Ne vous fiez pas aux valeurs par défaut pour valider  : un modèle payload.get("prompt", "Hello") fournit une valeur par défaut mais ne rejette pas les entrées autres que des chaînes. La valeur renvoyée est celle envoyée par l'appelant, qui peut être un dict ou une liste contenant des blocs de contenu.

• 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.

• Guardrails  : appliquez Amazon Bedrock Guardrails via le moteur de politiques pour filtrer les demandes et les réponses. Pour plus d'informations, consultez la section Utiliser des barrières dans les politiques.

• Intercepteurs de requêtes et de réponses  : inspectez ou transformez le trafic à l'aide des fonctions d'intercepteur Lambda 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 la section Restreindre les appels entrants IAM (Sigv4) vers votre passerelle.

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

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

• Préférez JWT-based l'identification des utilisateurs 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 (GetWorkloadAccessTokenForUserId/X-Amzn-Bedrock-AgentCore-Runtime-User-Idheader) traite l'identifiant de l'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 autorisations 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 revendications 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 des jetons. Les jetons codés en dur constituent un risque de sécurité dans le contrôle des sources et les artefacts déployés.

• Dérivez l'identifiant utilisateur à partir 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 relatives au jeton utilisateur), et non à partir 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 des terminaux VPC pour votre méthode d'authentification  : les politiques des terminaux VPC peuvent uniquement restreindre les appelants en fonction des principaux IAM, et non des utilisateurs OAuth. Pour les OAuth-based demandes, définissez Principal ce paramètre sur * dans la politique des terminaux. Pour SigV4-based l'authentification, spécifiez les identités IAM autorisées.

• Utilisez AgentCore Identity pour l'authentification sortante — AgentCore Identity gère les informations d'identification OAuth et les clés d'API en toute sécurité, empêchant ainsi l'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 relatives aux rôles d'exécution uniquement à ce dont votre agent a besoin.

• Activez MMDSv2 — À compter du 30 juin 2026, MMDSv2 doit être activé sur les environnements d'exécution de vos agents. Les environnements d'exécution sur lesquels MMDSv2 n'est pas activé ne peuvent pas être invoqués et renvoient 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 des conteneurs en tant qu'utilisateur 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.

• Identifiants autonomes et délégués par l'utilisateur distincts  : utilisez l'authentification déléguée par l'utilisateur (octroi 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 la section Configurer AgentCore Runtime pour VPC.

• À utiliser AWS PrivateLink pour accéder à l'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 (com.amazonaws.region.bedrock-agentcore-control) afin d'éviter la traversée d'Internet. Pour plus d'informations, voir 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 un 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 passerelle S3 pour les agents de conteneurs — Limitez la politique de point de terminaison de passerelle S3 au seul compartiment utilisé par Amazon ECR pour le stockage de la couche d'image :

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

  regionRemplacez-le par l'identifiant de votre 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 au format zip, limitez la politique au compartiment d'artefacts de code appartenant au service interne. Ajoutez une aws:PrincipalServiceName condition pour garantir que seul le principal du AgentCore service peut accéder aux compartiments 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 l'identifiant de votre 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. Seul AWS peut être propriétaire des noms de compartiment réels utilisés par le service. La aws:PrincipalServiceName condition garantit que seul le principal du AgentCore service peut accéder aux compartiments 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 AgentCore Runtime pour VPC.

• Utilisez 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 WSS (WebSocket Secure) sur HTTPS exclusivement. Les ws:// connexions en texte brut ne sont pas prises en charge.

• Appliquez les limites d'en-tête  : 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, et entre AgentCore Runtime et ses dépendances, sont protégées par le protocole TLS 1.2 ou supérieur. Il est configuré par défaut et ne nécessite aucune configuration supplémentaire.

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

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

• Activez la CloudTrail journalisation  : AWS CloudTrail enregistre les appels d'APIInvokeAgentRuntime, y compris les opérations du plan de contrôle InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, 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.

• Utilisez CloudWatch les journaux pour l'audit des commandes  : AgentCore Runtime envoie l'ID de la demande et la commande de saisie au groupe de CloudWatch journaux Logs de votre agent. Utilisez ces journaux pour conserver une piste 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).

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

• Consigner les relations de délégation entre les identifiants utilisateurs  : 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  : examinez 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 microVM au niveau 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 des agents 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-les régulièrement avec la dernière image de base sécurisée

• Validation des entrées et prévention rapide des injections, 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 persistant. 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.

• Utiliser 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

• Restreindre les personnes autorisées à exécuter des commandes  : utilisez les politiques IAM pour limiter les personnes autorisées à appeler InvokeAgentRuntimeCommand ou. InvokeAgentRuntimeCommandShell Les utilisateurs qui peuvent invoquer un agent ne devraient pas tous ê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

• Conservez le trafic au sein de votre réseau — Configurez les points de terminaison VPC pour éviter la traversée d'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û à l'emballement des processus.

• 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.

• N'autorisez que les ports requis pour les configurations de sidecar — Si votre architecture utilise un modèle de conteneur dans un conteneur ou de side-car sur localhost, n'autorisez explicitement que les ports spécifiques utilisés par vos services de sidecar. N'ouvrez pas un accès étendu à l'hôte local.

• Auditez les outils réseau pour déterminer 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'ils ne peuvent pas envoyer de requêtes involontaires aux points de terminaison de l'hôte local. Appliquez un filtrage d'URL ou une liste d'autorisations au niveau de l'outil.