AWS impose des limites strictes aux agents IA alors que la course à la sécurité entre Amazon et Google s’intensifie

AWS a mis en place des limites applicables autour des agents IA, malgré le risque que des attaquants ou des données empoisonnées manipulent leur raisonnement. Cette initiative intensifie la compétition entre Amazon et Google pour déterminer quel cloud peut connecter en toute sécurité les agents aux systèmes métier de valeur.

Amazon Bedrock AgentCore Policy vérifie les actions d’outils demandées par un agent avant qu’elles n’atteignent le service sous-jacent. Un agent manipulé peut toujours produire une requête dangereuse, mais celle-ci devrait échouer lorsqu’elle entre en conflit avec une politique externe.

Cette distinction est importante, car les filtres de prompts n’ont jamais constitué une frontière de sécurité complète. Les modèles traitent les instructions et les données non fiables à travers les mêmes mécanismes probabilistes. AWS considère désormais le modèle comme un décideur non fiable plutôt que comme l’autorité finale.

Google Cloud et Microsoft suivent la même orientation générale via leurs propres contrôles d’identité, de passerelle et de flux d’informations. La concurrence émergente ne se limite plus à la qualité des modèles. Les fournisseurs cloud doivent montrer que les agents peuvent agir sans hériter d’un accès illimité à chaque système connecté.

AWS déplace l’autorisation hors de l’agent

AWS sépare ce qu’un agent veut faire de ce que l’infrastructure lui permet de faire.

Policy dans Amazon Bedrock AgentCore crée une frontière protectrice autour des interactions entre les agents et les outils. Le service intercepte les requêtes acheminées via une AgentCore Gateway, puis évalue chaque requête avant d’autoriser l’appel de l’outil.

Une AgentCore Gateway connecte les agents aux API, fonctions et autres outils via une interface gérée. Le moteur de politiques se situe à côté de cette connexion plutôt qu’au sein du prompt ou du code d’orchestration de l’agent.

Ce positionnement modifie le modèle de sécurité. Un prompt système peut indiquer à un agent de ne jamais récupérer des dossiers clients restreints. Toutefois, une injection de prompts peut convaincre le modèle d’ignorer cette instruction ou de l’interpréter différemment.

Un moteur d’autorisation externe n’a pas besoin que le modèle soit d’accord. Il évalue l’action proposée à l’aide de règles explicites, d’une identité authentifiée, de paramètres d’outil et du contexte de requête disponible.

AWS utilise Cedar, son langage d’autorisation open source, pour exprimer ces règles. Une politique Cedar identifie le principal qui effectue une requête, l’action demandée, la ressource protégée et les conditions éventuellement requises.

Le service applique une sémantique de refus par défaut. Une action ne reçoit aucun accès à moins qu’une politique ne l’autorise explicitement. Une interdiction correspondante prévaut également sur toute permission plus large qui pourrait autrement autoriser la requête.

AWS explique ces mécanismes dans son guide des politiques AgentCore. Le guide indique que chaque requête d’agent acheminée est évaluée avant que l’accès à l’outil ne soit accordé.

Les développeurs peuvent écrire du Cedar directement ou décrire les exigences en anglais courant. Le service de rédaction en langage naturel traduit ces exigences en politiques Cedar candidates.

AWS indique que le service valide les politiques générées par rapport au schéma d’outils de la passerelle. Il vérifie également les règles qui semblent trop permissives, trop restrictives ou impossibles à satisfaire.

Ce processus de génération ne rend pas les exigences vagues sûres pour autant. AWS avertit que les politiques en langage naturel nécessitent toujours une formulation précise et sans ambiguïté. Les équipes de sécurité doivent examiner le Cedar obtenu plutôt que de traiter la politique générée comme un code incontestable.

Le modèle qui crée une politique est également distinct du mécanisme qui l’applique. Une fois déployée, la politique formelle contrôle la décision d’autorisation au lieu de demander l’avis d’un autre modèle.

