View a markdown version of this page

Sécurité et contrôles d'accès - Base rocheuse de l'Amazonie AgentCore

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurité et contrôles d'accès

Le harnais vous fournit les mêmes primitives de sécurité que les autres AgentCore, câblées par configuration.

  • Exécution isolée. Chaque session s'exécute dans sa propre microVM Firecracker in Runtime. AgentCore Aucun état partagé, aucun système de fichiers partagé.

  • Rôle d'exécution IAM. Le harnais assume un rôle IAM que vous possédez, configurable pour inclure Bedrock, ECR et les AgentCore primitives qu' CloudWatchil touche. Consultez un exemple de politique relative aux rôles d'exécution ci-dessous.

    Note

    Si le gestionnaire de rôles est activé dans votre compte, AgentCore le rôle est associé à votre place et l'étape de sélection du rôle décrite ici est remplacée par une option Personnaliser. Pour utiliser un autre rôle, choisissez Personnaliser. Pour plus d’informations, consultez Création de rôles IAM dans le Guide de l’utilisateur IAM.

  • Modèle d'autorisations IAM. Les API Harness nécessitent des autorisations à la fois sur la ressource Harness et sur la ressource AgentCore Runtime sous-jacente. Par exemple, les appels InvokeHarness nécessitent à la fois des bedrock-agentcore:InvokeAgentRuntime autorisations bedrock-agentcore:InvokeHarness et des autorisations sur l'ARN du harnais. Le même schéma s'applique aux opérations du plan de contrôle : UpdateHarness DeleteHarness nécessite bedrock-agentcore:UpdateAgentRuntimebedrock-agentcore:DeleteAgentRuntime, nécessite, etc. Consultez la politique relative aux rôles d'exécution pour obtenir la liste complète.

  • Support OAuth entrant. Les ressources du harnais configuré par JWT exigent que les appelants présentent un JWT valide émis par un fournisseur d'identité configuré avant de pouvoir invoquer le harnais. AgentCore L'identité transmet l'identité de l'utilisateur final à l'agent, de sorte que les outils en aval peuvent appeler des API avec des informations d'identification utilisateur étendues au lieu d'un compte de service partagé.

  • PVC. Connectez les sessions de harnais à votre VPC pour un accès privé aux ressources internes.

  • Politiques relatives à Gateway. Lorsque les outils sont fournis via AgentCore Gateway, des Cedar-based politiques peuvent être configurées pour bloquer chaque appel : qui peut appeler quel outil, dans quelles conditions, avec quels arguments.

Note

Sigv4 et identité par utilisateur. Lorsque les appelants s'authentifient avec SIGv4 (AWS IAM), le harnais ne propage pas l'identité par utilisateur dans les appels d'outils en aval. Cela signifie que les fonctionnalités de définition des informations d'identification par utilisateur dans AgentCore Identity Token Vault, telles que le stockage de jetons OAuth à l'échelle de l'utilisateur et l'échange de jetons au nom de l'utilisateur, ne sont disponibles que lorsque les appelants s'authentifient auprès d'un Bearer JWT via le chemin entrant OAuth. Si votre cas d'utilisation nécessite une définition des informations d'identification par utilisateur pour les outils en aval, configurez l'OAuth entrant sur le harnais. La prise en charge de Sigv4 pour l'identité par utilisateur est prévue dans une prochaine version.

Modèle de responsabilité partagée

Le harnais est basé sur AgentCore Runtime et la limite de sécurité est la même : authentification IAM ou JWT combinée à une isolation microVM. Tout mandant qui passe cette porte accède aux outils et fonctionnalités configurés sur le harnais, ce qui fait de l'autorisation de l'appelant et de la validation des entrées une responsabilité du client.

AWS responsabilités :
  • Infrastructure sécurisée et isolation des microVM au niveau matériel

  • Correctif du noyau du système d'exploitation

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

  • Code d'exécution du harnais géré, y compris la validation de la structure de demande InvokeHarness acceptée

  • 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

  • Validation des entrées et prévention rapide des injections, y compris la validation de toutes les InvokeHarness entrées (voirLimite de confiance et validation des entrées)

  • Validation de la configuration du modèle additionalParamsapiBase, tels que modelId les champs, et (voirParamètres de configuration du modèle)

  • Sources de compétences et d'instructions : s'assurer que les compartiments S3, les référentiels Git et les URL utilisés pour les compétences contiennent un contenu fiable (voir) Compétences et instructions

  • 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

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

