Amazon Web Services ajoute des politiques temporelles à Amazon Bedrock AgentCore, offrant aux développeurs un moyen d’autoriser l’action actuelle d’un agent IA en fonction de ce qu’il a fait plus tôt dans la même session. Ce contrôle est conçu pour les workflows où un appel d’outil individuel peut sembler sûr, mais devient risqué à cause de la séquence qui l’a précédé.

Ce changement comble une lacune du contrôle d’accès traditionnel. Les permissions applicatives classiques évaluent souvent les requêtes indépendamment, tandis que les agents IA choisissent les outils, les arguments et l’ordre d’exécution au moment de l’exécution. AWS indique que sa nouvelle approche peut imposer des étapes de workflow obligatoires, préserver l’intégrité des données entre les appels d’outils, limiter l’exposition financière cumulée et exiger une approbation humaine avant des actions sensibles.

Ce qu’AWS change

AWS décrit les politiques temporelles comme une extension avec état des contrôles de politique existants dans Bedrock AgentCore. Plutôt que de se demander seulement si un principal peut appeler un outil particulier, le moteur de politique peut inspecter la trajectoire récente de l’agent et décider si la requête actuelle est autorisée dans ce contexte.

Par exemple, un agent peut utiliser un outil de recherche de client, recevoir un numéro de compte, puis transmettre un numéro différent à un outil de transfert de fonds. Les deux appels pourraient satisfaire des permissions sans état. Une politique temporelle pourrait exiger que l’argument de transfert corresponde à la sortie précédente de l’outil, bloquant la requête si l’agent a modifié ou inventé la valeur.

D’autres exemples dans le AWS Machine Learning Blog incluent l’obligation d’une recherche de portefeuille avant une transaction, la garantie qu’une requête de données a eu lieu assez récemment pour étayer une décision, et l’arrêt d’une session lorsque l’exposition cumulative aux opérations atteint une limite définie. AWS décrit également des contrôles visant à empêcher des actions contradictoires, comme le fait qu’un agent approuve et refuse la même demande d’assurance à très peu de temps d’intervalle.

La fonctionnalité fait partie d’Amazon Bedrock AgentCore, l’ensemble de services d’AWS pour créer et exploiter des agents IA. Son point d’application est AgentCore Gateway, qui achemine le trafic pris en charge entre modèles, outils et agents via un point de terminaison central.

Comment fonctionne l’autorisation temporelle

Une requête évaluée par une politique temporelle porte l’en-tête x-amzn-bedrock-agentcore-policy-session-id. Cet identifiant relie la requête à une trajectoire contenant les actions, entrées et sorties antérieures pertinentes. Les équipes applicatives décident si une session représente une conversation, une tâche en plusieurs étapes ou un workflow de plus longue durée.

AWS recommande de garder les sessions relativement étroites, car une seule requête d’autorisation peut être active à la fois par session. Le service combine l’identifiant de session avec l’identité de l’utilisateur final, de sorte que deux utilisateurs présentant le même identifiant sont tout de même évalués par rapport à des trajectoires distinctes. AWS indique que la fenêtre d’historique est limitée à 24 heures, après quoi les événements plus anciens sont supprimés automatiquement.

Les politiques temporelles s’exécutent à la passerelle plutôt que dans le code propre de l’agent. Cette architecture est importante : un agent ne peut pas réécrire la logique de la politique ni manipuler directement l’état utilisé pour l’autorisation. AWS indique que le moteur renvoie un résultat déterministe d’autorisation ou de refus, enregistre le contexte de décision, refuse par défaut, et donne la priorité aux interdictions lorsque les règles d’autorisation et d’interdiction entrent en conflit.

Les contrôles ne constituent pas une couche d’orchestration. Ils ne transforment pas les requêtes, n’analysent pas les données et ne décident pas quel outil un agent doit appeler. Leur rôle est plus restreint : déterminer si une requête routée via la passerelle est autorisée compte tenu de l’historique observé.

Preuves et détails de mise en œuvre

La principale preuve du changement est la publication technique d’AWS elle-même, qui fournit la description de la fonctionnalité et un exemple détaillé impliquant un agent de banque privée. Dans ce scénario, l’agent récupère des informations client, charge les positions de portefeuille, obtient des prix de marché, effectue des analyses et exécute des transactions pour le compte de conseillers financiers.

AWS indique que l’exemple utilise Amazon Cognito pour l’identité, des JSON Web Tokens pour l’authentification entrante et des outils MCP exposés via AgentCore Gateway. Le langage de politique utilisé dans l’exemple est Dogwood, qu’AWS décrit comme un langage de gouvernance open source pour les agents et leurs outils. Selon AWS, Dogwood peut évaluer des politiques Cedar existantes tout en ajoutant la prise en charge de conditions temporelles, permettant aux clients de conserver leurs règles Cedar actuelles plutôt que de migrer.