Prenons un agent interne de support doté d’outils pour consulter des comptes et émettre des remboursements. Une entreprise pourrait autoriser chaque représentant du support à consulter les comptes qui lui sont attribués, tout en ne permettant qu’aux superviseurs d’approuver des remboursements plus importants.

Si un e-mail contient des instructions malveillantes exigeant un remboursement, l’agent peut tenter l’opération. La passerelle peut toutefois la rejeter lorsque l’employé authentifié ne possède pas le rôle requis ou que le montant dépasse ce que prévoit la politique.

La requête refusée n’a jamais besoin d’atteindre le système de paiement. Ce résultat est plus robuste que de demander à l’agent de reconnaître chaque variante d’une instruction malveillante.

AgentCore Policy est généralement disponible dans 13 régions AWS, selon la documentation de publication d’AWS. Des politiques centralisées peuvent s’appliquer de manière cohérente à plusieurs agents et outils connectés via des passerelles associées.

L’intégration à CloudWatch enregistre les décisions d’autorisation à des fins de surveillance et d’audit. Ces enregistrements offrent aux équipes de sécurité une vision plus claire des actions que les agents ont demandées, autorisées ou refusées.

Le changement immédiat est donc architectural, et non cosmétique. AWS place un point de contrôle déterministe entre le comportement incertain des modèles et les systèmes d’entreprise à fort impact.

Pourquoi l’injection de prompts transforme la compétition entre Amazon et Google

La compétition cloud entre Amazon et Google dépend désormais de leur capacité à contenir les agents compromis, et non simplement à améliorer leurs réponses.

Les agents IA deviennent utiles lorsqu’ils peuvent récupérer des informations privées, appeler des API, envoyer des messages ou modifier des enregistrements. Ces mêmes autorisations déterminent les dommages possibles après une manipulation.

L’injection de prompts insère des instructions hostiles dans le contenu traité par un modèle. L’injection directe provient d’une requête utilisateur, tandis que l’injection indirecte peut se dissimuler dans des sites web, des documents, des e-mails ou des réponses d’outils.

Un agent qui étudie un fournisseur pourrait rencontrer des instructions intégrées à une page web. Ces instructions pourraient lui demander de récupérer des fichiers confidentiels et de les envoyer via un autre outil connecté.

Un filtre de contenu pourrait détecter un schéma d’attaque connu. Il pourrait aussi manquer une formulation inhabituelle, une commande encodée ou une séquence répartie sur plusieurs interactions.

Le problème sous-jacent dépasse les prompts malveillants. Un modèle peut halluciner une action, mal comprendre une règle métier ou combiner des outils individuellement acceptables dans un flux de travail inacceptable.

OWASP décrit cette situation comme une autonomie excessive. Le risque apparaît lorsqu’un LLM reçoit suffisamment de fonctionnalités ou d’autorisations pour provoquer des effets nuisibles après une sortie inattendue.

L’autorisation limite le rayon d’impact qui en résulte. Le système part du principe qu’un agent finira par prendre une mauvaise décision, puis empêche que cette décision ne devienne une action sans restriction.

Cette approche ressemble aux pratiques établies de sécurité cloud. Les applications ne devraient recevoir que les autorisations nécessaires à une tâche, tandis que les opérations sensibles devraient faire l’objet de contrôles supplémentaires.

Les agents compliquent ce principe, car ils sélectionnent les outils de manière dynamique. Ils peuvent aussi enchaîner de nombreux appels, conserver du contexte entre les étapes et fonctionner plus longtemps sans supervision directe.

Un compte de service statique disposant d’autorisations étendues peut donc devenir un passif sérieux. L’agent acquiert de fait toutes les capacités attachées à cette identité, indépendamment de l’utilisateur ou de la tâche concernée.