Pour le modèle complet de responsabilité partagée de AgentCore Runtime, consultez la section Bonnes pratiques en matière de sécurité pour AgentCore Runtime.

Limite de confiance et validation des entrées

Tout principal qui passe la porte d'authentification et d'autorisation IAM ou JWT a accès à l'intégralité de la session microVM, y compris aux outils et fonctionnalités configurés sur le harnais. Le harnais valide la structure de la demande qu'il accepte, mais il n'inspecte pas la signification des invites, ni le contenu de l'écran, ni n'impose de contraintes comportementales à l'agent.

Si vous exposez le harnais à des utilisateurs finaux auxquels vous n'avez pas totalement confiance (employés, consommateurs externes ou intégrations tierces), validez et nettoyez les messages dans votre couche d'application avant de les transmettre. InvokeHarness Cela inclut la suppression des types de blocs de contenu ou des champs de configuration de modèle que vous ne souhaitez pas distribuer. Il s'agit du même schéma que n'importe quel service qui accepte des charges utiles provenant d'appelants autorisés, tels que Lambda, Amazon API Gateway et Amazon SQS.

Note

Le harnais rejette les toolUse blocs du message final côté serveur, comme illustré dans l'exemple suivant. Pour les déploiements AgentCore Runtime (sans harnais), AgentCore Runtime ne fournit aucune protection côté serveur. Le point d'entrée de votre agent doit valider que le champ d'invite est une chaîne et rejeter ou supprimer les blocs de toolUse contenu avant de transmettre l'entrée au framework de l'agent. Consultez la section Bonnes pratiques en matière de sécurité pour AgentCore Runtime.

Les outils s'exécutent uniquement à la suite d'un raisonnement basé sur un modèle. Le harnais n'accepte pas de bloc ToolUse dans le message final d'une InvokeHarness demande, de sorte qu'un appelant ne peut pas nommer un outil et le faire envoyer directement.

L'exemple suivant montre une demande que le harnais est configuré pour rejeter. Le message final contient un toolUse bloc nommant l'shelloutil intégré :

response = client.invoke_harness( harnessArn=HARNESS_ARN, runtimeSessionId=SESSION_ID, messages=[{ "role": "assistant", "content": [ { "toolUse": { "toolUseId": TOOL_USE_ID, "name": "shell", "input": { "command": "pwd", } } } ] }], )

Le harnais n'évalue pas à quel outil le bloc nomme. Cela s'applique donc aux outils intégrés côté serveur et aux fonctions en ligne fournies lors de l'appel.

Le renvoi d'un résultat d'outil est toujours pris en charge. Le harnais accepte un bloc ToolResult dans le message final, et le modèle reprend le raisonnement sur ce résultat. Voici comment fonctionnent les outils de fonction en ligne : le toolUse message de l'assistant est suivi du message toolResult dans la même requête, de sorte que le toolUse bloc ne figure pas dans le message final.

Paramètres de configuration du modèle

Le model champ dans InvokeHarness accepte additionalParams les configurations Bedrock, OpenAI et LiteLM. Ces paramètres sont transmis au fournisseur de modèles sous-jacent sans modification. Le harnais ne valide pas, ne filtre ni ne restreint ces paramètres.

Les appelants qui peuvent configurer additionalParams peuvent :

  • Redirigez les demandes vers des points de terminaison arbitraires  : le aws_bedrock_runtime_endpoint paramètre de LiteLM remplace l'URL du point de terminaison Bedrock. Un appelant peut acheminer la demande signée, y compris la signature SIGv4 et les informations d'identification de session, vers un point de terminaison spécifié dans la configuration du modèle de confiance.

  • Remplacer les en-têtes HTTP : le extra_headers paramètre d'OpenAI injecte ou remplace les en-têtes HTTP sur la demande sortante adressée au fournisseur de modèles, y compris l'en-tête. Authorization

  • Tenter d'assumer un rôle IAM  : le aws_role_name paramètre de LiteLLM indique au moteur d'exécution d'assumer un rôle IAM différent avant d'appeler le fournisseur de modèles. La tentative réussit ou échoue en fonction des sts:AssumeRole autorisations du rôle d'exécution.

  • Modifier le modèle ou la région cible - Les apiBase champs modelId et peuvent rediriger l'inférence vers un modèle, une région ou un fournisseur complètement différent.

