Dans plusieurs incidents récents que nous avons investigués chez KPMG, nous avons observé des tentatives d’accès à Amazon Bedrock dès les premières étapes de l’intrusion, puis de manière répétée. Ce constat ne démontre pas, à lui seul, que les attaquants ont réussi à utiliser les modèles ou qu’ils poursuivaient tous le même objectif. Il met de l’avant toutefois l’intérêt d’examiner la valeur que représente un accès Bedrock pour un attaquant et de comparer ces tentatives aux abus déjà documentés publiquement.
L’accès aux modèles est désormais une ressource que des attaquants peuvent consommer ou revendre aux frais de l’organisation compromise. Ce détournement, généralement appelé LLMjacking, est documenté sur Bedrock depuis 2024. Il faut le distinguer d’une vulnérabilité de la plateforme AWS : les cas examinés reposent principalement sur des identifiants compromis et sur les permissions associées.[13][17]
Ce qu’un attaquant pourrait concrètement réaliser avec un accès Bedrock
Bedrock fournit un accès géré à des modèles de fondation. Un attaquant qui détient les autorisations d’inférence nécessaires peut donc obtenir des réponses sans héberger lui-même ces modèles ni payer les requêtes depuis son propre compte. Il peut utiliser cette capacité directement ou l’intégrer à une application qui sert d’autres utilisateurs. Selon les modèles accessibles, cette capacité peut servir à produire et traduire des textes, aider à écrire du code ou analyser des documents. Son utilisation pour préparer des messages frauduleux ou assister des opérations offensives constitue un scénario plausible, mais elle ne doit pas être présentée comme l’objectif démontré de chaque accès non autorisé.[1][15]
Le catalogue de modèles à poids ouverts (open-weight) de Bedrock ne se limite pas à OpenAI. AWS propose notamment les modèles GLM de Z.ai (Zhipu AI), dont GLM 4.7, GLM 5 et GLM 5.3. Ce dernier est disponible depuis le 5 octobre 2026 pour les clients d’entreprise admissibles, via des profils d’inférence interrégionale ; sa présence au catalogue ne signifie donc pas qu’il soit accessible à toute identité compromise.[27][28]
Ces capacités peuvent effectivement servir à des opérations offensives. AWS documente lui-même l’utilisation de GLM 5.3 sur Bedrock avec Strix, un agent de test d’intrusion qui recherche des vulnérabilités et tente de les valider par des preuves de concept, dans un cadre explicitement autorisé.[29] Un attaquant pourrait détourner cette capacité pour assister la recherche et l’exploitation de vulnérabilités contre des cibles non autorisées. Il s’agit ici d’un scénario de détournement d’une capacité documentée, pas d’un incident GLM sur Bedrock démontré par cette source. Les interactions avec les cibles seraient réalisées par les outils connectés à l’agent, dans l’environnement de l’opérateur ; le seul appel d’inférence Bedrock n’exécute pas une attaque sur un système tiers.
On ne peut donc pas déduire des protections décrites par OpenAI que tous les modèles du catalogue résisteraient de la même manière aux usages malveillants. Inversement, ni l’ouverture des poids ni l’origine du fournisseur ne démontrent qu’un modèle accepte toute demande « sans restrictions ». Un simple droit d’inférence ne permet pas non plus de modifier les poids du modèle servi ; personnaliser une copie constitue un scénario distinct.[26] Pour l’organisation, la protection doit reposer sur les autorisations IAM/SCP et sur les guardrails effectivement imposés sur les chemins compatibles, plutôt que sur les seuls refus supposés du modèle.[2][5] Les politiques AWS interdisent les usages non autorisés, mais cette interdiction ne constitue pas à elle seule un blocage technique de chaque demande offensive.[12][29]
Le bénéfice le plus immédiat ne nécessite d’ailleurs pas que le modèle produise un contenu interdit. Un service de programmation ou un chatbot peut générer des réponses ordinaires tout en consommant une capacité d’inférence dérobée. Le préjudice pour la victime réside alors dans la facturation, la consommation de quotas et la persistance d’un accès illégitime. À l’inverse, obtenir le droit d’invoquer un modèle ne donne pas automatiquement accès aux documents internes, aux données d’apprentissage du fournisseur ou à l’ensemble du compte AWS. L’accès à une base de connaissances ou l’exécution d’actions par un agent dépend d’autres permissions et intégrations, qu’il faut évaluer séparément.[4][17]
Les restrictions existent, mais elles ne répondent pas toutes au même problème. AWS impose une politique d’utilisation responsable et permet d’exiger un guardrail pour certaines API d’inférence. Ces mécanismes complètent le contrôle d’accès ; ils ne remplacent pas la vérification de l’identité et du droit de consommer la ressource. Un filtre de contenu ne peut pas, à lui seul, empêcher qu’un identifiant volé finance une application dont les demandes semblent acceptables.[5][12]
La configuration actuelle mérite également de revoir certaines hypothèses héritées des premiers déploiements. Depuis la simplification annoncée en octobre 2025, l’absence d’activation manuelle d’un modèle n’est plus une protection sur laquelle compter dans les régions commerciales. AWS précise que le contrôle doit reposer sur IAM et les SCP, ce qui selon notre expérience est rarement implanté de manière correcte par les clients. Les prérequis varient encore selon les modèles et les comptes, et refuser uniquement les souscriptions Marketplace ne suffit pas à bloquer toute invocation. L’ancienne permission PutFoundationModelEntitlement, présente dans des rapports historiques, n’a plus d’effet.[2][3] Mandiant observe d’ailleurs que, dans plusieurs incidents de 2026, les services de modèles n’étaient pas activés au moment de la compromission : ce sont les identifiants détournés qui ont permis de les activer, Bedrock étant cité parmi ces services.[24]
Ce que les incidents publics établissent déjà
Les premières publications ne démontraient pas toutes une consommation réussie. En mai 2024, Sysdig décrit notamment des appels InvokeModel volontairement invalides destinés à tester les capacités d’identifiants volés. Une erreur de validation constituait un indice de reconnaissance, pas la preuve qu’une réponse avait été générée. En septembre 2024, l’équipe publie cependant des observations de prompts et de réponses obtenus via Bedrock, ainsi que des tentatives d’activation de modèles et des actions visant la journalisation détaillée.[13][14]
Permiso apporte un élément particulièrement proche de notre constat initial. Dans son rapport du 3 octobre 2024, l’équipe distingue des incidents clients d’une expérience en honeypot : après publication d’une clé de leurre sur GitHub, les premières tentatives Bedrock arrivent en quelques minutes. Dans ce même environnement de recherche, elle observe ensuite plus de 75 000 invocations réussies en deux jours, utilisées pour alimenter un service de conversations de jeu de rôle, notamment avec des contenus sexuels et violents. Ces mesures proviennent du honeypot, pas d’une facture client. Elles démontrent néanmoins un usage effectif de la capacité détournée, au-delà de la simple découverte du service.[17]
Les observations de 2026 montrent aussi que cette vérification est intégrée à l’outillage de collecte de secrets. Datadog décrit des séquences de validation d’identité, d’énumération des modèles puis de tests d’inférence, ainsi que des scripts dédiés à déterminer la valeur d’une clé pour Bedrock. Ses chercheurs distinguent explicitement l’analyse d’outils des événements observés chez leurs clients : une interface affichant une capacité Bedrock ne prouve pas à elle seule que cette capacité a été exploitée.[19][20]
Les conséquences financières ne relèvent plus uniquement de projections. DoiT rapporte environ 1,4 million de dollars de frais non autorisés dans ses dossiers support de juin à octobre 2026, dont un cas de 522 000 dollars. Ce sont des montants déclarés par ce répondant, sans publication du nombre total de cas ni des ajustements de facturation finaux. Le 30 octobre 2026, Wiz décrit également deux cas aval de clés compromises, avec environ 800 000 appels Bedrock en trente heures pour le premier et 1,7 million en treize heures pour le second ; la source distingue les appels réussis des refus et du throttling. Dans les deux cas, une première validation des clés était intervenue dans les trente minutes suivant l’accès aux secrets chez le fournisseur compromis.[21][23]
Le rapport publié le 2 novembre 2026 par le Google Threat Intelligence Group et Mandiant confirme que cette tendance dépasse un fournisseur, une région ou un secteur. L’équipe décrit plusieurs interventions menées en 2026 en Amérique du Nord, en Amérique du Sud et en Asie-Pacifique, avec des frais frauduleux dépassant 100 000 dollars en une seule journée et un cumul atteignant un million de dollars avant la révocation des accès. Elle documente surtout une spécialisation du marché : des acteurs chargés de l’accès initial transmettent des clés déjà validées à des opérateurs de « LLM Mixers », des passerelles illicites qui agrègent les identifiants volés, mesurent la consommation et revendent l’accès aux modèles à des abonnés. Ces observations couvrent plusieurs plateformes cloud et plusieurs fournisseurs de modèles ; les montants et les indicateurs publiés ne sont pas ventilés par service et ne doivent donc pas être attribués en totalité à Bedrock.[24]
La conclusion est donc claire : l’abus d’inférence Bedrock est un risque opérationnel déjà réel, avec des usages réussis, de l’automatisation et une commercialisation documentée. Les sources ne permettent pas de mesurer sa prévalence mondiale. Elles montrent aussi que les protections peuvent fonctionner : dans le cas JINX-2401 détaillé par Wiz, les SCP ont bloqué les invocations malgré les privilèges administrateur de l’identité compromise et les tentatives répétées de l’attaquant.[15][18][23][24]
Réduire le risque par une LZA adaptée et une détection opérationnelle
Pour se protéger, il est recommandé de commencer par les identités et les autorisations effectives : remplacer autant que possible les clés permanentes par des identités fédérées ou des rôles à durée limitée, restreindre les modèles et profils d’inférence accessibles, et refuser Bedrock dans les comptes qui n’en ont pas besoin. Les identifiants temporaires restent eux aussi exploitables s’ils sont volés ; réduire leur durée de vie ne dispense pas de limiter leurs permissions et leurs contextes d’utilisation.[2][19]
Une Landing Zone AWS correctement gouvernée, notamment avec le Landing Zone Accelerator on AWS, fournit une base pour déployer ces contrôles de manière cohérente et centraliser les journaux. Sa valeur dépend toutefois de la configuration retenue. Il faut y intégrer des SCP adaptées à Bedrock, protéger les comptes de sécurité, maîtriser les exceptions et vérifier les chemins d’inférence interrégionale. Installer la LZA ne signifie ni que ces décisions sont prises, ni que les scénarios d’abus sont automatiquement bloqués.[9][10][23]
Un CNAPP doit compléter cette architecture en corrélant exposition des secrets, permissions effectives et comportements observés. Une fonction de posture seule ne suffit pas : vérifiez la présence d’une détection opérationnelle couvrant Bedrock, les créations d’identités, les modifications d’accords Marketplace et les changements de journalisation. La synthèse publiée par la Cloud Security Alliance insiste justement sur l’association de la posture, de la gestion des droits et de la détection à l’exécution, plutôt que sur un contrôle isolé.[11]
Cette surveillance doit couvrir les bons journaux. Les appels classiques InvokeModel et Converse sur bedrock-runtime sont enregistrés comme événements de gestion CloudTrail. Les prompts et réponses relèvent d’une journalisation distincte, désactivée par défaut, qui exige des choix de confidentialité et de conservation. D’autres chemins, dont les agents, les bases de connaissances et l’inférence sur bedrock-mantle, nécessitent des événements de données explicitement activés. Une collecte générique « CloudTrail activé » ne garantit donc pas la couverture de tous les usages.[6][7][8] Le volume attendu ne doit pas non plus servir de seul critère d’alerte : Mandiant décrit des balayages de validation volontairement discrets, limités à une requête d’un seul token, destinés à confirmer la viabilité d’une clé sans déclencher les détections fondées sur les anomalies de volume.[24]
Enfin, les alertes de coûts, y compris sur les produits Marketplace, doivent compléter les signaux d’activité sans servir de seule protection. Il est recommandé de tester, dans un environnement autorisé, qu’une identité compromise ne peut pas invoquer de modèles hors de son périmètre, que ses tentatives déclenchent une alerte et que le confinement révoque aussi les accès persistants. C’est cette vérification de bout en bout, associant la LZA et les capacités réelles du CNAPP et du SOC, qui réduit le délai entre le premier test Bedrock et l’arrêt de l’abus.[18][21]
Sources
- [1] AWS — Overview
- [2] AWS — Simplified model access
- [3] AWS — Model access
- [4] AWS — Agents permissions
- [5] AWS — Enforce guardrails
- [6] AWS — CloudTrail bedrock-runtime
- [7] AWS — Model invocation logging
- [8] AWS — CloudTrail bedrock-mantle
- [9] AWS — Landing Zone Accelerator overview
- [10] AWS — LZA centralized logging
- [11] CSA / Tenable — Securing AI workloads in AWS
- [12] AWS — Responsible AI Policy
- [13] Sysdig — llmjacking-stolen-cloud-credentials-used-in-new-ai-attack
- [14] Sysdig — growing-dangers-of-llmjacking
- [15] Sysdig — llmjacking-targets-deepseek
- [17] Permiso — exploiting-hosted-models
- [18] Wiz — jinx-2401-llm-hijacking-aws
- [19] Datadog — attacker-infrastructure-but-vibe-coded
- [20] Datadog — beyond-valid-credentials-how-exposed-aws-keys-are-tested-for-amazon-bedrock-access
- [21] DoiT — llmjacking-when-attackers-run-claude-on-your-aws-bill
- [23] Wiz — black-october-for-ai-developer-platforms
- [24] GTIG / Mandiant — The Rise of LLMJacking
- [26] OpenAI — Introducing gpt-oss
- [27] AWS — Z.AI models in Bedrock
- [28] AWS — GLM 5.3 availability
- [29] AWS — GLM 5.3 and authorized penetration testing