AWS peut associer les requêtes AgentCore à des utilisateurs OAuth ou à des entités AWS Identity and Access Management. Les politiques peuvent alors prendre en compte l’identité à l’origine d’une requête plutôt que de s’appuyer uniquement sur le rôle de service partagé de l’agent.

Google fait face au même enjeu à mesure qu’il étend les agents basés sur Gemini et les connexions Model Context Protocol. MCP est une interface standard qui permet aux modèles de découvrir et d’appeler des outils externes.

Les recommandations de sécurité MCP de Google préconisent des politiques de refus pour les accès de production, des autorisations étroitement limitées, la désinfection des entrées et la surveillance. Elles avertissent également que, dans le cas contraire, la sécurité peut dépendre entièrement de la programmation des agents.

Cette convergence est importante. La concurrence entre Amazon et Google s’est souvent concentrée sur la disponibilité des modèles, l’infrastructure, les plateformes de données et les outils de développement. L’autorisation des agents devient un autre critère d’achat majeur.

Les clients d’entreprise déploient rarement un agent comme un chatbot isolé. Ils veulent des agents connectés à des bases de données, des dépôts de code, des plateformes de support, des consoles cloud et des référentiels de connaissances internes.

Chaque connexion crée à la fois de l’utilité et de l’exposition. Un fournisseur cloud qui facilite la connexion mais dont l’autorisation est faible reporte le risque opérationnel sur le client.

AWS positionne AgentCore Policy comme une couche d’application réutilisable entre les frameworks et les modèles. Les développeurs peuvent utiliser AgentCore avec des agents conçus via plusieurs frameworks d’orchestration populaires.

Cette ouverture permet à AWS d’affirmer que la politique de sécurité doit rester stable même lorsqu’une entreprise change de modèle. Une organisation pourrait remplacer un modèle de fondation sans réécrire chaque règle d’autorisation.

Google peut défendre une position similaire grâce à ses contrôles d’identité cloud, Model Armor et ses autorisations au niveau des ressources. Son avantage réside dans sa proximité avec Google Workspace, Gemini et une vaste plateforme de données.

Microsoft accentue la pression avec l’identité Entra, Copilot et sa pile de développement d’agents. Le marché devient une compétition à trois pour déterminer qui contrôle la frontière entre le raisonnement de l’IA et l’exécution en entreprise.

Pour les acheteurs, la question pertinente entre Amazon et Google n’est pas de savoir quel modèle refuse toujours un prompt malveillant. Aucun fournisseur ne peut promettre de manière crédible un refus parfait pour chaque combinaison d’entrées et d’outils.

La meilleure question est ce qui se passe après l’échec du refus. Une plateforme sécurisée devrait limiter les outils, les enregistrements, les paramètres, les destinations et les séquences d’actions accessibles à l’agent compromis.

Les stratégies de sécurité d’Amazon et Google se rencontrent à la frontière des outils

AWS, Google et Microsoft convergent vers une application déterministe des règles, mais ils organisent cette application différemment.

AWS place AgentCore Policy directement sur le chemin de la passerelle. Chaque requête couverte d’un agent vers un outil atteint le moteur de politiques avant que l’appel demandé ne se poursuive.

Cedar fournit à AWS un langage formel que les équipes peuvent inspecter, valider et analyser. AWS a utilisé les concepts de Cedar au-delà des agents, ce qui aide à relier l’autorisation des agents aux pratiques établies de sécurité applicative.

Les chercheurs en sécurité de l’entreprise émettent une hypothèse sans détour au sujet du modèle lui-même. Leur analyse de sécurité de Cedar indique que les organisations devraient traiter un LLM comme un acteur non fiable dans une conception de défense en profondeur.

Cela ne signifie pas que le modèle est malveillant. Cela signifie que le système d’autorisation ne peut pas dépendre d’un comportement prévisible du modèle, car celui-ci est probabiliste et sensible à un contexte manipulé.