Si votre application expose des InvokeHarness fonctionnalités à des appelants auxquels vous n'avez pas totalement confiance, envisagez de mettre en œuvre la validation des entrées dans votre couche d'application. En voici quelques exemples :

  • Supprimer ou autoriser la mise en liste du model champ avant de transmettre les demandes

  • Validation ou suppression additionalParamsapiBase, et modelId

  • Refuser sts:AssumeRole le rôle d'exécution si le changement de rôle n'est pas nécessaire

  • Délimitation de l'accès au réseau du harnais à l'aide de groupes de sécurité VPC

Compétences et instructions

Les compétences sont des ensembles de balises et de scripts que le harnais extrait d'Amazon S3 ou Git au moment de l'invocation et injecte dans le contexte de l'agent. Le harnais traite tout le contenu des compétences comme une donnée fiable. Il ne valide pas, ne nettoie ni n'inspecte le contenu ou la source des compétences avant de les fournir à l'agent.

Vous êtes responsable de :

  • S'assurer que les sources de compétences (compartiments S3, référentiels Git, URL) sont fiables et leur accès est contrôlé

  • Réviser le contenu des compétences, y compris les instructions de démarquage et les éventuels scripts intégrés, avant de les configurer sur le harnais

  • Contrôler quels principaux peuvent remplacer le skills champ par invocation, puisque les appelants peuvent pointer le harnais vers des sources S3 ou Git arbitraires

Les compétences peuvent être modifiées par appel. InvokeHarness Si votre application transmet les informations fournies par l'appelant àInvokeHarness, celui-ci peut fournir ses propres sources de compétences contenant des instructions ou des scripts arbitraires. Voici des exemples de mesures d'atténuation :

  • Supprimer ou ignorer le skills champ des demandes fournies par l'appelant

  • Autoriser la mise en liste des préfixes S3 ou des référentiels Git autorisés

Observabilité et corrélation des traces

Le harnais propage automatiquement les identifiants de corrélation aux AgentCore primitives en aval (passerelle, mémoire, interpréteur de code, navigateur) pour permettre des vues de trace unifiées dans. CloudWatch Ces identifiants sont utilisés à des fins d'observabilité uniquement ; ils ne sont jamais utilisés pour les décisions d'autorisation ou d'accès aux données.

Configuration réseau

Par défaut, les sessions de harnais s'exécutent sur le réseau public. Pour accéder à des ressources privées (bases de données, API internes, sous-réseaux privés), déployez le harnais dans votre VPC.

Exemple
AWS CLI/boto3
aws bedrock-agentcore-control create-harness \ --harness-name "VpcHarness" \ --execution-role-arn "arn:aws:iam::123456789012:role/MyHarnessRole" \ --environment '{"agentCoreRuntimeEnvironment": {"networkConfiguration": {"networkMode": "VPC", "vpcConfig": {"securityGroupIds": ["sg-0abc1234def56789a"], "subnetIds": ["subnet-0abc1234def56789a"]}}}}'
AgentCore CLI
agentcore add harness --name internal-agent \ --network-mode VPC \ --subnets subnet-0abc1234def56789a \ --security-groups sg-0abc1234def56789a agentcore deploy
Important

En mode VPC, le harnais extrait son conteneur d'applications géré d'un référentiel Amazon ECR privé situé dans la région du harnais au début de chaque session. Votre VPC n'a pas besoin d'une passerelle NAT ni d'un accès Internet pour effectuer ce pull. Créez plutôt des points de terminaison VPC d'interface pour com.amazonaws.<region>.ecr.dkr etcom.amazonaws.<region>.ecr.api, et un point de terminaison VPC de passerelle pourcom.amazonaws.<region>.s3, afin que l'image et ses couches soient résolues à l'intérieur de votre VPC. Si votre agent appelle Amazon Bedrock à des fins d'inférence, créez également un point de terminaison d'interface pour. com.amazonaws.<region>.bedrock-runtime Sans les points de terminaison requis, les sessions ne peuvent pas démarrer en raison des délais d'extraction des images. Le rôle d'exécution doit permettre l'extraction depuis le référentiel privé. Consultez la politique relative aux rôles d'exécution.

