View a markdown version of this page

Sécurité et contrôles d'accès - Amazon Bedrock AgentCore

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

Le harnais vous fournit les mêmes primitives de sécurité que le reste AgentCore, intégrées par configuration.

  • Exécution isolée. Chaque session s'exécute dans sa propre microVM Firecracker en cours d'exécution. AgentCore Pas d'état partagé, pas de 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.

  • 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, l'appel InvokeHarness nécessite à la fois bedrock-agentcore:InvokeHarness des bedrock-agentcore:InvokeAgentRuntime autorisations sur l'ARN du harnais. Le même schéma s'applique aux opérations du plan UpdateHarness de bedrock-agentcore:UpdateAgentRuntime contrôle DeleteHarness : bedrock-agentcore:DeleteAgentRuntime exigences, exigences, etc. Voir la politique des rôles d'exécution pour la liste complète.

  • Support OAuth entrant. Les ressources du harnais configuré par JWT nécessitent 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 définies au lieu d'un compte de service partagé.

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

  • Politiques relatives à Gateway. Lorsque des 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 le protocole OAuth entrant sur le harnais. La prise en charge de SigV4 pour l'identité par utilisateur est prévue pour une future version.

Modèle de responsabilité partagée

Le harnais est construit sur AgentCore Runtime. La limite de sécurité est la même : authentification IAM ou JWT combinée à l'isolation microVM. Le harnais n'ajoute pas de couche de sécurité entre l'appelant et la microVM.

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

  • Corriger le noyau du système d'exploitation

  • 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

  • Validation des entrées et prévention des injections rapides, 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, par exemple, et modelId champs (voirParamètres de configuration du modèle)

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

  • 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

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

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

Limite de confiance et validation des entrées

Toutes InvokeHarness les InvokeAgentRuntimeCommand entrées sont fiables. Tout principal qui passe le portail d'authentification et d'autorisation IAM ou JWT a accès à la session microVM complète, y compris aux outils et fonctionnalités configurés sur le harnais. Le harnais ne nettoie pas les entrées, ne filtre pas les blocs de contenu et n'impose pas de contraintes comportementales.

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

Paramètres de configuration du modèle

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

Les appelants qui peuvent configurer additionalParams peuvent :

  • Rediriger les demandes vers des points de terminaison arbitraires : le aws_bedrock_runtime_endpoint paramètre de LitellM 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 dans la demande sortante adressée au fournisseur de modèles, y compris l'en-tête. Authorization

  • Essayez d'attribuer 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 ne faites pas entièrement confiance, envisagez d'implémenter la validation des entrées dans votre couche d'application. En voici quelques exemples :

  • Supprimer ou autoriser le listage du model champ avant de transférer les demandes

  • Validation ou suppression additionalParamsapiBase, et modelId

  • Refus sts:AssumeRole du rôle d'exécution s'il n'est pas nécessaire de changer de rôle

  • 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 toutes les compétences comme des données fiables. Il ne valide, 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 que l'accès est contrôlé

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

  • Contrôler quels principes peuvent remplacer le skills champ par appel, car les appelants peuvent pointer le harnais vers des sources S3 ou Git arbitraires

Les compétences peuvent être annulées par appel. InvokeHarness Si votre application transmet les informations fournies par l'appelantInvokeHarness, 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 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 vers les AgentCore primitives situées en aval (passerelle, mémoire, interpréteur de code, navigateur) pour permettre des vues de trace unifiées dans. CloudWatch Ces identifiants ne sont utilisés qu'à des fins d'observabilité ; 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 Harness 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

Le harnais extrait son conteneur d'applications d'Amazon ECR Public au début de chaque session. Lorsqu'il est exécuté en mode VPC, votre VPC doit autoriser l'accès sortant à. public.ecr.aws Amazon ECR Public ne prend pas en charge les points de terminaison VPC. Votre VPC doit donc disposer d'une passerelle NAT avec une route vers une passerelle Internet. Si cette connectivité n'est pas disponible, les sessions ne démarreront pas en raison des délais d'extraction des images.

Pour obtenir des conseils supplémentaires sur la configuration du réseau, voir Configuration du AgentCore moteur d'exécution et des outils intégrés (VPC). Pour la connectivité aux API entrantes via PrivateLink, consultez la section Points de terminaison de l'interface VPC.

OAuth entrant

Exigez des appelants qu'ils 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 définies 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>"]}}'

Appelez avec un jeton Bearer au lieu des 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 depuis 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 un. Avec--private-endpoint-vpc-id, les deux --private-endpoint-subnets et --private-endpoint-ip-type (IPV4ouIPV6) sont obligatoires.

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

Interactive

Exécutez agentcore dans un répertoire de projet, sélectionnez Ajouter, choisissez Harness et 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'autorisateur : AWS IAM (par défaut) ou JWT personnalisé pour l'authentification par jeton porteur OIDC.

    Sélectionnez le type d'autorisateur 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 de l'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 fournissez les identifiants de sous-réseau et de groupe de sécurité.

    Entrez les ID de sous-réseau VPC

Confirmez l'assistant, puis exécutez agentcore deploy pour appliquer.

En savoir plus : AgentCore Identité · Autorisateur JWT entrant · informations d'identification sortantes

Politiques de passerelle

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

Pour en savoir plus : AgentCore Politique · modèles courants

Politique relative aux rôles d'exécution

Le harnais assume le rôle d'exécution IAM que vous fournissez. La politique de confiance du rôle doit permettre au directeur du AgentCore 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 Harness nécessitent des autorisations à la fois sur la ressource Harness, sur le AgentCore Runtime sous-jacent et sur les ressources 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 la ressource :arn:aws:bedrock-agentcore:<region>:<accountId>:harness/<id>. Les actions du point de terminaison 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, donc aucun ARN de point de terminaison n'est 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 des rôles d'exécution

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

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

Note

L'BedrockModelInvocationexemple de déclaration 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 limiter 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> jumelé à 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 en fonction des 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. Respectez le principe du moindre privilège : accordez à votre agent de harnais uniquement les outils et informations d'identification spécifiques dont il a besoin pour ses inférences. Voir Référence à un espace réservé pour 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": "*" } ] }

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 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 depuis un dépôt Git privé, le harnais lit un jeton d'accès personnel provenant d'un fournisseur d'informations d'identification de clé 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, LitellM ou MCP)

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

{ "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 à un 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>

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

<accountId>

L'identifiant AWS de votre compte.

<agentName>

Le nom de votre agent de harnais.

<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 de votre fournisseur d'informations d'identification de clé d'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>

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

<ecrAccountId>

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

<ecrRepoName>

Le nom de votre référentiel ECR.

Note

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