Les recommandations publiées par Google mettent actuellement l’accent sur des contrôles en couches autour des serveurs MCP et des ressources Google Cloud. Ces contrôles comprennent des politiques de refus, des identifiants à portée limitée, des environnements de test distincts, des entrées désinfectées et un accès restreint à la production.

Google recommande également d’empêcher les outils en lecture-écriture d’atteindre les ressources de production sauf si le flux de travail l’exige. Les fonctions de récupération restent importantes, car même une action autorisée peut produire un résultat indésirable.

La différence pratique peut apparaître dans l’expérience développeur. AWS propose un moteur de politiques AgentCore dédié avec une évaluation soutenue par Cedar au niveau de sa passerelle gérée.

Google peut s’appuyer sur Cloud IAM mature et sur des politiques propres à chaque produit. Toutefois, les développeurs doivent encore veiller à ce que chaque chemin d’outil pertinent passe réellement par le contrôle prévu.

Cette réserve s’applique également à AWS. AgentCore Policy régit le trafic acheminé via une AgentCore Gateway associée. Un agent disposant d’un autre chemin d’exécution pourrait contourner ce point de contrôle particulier.

Par exemple, une politique pourrait bloquer une opération S3 effectuée par l’intermédiaire d’un outil MCP géré. Cette restriction ne couvrirait pas automatiquement un outil shell distinct capable d’exécuter une commande équivalente.

Les revues d’architecture doivent donc recenser les capacités, et pas seulement les outils nommés. Les équipes de sécurité doivent se demander si un agent peut atteindre la même ressource via un SDK, une ligne de commande, un navigateur, une fonction ou un agent secondaire.

Microsoft développe une autre variante fondée sur le contrôle des flux d’information. Son middleware FIDES étiquette le contenu selon son intégrité et sa confidentialité, puis transmet ces étiquettes lors des appels d’outils.

Le modèle de sécurité FIDES de Microsoft peut empêcher un contenu non fiable d’influencer une opération sensible. Il peut également empêcher des données privées de circuler vers une destination publique.

Cette approche traite une faiblesse de l’autorisation à action unique. Une requête de base de données peut être autorisée, tout comme l’envoi d’un e-mail. Le comportement dangereux apparaît lorsque des résultats de requête privés sont transmis dans un e-mail externe.

AWS étend ses politiques vers une évaluation tenant compte de la session. Les contrôles temporels peuvent examiner les actions récentes d’un agent au lieu de juger chaque requête comme un événement isolé.

Cette orientation compte, car les attaquants peuvent répartir un objectif malveillant sur plusieurs étapes d’apparence légitime. Une séquence peut révéler un risque qu’aucune action individuelle ne met en évidence.

Un agent pourrait d’abord lire un portefeuille confidentiel, puis en calculer un résumé, avant de tenter une transmission externe. Chaque appel d’outil peut sembler valide sans que la trajectoire qui les relie ne soit prise en compte.

Pour les clients qui comparent les approches de sécurité d’Amazon et de Google, la couverture importe davantage que la terminologie. Un langage de politique formel offre peu de protection lorsque les voies d’exécution à haut risque restent hors du champ d’application.

La propagation de l’identité compte également. Le moteur de politique doit disposer d’informations fiables sur l’utilisateur, la charge de travail, la ressource, l’action et le contexte métier pertinent.

Une identité générique d’« agent » ne suffit pas lorsque l’agent sert de nombreux employés. Elle peut accorder à chaque utilisateur l’ensemble maximal des autorisations de l’agent et effacer la traçabilité fournie par les contrôles d’accès habituels.

Les organisations devraient préserver l’identité humaine ou de charge de travail à l’origine de chaque requête déléguée. Elles devraient également attribuer à l’agent sa propre identité contrainte, plutôt que de le dissimuler derrière un identifiant partagé.

Cette séparation aide à répondre à deux questions distinctes. La première consiste à déterminer si l’utilisateur peut demander l’action. La seconde, si cet agent peut effectuer cette action au moyen de cet outil précis.