Pour obtenir des conseils supplémentaires sur la configuration du réseau, voir Configurer AgentCore Runtime et les outils intégrés Configuration VPC. Pour la connectivité API entrante via PrivateLink, consultez la section Points de terminaison de l'interface VPC.

OAuth entrant

Demandez aux appelants de présenter un JWT valide émis par un fournisseur d'identité configuré avant de pouvoir invoquer le harnais. AgentCore L'identité transmet l'identité de l'utilisateur final à l'agent, de sorte que les outils en aval peuvent appeler des API avec des informations d'identification utilisateur étendues au lieu d'un compte de service partagé.

Exemple
AWS CLI/boto3
aws bedrock-agentcore-control create-harness \ --harness-name "OAuthHarness" \ --execution-role-arn "arn:aws:iam::123456789012:role/MyHarnessRole" \ --authorizer-configuration '{"customJWTAuthorizer": {"discoveryUrl": "https://cognito-idp.us-west-2.amazonaws.com/<POOL_ID>/.well-known/openid-configuration", "allowedClients": ["<CLIENT_ID>"]}}'

Invoquez avec un jeton Bearer au lieu d'informations d'identification SIGv4 :

curl -X POST "https://bedrock-agentcore.us-west-2.amazonaws.com/harnesses/invoke?harnessArn=${HARNESS_ARN}" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ${ID_TOKEN}" \ -H "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id: $(uuidgen)" \ -d '{"messages": [{"role": "user", "content": [{"text": "Hi"}]}]}'
AgentCore CLI
agentcore add harness --name MyNewHarness \ --authorizer-type CUSTOM_JWT \ --discovery-url {DISCOVERY_URL} \ --allowed-clients {CLIENT_ID} agentcore deploy

Invoquez avec un jeton porteur :

agentcore invoke --harness MyNewHarness --bearer-token "{token}" "Hello"

Lorsque le point de terminaison de découverte OIDC de votre fournisseur d'identité n'est accessible que via PrivateLink, ajoutez des indicateurs de point de terminaison privé à l'autorisateur CUSTOM_JWT. Utilisez un point de terminaison VPC géré par des services :

agentcore add harness --name MyNewHarness \ --authorizer-type CUSTOM_JWT \ --discovery-url {DISCOVERY_URL} \ --allowed-clients {CLIENT_ID} \ --private-endpoint-vpc-id vpc-0abc1234def56789a \ --private-endpoint-subnets subnet-0abc1234def56789a,subnet-0def5678abc12349b \ --private-endpoint-ip-type IPV4 \ --private-endpoint-security-groups sg-0abc1234def56789a agentcore deploy

Ou pointez vers une configuration de ressources VPC Lattice existante au lieu d'un point de terminaison VPC géré :

agentcore add harness --name MyNewHarness \ --authorizer-type CUSTOM_JWT \ --discovery-url {DISCOVERY_URL} \ --allowed-clients {CLIENT_ID} \ --private-endpoint-lattice-arn rcfg-0abc1234def56789a agentcore deploy
Note

Les indicateurs de point de terminaison privé ne sont valides qu'avec. --authorizer-type CUSTOM_JWT --private-endpoint-vpc-idet s'--private-endpoint-lattice-arnexcluent mutuellement : choisissez-en une. Avec--private-endpoint-vpc-id, --private-endpoint-subnets et --private-endpoint-ip-type (IPV4ouIPV6) sont requis.

Consultez l'autorisateur JWT entrant pour le flux de configuration complet d'OAuth.

Interactive

Exécutez agentcore dans un répertoire de projet, sélectionnez Ajouter, choisissez Harness, puis passez aux paramètres avancés. Activez l'authentification (et le réseau pour l'accès au VPC) avec Space, puis appuyez sur Entrée.

  1. Choisissez le type d'autorisation : AWS IAM (par défaut) ou JWT personnalisé pour l'authentification OIDC bearer-token.

    Sélectionnez le type d'autorisation du harnais
  2. Pour Custom JWT, entrez l'URL de découverte OIDC.

    Configurer un JWT personnalisé : URL de découverte
  3. Sélectionnez les contraintes de jetons à valider : audiences autorisées, clients autorisés, étendues autorisées ou revendications personnalisées.

    Sélectionnez les contraintes JWT à configurer
  4. Choisissez la manière dont le harnais atteint le point de terminaison de découverte des IdP : aucun (accessible au public), une ressource VPC Lattice ou un point de terminaison VPC géré (). PrivateLink

    PrivateLink options pour le point de terminaison de découverte des IdP
  5. Pour Réseau, choisissez le mode VPC et indiquez les ID de sous-réseau et les ID de groupe de sécurité.

    Entrez les ID de sous-réseau VPC