La source ne fournit pas de résultats de tests indépendants, de chiffres d’adoption par les clients ni de preuve que les contrôles empêchent toutes les classes d’échec des agents. Les affirmations sur la résistance au contournement et le comportement opérationnel relèvent des revendications produit et architecture d’AWS. L’élément média disponible reprend le titre de l’annonce, mais n’ajoute aucun détail rapporté de manière indépendante.

Il existe aussi des contraintes opérationnelles pour les équipes qui évaluent la fonctionnalité. L’absence d’en-tête de session peut amener AgentCore à générer une nouvelle session, ce qui signifie que le moteur de politique voit une trajectoire vide plutôt que l’historique prévu. AWS indique que les modifications de politique invalident les sessions existantes afin que les décisions ultérieures utilisent l’ensemble de politiques actuel et le schéma d’événements attendu. Ces comportements font de la gestion des sessions et du déploiement des politiques une partie de la conception de sécurité, et non de simples détails de configuration.

Pourquoi cela compte pour les développeurs et les entreprises

Pour les créateurs d’IA, les politiques temporelles offrent un point de contrôle pour un problème difficile à résoudre de façon fiable avec des prompts ou des vérifications côté application : maintenir des invariants à travers une séquence d’actions choisies par le modèle. Une politique peut exiger qu’un appel d’outil utilise une sortie précédemment vérifiée, qu’une action à fort impact suive une procédure définie, ou qu’un événement d’approbation humaine précède l’exécution.

Pour les entreprises, la valeur principale réside dans la cohérence à la frontière où le trafic des agents atteint les outils et les modèles. Une passerelle partagée peut appliquer des règles aux appels MCP, aux appels d’inférence de modèle et aux interactions agent-à-agent lorsque ces requêtes transitent par AgentCore Gateway. Cela pourrait réduire le besoin pour chaque implémentation d’agent de reproduire les contrôles de workflow, même si les équipes doivent toujours concevoir les politiques, le modèle d’identité, les limites de session et le processus d’approbation.

L’approche peut également aider à limiter les risques financiers ou opérationnels bornés. Une règle sans état peut par exemple limiter la taille d’une transaction, mais elle ne peut pas, à elle seule, déterminer combien d’exposition s’est accumulée au cours d’une session. L’état temporel rend ce type de contrainte cumulative exprimable. Le compromis est une dépendance accrue à une capture précise des événements et à des trajectoires soigneusement délimitées. Une nouvelle session peut aussi supprimer l’historique qu’une politique s’attendait à inspecter.

Cela positionne AgentCore plus directement face aux plateformes d’agents qui mettent l’accent sur la gouvernance à l’exécution, les permissions d’outils et les contrôles avec intervention humaine. Les éléments disponibles ne suffisent pas à comparer l’implémentation d’AWS aux produits concurrents en matière de latence, d’expressivité des politiques ou de coût de déploiement.

Ce qu’il faut surveiller ensuite

Les prochains signaux seront pratiques plutôt que promotionnels. Les développeurs devraient rechercher une documentation plus large sur Dogwood et sa sémantique temporelle, des exemples au-delà du workflow bancaire, ainsi que des détails sur la latence d’évaluation des politiques et la journalisation à l’échelle de la production.

Les acheteurs d’entreprise devraient aussi examiner comment les équipes peuvent tester des règles dépendantes de la trajectoire, récupérer des sessions échouées ou abandonnées et gérer les changements de politique sans perturber les workflows légitimes. Des retours clients indépendants aideraient à déterminer si l’application au niveau de la passerelle réduit les incidents ou l’effort d’implémentation par rapport aux contrôles intégrés dans le code de l’agent.

La portée du trafic pris en charge comptera également. AWS indique que les politiques temporelles peuvent régir les appels de modèle, d’outil MCP et d’agent-à-agent acheminés via la passerelle ; l’adoption dépendra de la proportion de l’architecture d’agents d’une organisation pouvant utiliser ce chemin sans créer de goulot d’étranglement.

Point de vue Creati.ai

AWS répond à une faiblesse réelle de la sécurité des agents : les décisions d’autorisation ont souvent besoin de mémoire. Le risque le plus important n’est pas toujours un appel d’outil interdit, mais un appel autorisé après une recherche non fiable, une récupération de données obsolètes, une approbation manquante ou une activité antérieure excessive.

Les politiques temporelles ne rendent pas les agents fiables à elles seules. Elles créent une frontière d’application plus solide autour du comportement des agents, à condition que les développeurs définissent des identités de session fiables, capturent les bons événements et testent les politiques contre des séquences d’échec. Pour les équipes qui déplacent des agents vers la finance, le service client ou d’autres workflows à fort impact, cette distinction — application des politiques plutôt que conformité du modèle — pourrait être l’avancée la plus significative.