Une politique centralisée réduit aussi les incohérences entre les équipes. Sans elle, chaque développeur peut implémenter l’autorisation dans des prompts, des middlewares personnalisés ou des gestionnaires d’outils individuels.

Ces contrôles dispersés deviennent difficiles à auditer. Ils dérivent également à mesure que les agents acquièrent de nouveaux outils, modèles et branches de workflow.

Une passerelle partagée ne peut pas remplacer toutes les autorisations au niveau des ressources. Elle peut offrir un point cohérent où les organisations appliquent une politique avant que l’intention de l’agent n’atteigne les services en aval.

La politique n’est aussi solide que sa couverture

AgentCore Policy réduit les risques, mais ne prouve pas qu’un agent hébergé sur AWS est sûr.

Le service contrôle les requêtes qui passent par sa passerelle configurée et son moteur de politique. Il ne peut pas régir les outils, identifiants ou itinéraires réseau que les développeurs laissent en dehors de cette limite.

Cela crée un problème de couverture. Une équipe de sécurité peut croire avoir bloqué une action dangereuse alors qu’un outil alternatif fournit un autre chemin vers la même ressource.

Des autorisations IAM trop larges peuvent aggraver cet écart. Si le rôle d’exécution d’un agent peut appeler directement des services, les restrictions de la passerelle doivent être associées à des politiques de ressource qui bloquent les chemins non autorisés.

La conception des politiques reste également difficile. La rédaction en langage naturel réduit la barrière syntaxique, mais ne résout ni les exigences métier vagues ni les hypothèses de sécurité manquantes.

« Autoriser les analystes à consulter les rapports appropriés » n’est pas une règle d’autorisation précise. L’organisation doit définir quels analystes, rapports, classifications, régions, clients et conditions opérationnelles sont considérés comme appropriés.

Le Cedar généré nécessite une revue, des tests et un contrôle des changements. Les équipes doivent tester les autorisations attendues, les refus attendus, les requêtes malformées, les contextes manquants et des combinaisons de paramètres délibérément adverses.

Une politique qui refuse tout entraîne une défaillance opérationnelle. Une règle qui autorise discrètement tout crée le problème inverse. Les deux résultats peuvent sembler syntaxiquement valides.

Les développeurs doivent également prendre en compte le contexte d’autorisation fourni par l’agent. Les attributs sensibles pour la sécurité doivent provenir de jetons d’identité fiables, de métadonnées de ressources ou d’une infrastructure contrôlée.

Le modèle ne devrait pas pouvoir déclarer qu’une transaction présente un faible risque ou qu’un document est public. Ces affirmations doivent être vérifiées en dehors du processus de raisonnement du modèle.

Les journaux d’audit introduisent une autre obligation. Enregistrer chaque décision facilite les enquêtes, mais les équipes doivent surveiller activement ces enregistrements et préserver un contexte utile.

Une action refusée peut indiquer qu’un contrôle de sécurité a fonctionné. Des refus répétés peuvent aussi révéler un workflow compromis, une erreur de politique ou un agent qui réessaie continuellement un objectif interdit.

Les actions autorisées méritent également de l’attention. Un attaquant peut abuser d’autorisations légitimes prises individuellement, en particulier lorsque les politiques ne tiennent pas compte de l’historique de session ou des mouvements de données.

L’approbation humaine reste utile pour les opérations irréversibles ou à fort impact. Toutefois, un écran d’approbation peut échouer lorsque l’agent fournit une description trompeuse de l’action demandée.

L’interface doit présenter des détails fiables provenant de la requête d’outil réelle. Les réviseurs ont besoin de connaître la destination, la ressource, les paramètres, la classification des données et l’effet attendu.

Les équipes de sécurité doivent également défendre le plan d’administration des politiques. Un agent ne devrait pas pouvoir modifier ses propres règles, associer un moteur de politique moins strict ou obtenir des identifiants donnant un accès plus large.