Confirmez l'assistant, puis agentcore deploy lancez-le pour appliquer.

Informations complémentaires : AgentCore Identité · Autorisateur JWT entrant · informations d'identification sortantes https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-outbound-credential-provider.html

Politiques de passerelle

Lorsque les outils sont fournis via AgentCore Gateway, les Cedar-based politiques bloquent chaque appel : qui peut appeler quel outil, dans quelles conditions, avec quels arguments.

En savoir plus : AgentCore Politique · modèles courants

Politique relative aux rôles d'exécution

Le harnais assume un rôle d'exécution IAM que vous fournissez. La politique de confiance du rôle doit permettre au AgentCore responsable du service de l'assumer :

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "bedrock-agentcore.amazonaws.com"}, "Action": "sts:AssumeRole" }] }

Autorisations IAM requises pour les appelants

Les API de harnais nécessitent des autorisations à la fois sur la ressource de harnais et sur les ressources AgentCore d'exécution sous-jacentes et de AgentCore mémoire facultatives. Le tableau suivant répertorie les actions requises pour chaque API :

API Actions IAM requises

InvokeHarness

bedrock-agentcore:InvokeHarness, bedrock-agentcore:InvokeAgentRuntime

InvokeAgentRuntimeCommand

bedrock-agentcore:InvokeAgentRuntimeCommand, bedrock-agentcore:InvokeAgentRuntime

CreateHarness

bedrock-agentcore:CreateHarness, bedrock-agentcore:CreateAgentRuntime, bedrock-agentcore:CreateMemory

UpdateHarness

bedrock-agentcore:UpdateHarness, bedrock-agentcore:UpdateAgentRuntime, bedrock-agentcore:UpdateMemory

DeleteHarness

bedrock-agentcore:DeleteHarness, bedrock-agentcore:DeleteAgentRuntime, bedrock-agentcore:DeleteMemory

GetHarness

bedrock-agentcore:GetHarness

ListHarnesses

bedrock-agentcore:ListHarnesses

CreateHarnessEndpoint

bedrock-agentcore:CreateHarnessEndpoint, bedrock-agentcore:CreateAgentRuntimeEndpoint

UpdateHarnessEndpoint

bedrock-agentcore:UpdateHarnessEndpoint, bedrock-agentcore:UpdateAgentRuntimeEndpoint

DeleteHarnessEndpoint

bedrock-agentcore:DeleteHarnessEndpoint, bedrock-agentcore:DeleteAgentRuntimeEndpoint

GetHarnessEndpoint

bedrock-agentcore:GetHarnessEndpoint

ListHarnessEndpoints

bedrock-agentcore:ListHarnessEndpoints

ListHarnessVersions

bedrock-agentcore:ListHarnessVersions

La plupart des actions utilisent l'ARN du harnais comme étendue de ressource :arn:aws:bedrock-agentcore:<region>:<accountId>:harness/<id>. Les actions sur les terminaux utilisent également l'ARN du point de terminaison du harnais :arn:aws:bedrock-agentcore:<region>:<accountId>:harness/<id>/harness-endpoint/<endpointName>.

Les DeleteHarnessEndpoint actions GetHarnessEndpointUpdateHarnessEndpoint, et nécessitent à la fois l'ARN du harnais et l'ARN du point de terminaison. CreateHarnessEndpointnécessite uniquement l'ARN du harnais. Le point de terminaison n'existe pas encore, aucun ARN de point de terminaison n'est donc nécessaire. Lorsque vous invoquez un point de terminaison personnalisé InvokeHarness et que vous avez InvokeAgentRuntimeCommand besoin à la fois de l'ARN du harnais et de l'ARN du point de terminaison.

Exemple de politique relative aux rôles d'exécution