La séparation des responsabilités aide dans ce cas. Les développeurs peuvent proposer des changements de politique, tandis que les responsables de la sécurité examinent et déploient les modifications via des workflows contrôlés.

La même discipline s’applique aux systèmes internes de connaissances. Les équipes qui construisent une base de connaissances consultable devraient préserver les autorisations des documents avant d’exposer ce contenu à un agent.

La récupération devrait filtrer les enregistrements selon l’autorisation de l’utilisateur demandeur. Le modèle ne devrait recevoir que le sous-ensemble d’informations auquel l’utilisateur pourrait accéder directement.

Cette conception évite un mode de défaillance critique. Même un modèle manipulé avec succès ne peut pas révéler des informations qui ne sont jamais entrées dans son contexte accessible.

Les organisations devraient éviter de placer toute leur confiance dans la détection des injections de prompt. La détection ajoute une défense utile, mais des attaques inconnues et des instructions d’apparence bénigne peuvent échapper aux classificateurs.

AWS prend en charge Bedrock Guardrails au niveau des politiques afin d’évaluer les entrées et sorties de la passerelle. Cette fonctionnalité complète l’application de Cedar au lieu de la remplacer.

La différence est simple. Un guardrail estime si un contenu semble dangereux, tandis que l’autorisation décide si une opération demandée est permise.

La détection probabiliste et l’application déterministe résolvent des problèmes différents. Les combiner réduit la surface d’attaque sans prétendre que l’une ou l’autre couche détecte chaque défaillance.

La course à la sécurité entre Amazon et Google récompensera les fournisseurs qui rendent ces couches difficiles à contourner. Les promesses marketing sur des agents sûrs comptent moins qu’une couverture d’application démontrable.

Les clients devraient tester ces affirmations avec des exercices de red team impliquant des injections indirectes, des outils compromis, des voies d’exécution alternatives et des mouvements de données en plusieurs étapes.

Ils devraient également vérifier le comportement en cas d’échec. Un appel d’outil refusé doit arrêter l’opération protégée sans exposer de détails sensibles via des erreurs ou des chemins de repli.

AWS a établi un modèle par défaut plus robuste en plaçant la politique en dehors du code de l’agent. La question restante est de savoir si les clients configureront les identités et les itinéraires environnants avec le même soin.

Ce que les acheteurs d’entreprise devraient surveiller ensuite

La prochaine phase mettra à l’épreuve la couverture des politiques, la prise en compte des sessions et la portabilité entre plateformes d’agents concurrentes.

Le premier signal sera la vitesse à laquelle les clients adoptent les politiques temporelles. Les règles à requête unique fonctionnent bien pour des restrictions claires, mais de nombreuses attaques contre les agents émergent au travers de séquences d’actions autorisées.

L’évaluation temporelle peut détecter qu’un agent a lu des données sensibles avant de tenter un transfert externe. Elle peut aussi exiger une approbation supplémentaire après une séquence particulière d’opérations.

La difficulté concerne l’état et l’interprétation. Les systèmes doivent suivre suffisamment d’historique pour reconnaître des trajectoires dangereuses sans bloquer les workflows ordinaires ni ajouter une latence excessive.

Les acheteurs devraient rechercher une documentation technique publique décrivant précisément quelle quantité d’historique de session est évaluée. Ils devraient également demander comment l’état est isolé entre les utilisateurs, les agents et les tâches simultanées.

Le deuxième signal est la manière dont Google et Microsoft exposent des contrôles équivalents via leurs plateformes d’agents gérées. Les trois fournisseurs reconnaissent que les seules instructions de prompt ne peuvent pas protéger les systèmes connectés.

La réponse de Google comptera, car les agents Gemini peuvent se trouver à proximité du contenu Workspace, des données cloud et de l’infrastructure des développeurs. De solides autorisations de ressources existent déjà, mais une composition spécifique aux agents reste essentielle.