L'exemple suivant couvre un harnais sur le réseau public, qui extrait son image de conteneur géré d'Amazon ECR Public. Un harnais en mode VPC extrait l'image gérée d'un référentiel Amazon ECR privé dans la région du harnais, de sorte que son rôle d'exécution nécessite également des autorisations d'extraction ECR privées. Ajoutez les instructions en mode VPC : extraction d'image gérée depuis un ECR privé au rôle d'exécution d'un VPC-mode harnais.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockModelInvocation", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:<region>:<accountId>:*" ] }, { "Sid": "EcrPublicTokenAccess", "Effect": "Allow", "Action": [ "ecr-public:GetAuthorizationToken" ], "Resource": "*" }, { "Sid": "StsForEcrPublicPull", "Effect": "Allow", "Action": [ "sts:GetServiceBearerToken" ], "Resource": "*" }, { "Sid": "XRayTracingAccess", "Effect": "Allow", "Action": [ "xray:PutTraceSegments", "xray:PutTelemetryRecords", "xray:GetSamplingRules", "xray:GetSamplingTargets" ], "Resource": "*" }, { "Sid": "CloudWatchLogsGroup", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:DescribeLogStreams" ], "Resource": "arn:aws:logs:<region>:<accountId>:log-group:/aws/bedrock-agentcore/runtimes/*" }, { "Sid": "CloudWatchLogsDescribeGroups", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups" ], "Resource": "arn:aws:logs:<region>:<accountId>:log-group:*" }, { "Sid": "CloudWatchLogsStream", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:<region>:<accountId>:log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*" }, { "Sid": "CloudWatchLogsPutResourcePolicy", "Effect": "Allow", "Action": [ "logs:PutResourcePolicy" ], "Resource": "*" }, { "Sid": "CloudWatchMetricsPublish", "Effect": "Allow", "Resource": "*", "Action": "cloudwatch:PutMetricData", "Condition": { "StringEquals": { "cloudwatch:namespace": "bedrock-agentcore" } } }, { "Sid": "AgentCoreWorkloadIdentity", "Effect": "Allow", "Action": [ "bedrock-agentcore:GetWorkloadAccessToken", "bedrock-agentcore:GetWorkloadAccessTokenForJWT" ], "Resource": [ "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default", "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default/workload-identity/harness_<agentName>-*" ] }, { "Sid": "AgentCoreBrowserDefault", "Effect": "Allow", "Action": [ "bedrock-agentcore:StartBrowserSession", "bedrock-agentcore:StopBrowserSession", "bedrock-agentcore:GetBrowserSession", "bedrock-agentcore:ListBrowserSessions", "bedrock-agentcore:UpdateBrowserStream", "bedrock-agentcore:ConnectBrowserAutomationStream", "bedrock-agentcore:ConnectBrowserLiveViewStream" ], "Resource": "arn:aws:bedrock-agentcore:<region>:aws:browser/*" }, { "Sid": "AgentCoreCodeInterpreterDefault", "Effect": "Allow", "Action": [ "bedrock-agentcore:StartCodeInterpreterSession", "bedrock-agentcore:StopCodeInterpreterSession", "bedrock-agentcore:GetCodeInterpreterSession", "bedrock-agentcore:ListCodeInterpreterSessions", "bedrock-agentcore:InvokeCodeInterpreter" ], "Resource": "arn:aws:bedrock-agentcore:<region>:aws:code-interpreter/*" }, { "Sid": "AgentCoreMemory", "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateEvent", "bedrock-agentcore:DeleteEvent", "bedrock-agentcore:GetEvent", "bedrock-agentcore:ListEvents", "bedrock-agentcore:RetrieveMemoryRecords" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:memory/harness_<agentNameAbbrv>_*" } ] }

La AgentCore CLI crée automatiquement un rôle avec ces autorisations lorsque vous échafaudez un projet de harnais. La politique ci-dessus s'applique aux cas où vous créez vous-même le rôle.

Note

L'BedrockModelInvocationexemple de relevé ci-dessus permet d'invoquer tous les modèles de fondation dans toutes les régions et toutes les ressources Bedrock de votre compte. Pour réduire cela, remplacez les ARN des ressources par des profils d'inférence spécifiques, qui vous permettent d'acheminer les demandes entre les modèles et les régions avec un seul ARN. Par exemple : arn:aws:bedrock:<destination_regions>:<accountId>:inference-profile/<profileId> associé à toutes les régions autoriséesarn:aws:bedrock:<region>:<accountId>:foundation-model/<modelId>.

Pour les charges de travail de production, définissez Resource les valeurs jusqu'aux ARN spécifiques dont votre harnais a besoin plutôt que d'utiliser. "*"

Autorisations supplémentaires pour les fonctionnalités optionnelles

Vous trouverez ci-dessous des exemples de politiques que vous pouvez ajouter à votre rôle d'exécution en fonction des fonctionnalités utilisées par votre harnais. Suivez le principe du moindre privilège : n'accordez à votre agent de harnais que les outils et les informations d'identification spécifiques dont il a besoin pour effectuer des inférences. Voir Référence de l'espace réservé les définitions des espaces réservés.

Accès ECR privé (images de conteneurs personnalisées)

Ajoutez cette politique lorsque votre harnais utilise une image ECR privée pour un conteneur personnalisé.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ECRImageAccess", "Effect": "Allow", "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage" ], "Resource": "arn:aws:ecr:<ecrRegion>:<ecrAccountId>:repository/<ecrRepoName>" }, { "Sid": "ECRTokenAccess", "Effect": "Allow", "Action": "ecr:GetAuthorizationToken", "Resource": "*" } ] }

Mode VPC : extraction d'image gérée depuis un ECR privé

Ajoutez cette politique lorsque votre harnais s'exécute en mode VPC. En mode VPC, le harnais extrait son conteneur d'applications géré depuis un référentiel Amazon ECR privé situé dans la région du harnais (nomméeharness-<region>). Ce pull utilise un ECR privé au lieu d'Amazon ECR Public, de sorte que le rôle d'exécution nécessite des autorisations d'extraction ECR privées. Cette politique est distincte des autorisations personnalisées relatives aux images de conteneur  : elle s'applique à l'image AWS gérée même lorsque vous ne fournissez pas votre propre conteneur.

Le référentiel est détenu par un compte de AWS service, de sorte que le compte dans l'ARN du référentiel est remplacé par un caractère générique. Les autorisations d'extraction sont limitées à la région du harnais.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "EcrManagedImagePull", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer", "ecr:BatchCheckLayerAvailability" ], "Resource": "arn:aws:ecr:<region>:*:repository/harness-*" }, { "Sid": "EcrManagedImageToken", "Effect": "Allow", "Action": "ecr:GetAuthorizationToken", "Resource": "*" } ] }

Assurez-vous que les points de terminaison VPC requis existent dans votre VPC (voir Configuration réseau) : des points de terminaison d'interface pour com.amazonaws.<region>.ecr.dkr etcom.amazonaws.<region>.ecr.api, et un point de terminaison de passerelle pour. com.amazonaws.<region>.s3

AgentCore Mémoire

Ajoutez cette politique lorsque votre harnais utilise une instance de mémoire appartenant au client.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreMemory", "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateEvent", "bedrock-agentcore:DeleteEvent", "bedrock-agentcore:GetEvent", "bedrock-agentcore:ListEvents", "bedrock-agentcore:RetrieveMemoryRecords" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:memory/<memoryId>" } ] }

AgentCore Navigateur (personnalisé)

Ajoutez cette politique lorsque votre harnais utilise une ressource de navigateur personnalisée appartenant au client.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreBrowserCustom", "Effect": "Allow", "Action": [ "bedrock-agentcore:StartBrowserSession", "bedrock-agentcore:StopBrowserSession", "bedrock-agentcore:GetBrowserSession", "bedrock-agentcore:ListBrowserSessions", "bedrock-agentcore:UpdateBrowserStream", "bedrock-agentcore:ConnectBrowserAutomationStream", "bedrock-agentcore:ConnectBrowserLiveViewStream" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:browser-custom/<browserCustomId>" } ] }

AgentCore Interprète de code (personnalisé)

Ajoutez cette politique lorsque votre harnais utilise un interpréteur de code personnalisé appartenant au client.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreCodeInterpreterCustom", "Effect": "Allow", "Action": [ "bedrock-agentcore:StartCodeInterpreterSession", "bedrock-agentcore:StopCodeInterpreterSession", "bedrock-agentcore:GetCodeInterpreterSession", "bedrock-agentcore:ListCodeInterpreterSessions", "bedrock-agentcore:InvokeCodeInterpreter" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:code-interpreter-custom/<codeInterpreterCustomId>" } ] }

Passerelle AgentCore

Ajoutez cette politique lorsque votre harnais utilise une passerelle configurée avec l'authentification entrante SIGv4.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreGatewayAccess", "Effect": "Allow", "Action": "bedrock-agentcore:InvokeGateway", "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:gateway/<gatewayId>" } ] }