Microsoft peut combiner l’identité Entra avec Copilot, Agent Framework et des étiquettes de flux d’information. Son avantage dépendra d’une application cohérente entre les outils Microsoft et les outils tiers.

La comparaison entre Amazon et Google devrait se concentrer sur les parcours de bout en bout. Les acheteurs ont besoin de preuves que la politique suit une action depuis l’identité de l’utilisateur, en passant par le raisonnement de l’agent et l’exécution de la passerelle, jusqu’à l’accès final à la ressource.

Le troisième signal est celui des tests de sécurité indépendants. La documentation des fournisseurs décrit le comportement prévu, tandis que les red teams révèlent les routes manquantes, les identités confuses, les paramètres par défaut dangereux et les combinaisons d’outils inattendues.

Les tests devraient inclure une page web malveillante, un ticket de support empoisonné, une réponse MCP compromise et un document hostile dans un dépôt approuvé. Chaque source peut introduire des instructions indirectes dans le contexte d’un agent.

Les chercheurs devraient également tester si les agents peuvent transformer des requêtes interdites en actions techniquement différentes. Une exportation bloquée peut devenir un téléversement via navigateur, une commande shell, un message encodé ou une requête adressée à un autre agent.

Les résultats détermineront si une politique externe produit un confinement significatif ou seulement une couche de configuration supplémentaire. Les preuves les plus solides viendront d’attaques qui modifient le comportement du modèle mais ne parviennent toujours pas à franchir les limites d’autorisation.

Les entreprises n’ont pas besoin d’attendre ces résultats pour améliorer leur architecture. Elles peuvent commencer par inventorier chaque agent, outil, identifiant, source de données et destination sortante.

Chaque outil devrait recevoir le périmètre d’action le plus étroit possible. L’accès en lecture seule devrait rester séparé de la modification, de la suppression, du partage externe ou de l’exécution financière.

Les équipes devraient supprimer les identifiants permanents lorsque des délégations de courte durée peuvent fonctionner. Elles devraient préserver l’identité utilisateur entre les appels d’outils et consigner les opérations tentées comme celles achevées.

Les actions à fort impact devraient exiger un contexte d’approbation fiable. Les équipes de sécurité devraient tester régulièrement des chemins alternatifs vers les ressources protégées, plutôt que de valider uniquement l’itinéraire prévu par la passerelle.

Pour la décision d’Amazon et Google dans le cloud, les benchmarks de modèles ne suffisent plus. Les acheteurs devraient comparer les comportements de refus par défaut, la propagation des identités, l’analyse des politiques, le niveau de détail des audits, les contrôles de session et la couverture de l’application des règles.

Ils devraient également se demander comment les politiques résistent aux changements de modèles et de frameworks. Une autorisation étroitement liée à une implémentation d’agent particulière devient coûteuse à maintenir et plus facile à contourner lors des migrations.

AWS a fait un pari architectural clair. L’entreprise part du principe que le raisonnement des agents restera manipulable, puis en limite les conséquences grâce à des contrôles déterministes externes à l’agent.

Cette hypothèse est plus crédible que la promesse d’une obéissance parfaite du modèle. Elle reconnaît que des erreurs et des attaques surviendront, tout en préservant une autorité distincte sur les outils et les données.

Cette approche dépend toujours d’une configuration rigoureuse. Une politique de passerelle restrictive ne peut pas compenser un environnement d’exécution aux privilèges excessifs, un shell non géré ou des données récupérées avant le filtrage des autorisations.

Les équipes d’entreprise devraient désormais tester un workflow concret de bout en bout. Manipulez l’agent, observez les actions qu’il demande, puis vérifiez que les opérations protégées échouent à une frontière externe.

Ce test fournit un standard pratique pour Amazon, Google et toutes les autres plateformes d’agents : le modèle peut être trompé, mais l’infrastructure doit tout de même refuser.