Sources de compétences dans Amazon S3 et Git

Ajoutez cette politique lorsque votre harnais récupère une compétence depuis une source Amazon S3. Le rôle d'exécution répertorie et télécharge les objets de compétence sous le préfixe du bucket.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreSkillS3Access", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::<skillBucket>", "arn:aws:s3:::<skillBucket>/*" ] } ] }

Pour récupérer une compétence à partir d'un dépôt Git privé, le harnais lit un jeton d'accès personnel provenant d'un fournisseur de clés d'API. Accordez la politique de fournisseur d'informations d'identification de clé d'API indiquée ci-dessous pour le fournisseur d'informations d'identification qui détient le jeton.

Fournisseur d'informations d'identification de clé d'API (références ARN d'en-tête OpenAI, Gemini, LiteLM ou MCP)

Ajoutez cette politique lorsque votre harnais utilise un fournisseur d'informations d'identification de clé d'API pour les fournisseurs de modèles tels qu'OpenAI, Gemini ou LiteLM.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreApiKeyTokenVaultDefault", "Effect": "Allow", "Action": "bedrock-agentcore:GetResourceApiKey", "Resource": [ "arn:aws:bedrock-agentcore:<region>:<accountId>:token-vault/default", "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default", "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default/workload-identity/harness_<agentName>-*" ] }, { "Sid": "AgentCoreApiKeyTokenVaultPerKey", "Effect": "Allow", "Action": "bedrock-agentcore:GetResourceApiKey", "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:token-vault/default/apikeycredentialprovider/<apiKeyName>" }, { "Sid": "AgentCoreApiKeySecret", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:<region>:<accountId>:secret:bedrock-agentcore-identity!default/apikey/<apiKeyName>-*" } ] }

Fournisseur d'informations d'identification OAuth2 (Gateway) OAuth-protected

Ajoutez cette politique lorsque votre harnais utilise un fournisseur d'informations d'identification OAuth2 pour les OAuth-protected outils de passerelle.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AgentCoreOAuth2TokenVaultDefault", "Effect": "Allow", "Action": "bedrock-agentcore:GetResourceOauth2Token", "Resource": [ "arn:aws:bedrock-agentcore:<region>:<accountId>:token-vault/default", "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default", "arn:aws:bedrock-agentcore:<region>:<accountId>:workload-identity-directory/default/workload-identity/harness_<agentName>-*" ] }, { "Sid": "AgentCoreOAuth2TokenVaultPerProvider", "Effect": "Allow", "Action": "bedrock-agentcore:GetResourceOauth2Token", "Resource": "arn:aws:bedrock-agentcore:<region>:<accountId>:token-vault/default/oauth2credentialprovider/<oauthProviderName>" }, { "Sid": "AgentCoreOAuth2Secret", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:<region>:<accountId>:secret:bedrock-agentcore-identity!default/oauth2/<oauthProviderName>-*" } ] }

Référence de l'espace réservé

Remplacez les espaces réservés suivants dans les politiques ci-dessus par des valeurs spécifiques à votre environnement :

Placeholder Description

<region>

La AWS région dans laquelle votre ressource est déployée.

<accountId>

Votre identifiant de AWS compte.

<agentName>

Le nom de l'agent de votre harnais.

<agentNameAbbrv>

Forme abrégée du nom de votre agent de harnais utilisée dans les noms de ressources AgentCore mémoire par défaut.

<memoryId>

L'ID de votre ressource AgentCore mémoire.

<browserCustomId>

L'ID de la ressource personnalisée de votre navigateur.

<codeInterpreterCustomId>

L'ID de votre ressource d'interpréteur de code personnalisé.

<gatewayId>

L'ID de votre ressource AgentCore Gateway.

<apiKeyName>

Le nom du fournisseur d'informations d'identification de votre clé API.

<skillBucket>

Le nom du compartiment S3 qui contient vos fichiers de compétences.

<oauthProviderName>

Le nom de votre fournisseur d'informations d'identification OAuth2.

<ecrRegion>

La région dans laquelle votre référentiel ECR est hébergé.

<ecrAccountId>

L'ID de AWS compte propriétaire du référentiel ECR.

<ecrRepoName>

Le nom de votre référentiel ECR.

Note

La fin des ressources -* de Secrets Manager explique le suffixe aléatoire que Secrets Manager ajoute aux ARN secrets.