Avant-propos

Cet article présente une preuve de concept (PoC) démontrant comment un adversaire peut exploiter une injection de commande indirecte pour empoisonner silencieusement la mémoire à long terme d’un agent IA. L’expérience a été menée à l’aide d’Amazon Bedrock Agent. Dans ce scénario, lorsque la mémoire de l’agent est activée, un attaquant peut insérer des instructions malveillantes dans cette mémoire via une attaque par injection de prompt. Cela peut se produire lorsqu’un utilisateur victime est amené, par ingénierie sociale, à accéder à une page web ou à un document malveillant.

Dans notre preuve de concept, le contenu de la page web détourne le processus de résumé de session de l’agent, entraînant l’enregistrement des instructions injectées dans sa mémoire. Une fois implantées, ces instructions persistent d’une session à l’autre et sont intégrées aux prompts d’orchestration de l’agent. Ce mécanisme permet alors à l’agent d’exfiltrer discrètement l’historique de conversation de l’utilisateur lors d’interactions ultérieures.

Il convient de préciser qu’il ne s’agit pas d’une vulnérabilité de la plateforme Amazon Bedrock. Cette démonstration met plutôt en lumière un enjeu de sécurité plus vaste et encore non résolu des large language models (LLM) : les attaques par injection de prompt, notamment dans le contexte de l’utilisation d’agents.

Les LLM sont conçus pour suivre des instructions en langage naturel, mais ils ne sont pas capables de distinguer de manière fiable un contenu légitime d’un contenu malveillant. Ainsi, lorsqu’un contenu non vérifié (pages web, documents ou saisies d’utilisateurs) est incorporé dans les prompts système, le modèle devient vulnérable à des manipulations adverses. Les applications reposant sur des LLM, comme les agents (et donc leur mémoire), se trouvent dès lors exposées aux attaques par injection de prompt.

S’il n’existe pas encore de solution complète pour éliminer ce risque, certaines stratégies de réduction peuvent en atténuer considérablement l’impact. Les développeurs doivent considérer tout contenu non approuvé – provenant de sites web, de documents, d’API ou d’utilisateurs – comme potentiellement hostile.

Des solutions telles que Amazon Bedrock Guardrails et Prisma AIRS peuvent aider à détecter et bloquer en temps réel les attaques par injection de commande. Cependant, une protection réellement efficace des agents d’IA repose sur une stratégie de défense en profondeur, combinant plusieurs niveaux de sécurité, notamment :

  • le filtrage de contenu
  • le contrôle des accès
  • la journalisation
  • la surveillance continue

Nous avons partagé les résultats de cette recherche avec Amazon avant publication. Si les représentants du groupe ont salué cette étude, ils ont également souligné que, selon eux, ces risques peuvent être aisément atténués en activant certaines fonctionnalités intégrées à la plateforme Bedrock, spécifiquement conçues pour limiter ce type d’exposition. Ils ont notamment indiqué que l’application des Amazon Bedrock Guardrails, associée à la politique de protection contre les attaques par injection, offre une défense efficace.

Prisma AIRS a été conçu pour assurer une protection multicouche en temps réel des systèmes d’IA : détection et blocage des menaces, prévention des fuites de données et application de politiques d’utilisation sécurisées sur un large éventail d’applications d’IA.

Les solutions de filtrage d’URL, telles qu’Advanced URL Filtering, permettent de valider les liens à partir de flux de renseignements sur les menaces reconnus et de bloquer l’accès aux domaines malveillants ou suspects. Cette approche empêche les payloads contrôlés par des attaquants d’atteindre le LLM dès le départ.

AI Access Security a été conçu pour offrir une visibilité et un contrôle accrus sur l’utilisation des solutions de GenAI tierces. Cette solution contribue à prévenir les fuites de données, les usages non autorisés et les résultats potentiellement préjudiciables, grâce à l’application de politiques de sécurité et à la surveillance de l’activité des utilisateurs.

Cortex Cloud assure une analyse et une classification automatiques des actifs liés à l’IA, qu’il s’agisse de modèles commerciaux ou autogérés, afin de détecter les données sensibles et d’évaluer la posture de sécurité associée. Le contexte d’analyse est déterminé en fonction du type d’IA, de l’environnement cloud d’hébergement, du niveau de risque, de la posture de sécurité et des jeux de données utilisés.

Une évaluation de sécurité de l’IA Unit 42 peut vous aider à identifier de manière proactive les menaces les plus susceptibles de cibler votre environnement d’IA.

Vous pensez que votre entreprise a été compromise ? Vous devez faire face à une urgence ? Contactez l’équipe de réponse à incident d’Unit 42.

Unit 42 – Thématiques connexes Indirect Prompt Injection, GenAI, Memory Corruption

Mémoire des agents Bedrock

Les applications d’IA générative (GenAI) s’appuient de plus en plus sur des fonctionnalités de mémoire pour offrir des expériences plus personnalisées et cohérentes. Contrairement aux anciens LLM, qui sont sans état et traitent chaque session de manière isolée, le stockage d’informations en mémoire permet aux agents de conserver le contexte entre les sessions.

La fonction Amazon Bedrock Agents Memory permet ainsi aux agents d’IA de mémoriser les informations issues des interactions avec les utilisateurs. Lorsqu’elle est activée, l’agent enregistre les conversations et actions résumées sous un identifiant mémoire unique, généralement associé à un utilisateur donné. Cette approche permet à l’agent de retrouver le contexte précédent, les préférences et la progression des tâches, évitant ainsi à l’utilisateur de répéter les mêmes informations lors des sessions suivantes.

En interne, les agents Bedrock utilisent un processus de résumé de session piloté par des LLM. À la fin de chaque session – qu’elle se termine explicitement ou par expiration automatique – l’agent fait appel à un LLM à l’aide d’un modèle de prompt configurable. Ce prompt indique au modèle d’extraire et de résumer les informations essentielles, telles que les objectifs de l’utilisateur, ses préférences exprimées et les actions menées par l’agent. Le résumé obtenu condense ainsi le contexte central de l’interaction.

Lors des sessions suivantes, les agents Bedrock injectent ce résumé dans le modèle de prompt d’orchestration, de sorte qu’il fasse désormais partie des instructions système de l’agent. En pratique, la mémoire de l’agent influence la manière dont il raisonne, planifie et répond. Cela permet à son comportement d’évoluer au fil du temps, en fonction du contexte accumulé.

Les développeurs peuvent configurer la durée de conservation de la mémoire jusqu’à 365 jours, et personnaliser le pipeline de résumé en modifiant le modèle de prompt. Ce niveau de contrôle granulaire leur permet de déterminer quelles informations sont extraites, comment elles sont structurées et ce qui est effectivement conservé. Ces fonctionnalités offrent ainsi aux développeurs un moyen d’ajouter de nouvelles capacités à leurs applications à base d’agents, tout en renforçant leur défense en profondeur.

Injection de commande indirecte

L’injection de commande, ou prompt injection en anglais constitue un risque de sécurité pour les LLM : un utilisateur peut concevoir une entrée contenant des instructions trompeuses visant à manipuler le comportement du modèle, ce qui peut conduire à des accès non autorisés à des données ou à des actions involontaires.

L’injection de commande indirecte est une variante où des instructions malveillantes sont intégrées dans du contenu externe (e-mails, pages web, documents ou métadonnées) que le modèle finit par ingérer et traiter. Contrairement à l’injection directe, cette méthode exploite l’intégration du modèle avec des sources de données externes, amenant le modèle à interpréter des instructions embarquées comme des entrées légitimes, sans interaction directe de l’utilisateur.

Preuve de concept : manipulation de la mémoire via une injection de commande indirecte

Pour démontrer une attaque visant la mémoire d’un agent, nous avons construit un simple chatbot assistant de voyage en utilisant Amazon Bedrock Agents. Le bot peut réserver, récupérer et annuler des voyages, et dispose d’une fonction de lecture de pages web externes. Nous avons activé la fonction mémoire, en allouant à chaque utilisateur un périmètre de mémoire isolé afin que toute compromission n’affecte que l’utilisateur ciblé.

L’agent a été développé à partir des modèles de prompt d’orchestration et de résumé de session gérés par AWS, sans personnalisation (voir Ressources supplémentaires). Le modèle de base employé par notre agent était Amazon Nova Premier v1. Nous n’avons pas activé les Bedrock Guardrails, ce qui reflète une configuration minimalement protégée pour cette PoC.

Scénario d’attaque

Dans notre scénario fictionnel, la victime est un utilisateur légitime du chatbot, tandis que l’attaquant opère depuis l’extérieur et n’a aucun accès direct au système. Par ingénierie sociale, l’attaquant persuade la victime de soumettre au chatbot une URL malveillante. Lorsque le chatbot récupère cette URL, il charge une page web contenant des charges utiles d’injection de prompt intégrées.

Ces payloads manipulent le prompt de résumé de session, poussant le LLM à inclure des instructions malveillantes dans son résumé.

Cette PoC suit les étapes suivantes :

  1. Un attaquant crée une page web contenant des charges utiles d’injection de prompt.
  2. L’attaquant envoie l’URL malveillante à la victime.
  3. La victime communique l’URL au chatbot.
  4. Le chatbot récupère le contenu de la page web malveillante.
  5. Le payload du prompt injection manipule le processus de résumé de session et insère des instructions malveillantes dans la mémoire de l’agent.
  6. Lors des sessions ultérieures, les agents Bedrock intègrent ces instructions dans leurs prompts d’orchestration.
  7. Agissant en conformité avec les instructions injectées, le chatbot exfiltre discrètement l’historique de conversation de l’utilisateur vers un serveur de commandement et contrôle (CnC) distant en utilisant l’outil d’accès web.

La figure 1 illustre le déroulé de cette attaque.

Schéma illustrant un scénario de menace cybernéthique impliquant plusieurs composants : un pirate, un serveur de commande et contrôle (CnC), une personne à un poste de travail, un chatbot et une unité de stockage de la mémoire. Les connexions entre ces éléments montrent le flux depuis l’attaquant, l’insertion par l’attaquant de l’URL malveillante dans le chatbot, l’utilisation du chatbot par la personne, et le stockage de l’URL malveillante dans la mémoire du chatbot au fil des sessions.
Figure 1. Flux de l’attaque pour la PoC de manipulation de la mémoire.

Construction du payload d'injection de prompt

Cette section décrit comment nous avons construit des instructions malveillantes sur la page web pour réaliser une attaque par prompt ciblant le prompt de résumé de session.

La technique employée dans cette PoC vise spécifiquement le prompt de résumé de session dans le but d’insérer des instructions malveillantes dans la mémoire persistante de l’agent. Comprendre la structure de ce prompt est essentiel pour appréhender le vecteur d’attaque.

Par défaut, le prompt de résumé extrait deux éléments principaux :

  • Objectifs de l’utilisateur – les objectifs explicites exprimés par l’utilisateur au cours de la session.
  • Actions de l’assistant – les actions menées par l’agent pour atteindre ces objectifs.

Nous avons alimenté un modèle de prompt de résumé avec une session de conversation contenant ces objectifs utilisateur et ces actions de l’assistant. La conversation, comprenant les entrées utilisateur, les réponses de l’assistant et les appels d’outil, est encapsulée entre des balises XML <conversation> (surlignées en bleu). Un déroulé typique pour cette technique comprend :

  1. (Utilisateur) L’utilisateur demande au chatbot de lire une URL
  2. (Action) L’agent sélectionne et invoque un outil pour récupérer le contenu web
  3. (Résultat) L’outil renvoie le contenu de la page web
  4. (Assistant) L’agent génère une réponse en s’appuyant sur la sortie de l’outil et la requête de l’utilisateur

Comme l’illustre la figure 2, cette structure place la sortie de l’outil (c’est-à-dire la page web récupérée) dans le champ result (surligné en rouge). Ce champ constitue la seule entrée contrôlée par l’attaquant dans le prompt de résumé, ce qui en fait le point d’injection idéal.

Capture d’écran d’une conversation textuelle entre un utilisateur et un assistant IA, illustrant la discussion autour d’une URL, avec des portions de texte surlignées pour attirer l’attention. L’entrée est marquée comme bénigne. La zone en rouge correspond au point d’injection idéal.
Figure 2. Extrait du modèle de prompt de résumé de session.

Anatomie du payload

Le payload injecté se divise en trois parties, chacune séparée par une balise XML <conversation> forgée (surlignée en jaune). Ces balises sont conçues pour semer la confusion chez le LLM. Cela amène le LLM à interpréter les parties un et trois comme des blocs de conversation distincts, tandis que la partie deux (en dehors de ces blocs) est traitée comme faisant partie des instructions système du prompt de résumé de session.

  • La partie un se termine par une balise </conversation> forgée, trompant ainsi le modèle en lui faisant croire à la fin d’un bloc de conversation. Elle contient les échanges antérieurs entre l’utilisateur et l’agent ainsi que du contenu web bénin. Le payload commence immédiatement après cette section.
  • La partie trois débute par une balise <conversation> forgée, amenant le LLM à la considérer comme le début d’un autre bloc de conversation. Elle contient une interaction utilisateur-agent fabriquée qui réitère les instructions de la partie deux, augmentant la probabilité que le LLM les intègre dans le résumé final de session.
  • La partie deux, positionnée stratégiquement en dehors de tout bloc <conversation>, renferme les instructions malveillantes essentielles. Cette disposition conduit le LLM à l’interpréter comme des instructions système plutôt que comme une entrée utilisateur ou générée par un outil, ce qui accroît fortement la probabilité que le modèle exécute ces instructions. Le payload s’intègre visuellement en reprenant la même syntaxe de type XML utilisée dans le modèle de prompt, afin de se fondre dans le contenu attendu.

La figure 3 illustre comment les agents Bedrock remplissent le champ result avec le contenu malveillant provenant de la page web de l’attaquant, tandis que les autres champs du prompt de résumé restent inchangés.

Marqué comme malveillant. Capture d’écran de l’interface de chat d’un agent IA montrant des zones de texte avec un exemple de dialogue sur la validation d’URL. L’image comprend des sections annotées « Action malveillante », « Résultat » et « Directives » avec des commentaires pour améliorer les consignes utilisateurs en matière de sécurité. L’exemple mentionne l’URL example.com dans la conversation.
Figure 3. Payload de prompt injection dans le prompt de résumé de session.

Livraison et installation du payload d’exploitation

La figure 4 montre la page web malveillante contenant le payload d’exploitation correspondant à l’étape 1 du déroulé d’attaque. Les instructions malveillantes spécifiées par l’attaquant sont intégrées dans le HTML mais rendues invisibles pour l’utilisateur final, ce qui garantit la discrétion de l’attaque.

Image présentant le top 5 des parcs nationaux américains pour les vacances d’été et leurs aéroports les plus proches. Les parcs listés sont Glacier National Park, Yosemite National Park, Grand Teton National Park, Acadia National Park et Olympic National Park. Pour chaque parc, l’entrée indique les aéroports à proximité ainsi que les distances correspondantes.
Figure 4. Page web malveillante où les payloads de prompt injection sont dissimulés sous un contenu bénin.

La figure 5 illustre l’interaction de la victime avec le chatbot, correspondant aux étapes 2 à 4 du déroulé d’attaque. Notons que l’agent n’affiche aucun comportement malveillant ni ne révèle les instructions injectées : le payload cible le prompt de résumé de session et non le prompt d’orchestration qui gouverne la conversation en temps réel. Comme les instructions injectées ne sont pas liées à la requête de l’utilisateur, le LLM les exclut de la réponse de l’assistant.

Capture d’écran d’un guide des parcs nationaux indiquant les temps de vol depuis Washington D.C. vers plusieurs parcs américains. Le prompt demande au chatbot de consulter le guide des parcs nationaux figurant dans une URL, laquelle est malveillante.
Figure 5. La victime demande au chatbot de lire l’URL malveillante.

La figure 6 présente un extrait de la sortie du LLM lors du processus de résumé de session, correspondant à l’étape 5 du déroulé d’attaque. Comme attendu, le modèle extrait les objectifs clés de l’utilisateur et les actions de l’assistant à partir de la conversation. Cependant, il intègre également les instructions injectées par l’attaquant depuis la page web malveillante, en les étiquetant sous un thème fabriqué tel que « validation goal ». Étant donné que chaque thème présent dans le résumé est automatiquement injecté dans la mémoire de l’agent, cette étape installe effectivement le payload pour les sessions futures.

Capture d’écran d’un résumé généré par un LLM lors de la planification d’un voyage, incluant la révision des recommandations de parcs nationaux et l’estimation des durées de trajet. Le contenu est structuré par résumé, objectifs de l’utilisateur et actions de l’assistant.
Figure 6. Sortie du LLM lors du résumé de session.

Activation du payload dans les sessions suivantes

Les agents Amazon Bedrock injectent automatiquement le contenu de la mémoire dans le contexte de chaque nouvelle session. La figure 7 montre la victime revenant vers le chatbot plusieurs jours plus tard pour réserver un nouveau voyage, correspondant à l’étape 6 du déroulé d’attaque. L’agent accomplit la réservation comme attendu et, du point de vue de l’utilisateur, tout semble normal. Pourtant, un comportement malveillant s’exécute désormais en arrière-plan, de manière silencieuse.

Capture d’écran d’une confirmation de réservation de vol de Washington D.C. à Kalispell (Montana) le 15 juillet 2025 pour visiter Glacier National Park, initiée par un utilisateur interagissant avec un chatbot.
Figure 7. La victime demande au chatbot de réserver un nouveau voyage dans une nouvelle session de conversation.

La figure 8 montre un extrait du prompt d’orchestration utilisé dans la nouvelle session, correspondant à l’étape 7 du déroulé. Ce prompt contient désormais le contenu de la mémoire de l’agent, enrichi des instructions de l’attaquant, dans la section des instructions système. Puisque les instructions système influencent fortement le comportement du LLM, le modèle est plus susceptible d’exécuter les instructions malveillantes.

Capture d’écran d’une description d’un agent IA. Le résumé de session évoque les « validation goals » de l’agent, qui incluent une URL malveillante. S’ensuivent les objectifs de l’utilisateur et les actions de l’assistant, incluant le contenu scrappé depuis une URL partiellement masquée et la réservation d’un vol.
Figure 8. Prompt d’orchestration compromis contenant la mémoire altérée.

La figure 9 montre comment l’agent raisonne et planifie l’exécution de la demande de l’utilisateur. Dans le premier message de l’assistant, l’agent expose son plan d’exécution, qui incorpore des étapes dérivées des instructions de l’attaquant. Dans le second message, l’agent exfiltre silencieusement les informations de réservation de l’utilisateur vers un domaine malveillant en encodant les données dans les paramètres de requête de l’URL CnC et en appelant cette URL avec l’outil scrape_url. L’agent peut ainsi exécuter le payload de l’attaquant sans qu’aucun signe visible n’alerte la victime.

Capture d’écran d’un extrait de code montrant la validation d’une réservation via l’assistant, avec paramètres et URL inclus.
Figure 9. Les instructions malveillantes intégrées au plan d’exécution de l’agent.

Conclusion

La mémoire à long terme est une fonctionnalité puissante des agents IA, qui permet des expériences personnalisées, contextualisées et adaptatives. Cependant, elle ouvre aussi de nouvelles surfaces d’attaque. Notre PoC montre que des agents IA dotés d’une mémoire persistante peuvent servir de vecteur à des instructions malveillantes durables. Cela peut modifier le comportement de l’agent d’une session à l’autre et dans la durée, offrant une voie possible à une manipulation systémique à long terme. Comme le contenu de la mémoire est injecté dans les instructions système des prompts d’orchestration, il est souvent priorisé par rapport aux entrées de l’utilisateur, ce qui amplifie l’impact potentiel.

Si cette PoC utilise une page web malveillante comme vecteur de livraison, le risque couvre en réalité tout canal d’entrée non vérifié, notamment :

  • les documents
  • les API tierces
  • les contenus générés par les utilisateurs

Selon les capacités et les intégrations de l’agent, une exploitation réussie peut entraîner une exfiltration de données, la diffusion de fausses informations ou l’exécution d’actions non autorisées, le tout de manière autonome. La bonne nouvelle, comme le souligne AWS, est que l’attaque spécifique présentée ici peut être atténuée en activant les protections natives de Bedrock Agent, notamment le prompt de prétraitement par défaut et le Bedrock Guardrail, destinés à contrer les attaques par injection de prompt.

La prévention des attaques de manipulation de mémoire repose sur une approche multicouches de la sécurité. Les développeurs doivent partir du principe que toute entrée externe peut être hostile et mettre en œuvre des mécanismes de protection adaptés. Cela inclut le filtrage des contenus non vérifiés, la restriction de l’accès des agents à des sources externes et la surveillance continue du comportement des agents afin de détecter et de corriger toute anomalie.

À mesure que les agents d’IA gagnent en autonomie et en complexité, la sécurisation de la mémoire et de la gestion du contexte devient essentielle pour garantir des déploiements sûrs et dignes de confiance.

Protection et atténuation

La cause première de cette attaque de manipulation de mémoire réside dans l’ingestion par l’agent de contenus non vérifiés et contrôlés par un attaquant, en particulier ceux provenant de sources de données externes telles que des pages web ou des documents. L’attaque peut être interrompue à tout moment dans la chaîne si une URL malveillante, un contenu web compromis ou un prompt de résumé de session est nettoyé, filtré ou bloqué. Une atténuation efficace repose sur une stratégie de défense intégrée, appliquée à plusieurs niveaux du pipeline d’entrée et de mémoire de l’agent.

Prétraitement

Les développeurs peuvent activer le prompt de prétraitement par défaut fourni pour chaque agent Bedrock. Cette mesure légère de protection utilise un modèle de base pour évaluer si les entrées utilisateur sont sûres avant d’être traitées. Elle peut fonctionner selon son comportement par défaut ou être personnalisée pour inclure des catégories de classification supplémentaires. Les développeurs peuvent également intégrer AWS Lambda afin de mettre en œuvre des règles spécifiques via un analyseur de réponse personnalisé. Cette flexibilité permet d’adapter les mécanismes de défense à la posture de sécurité propre à chaque application.

Filtrage de contenu

Tous les contenus non vérifiés, en particulier ceux provenant de sources externes, doivent être inspectés afin de détecter d’éventuelles injections de prompt. Des solutions telles qu’Amazon Bedrock Guardrails et Prisma AIRS sont conçues pour détecter et bloquer efficacement les attaques par prompt visant à manipuler le comportement des LLM. Ces outils permettent d’appliquer des politiques de validation des entrées, de supprimer les contenus suspects ou interdits, ou encore de rejeter les données malformées avant qu’elles ne soient transmises aux LLM.

Filtrage d’URL

Il est recommandé de restreindre la liste des domaines accessibles par les outils de lecture web de l’agent. Les solutions de filtrage d’URL, telles qu’Advanced URL Filtering, permettent de valider les liens à partir de flux de renseignements sur les menaces reconnus et de bloquer l’accès aux domaines malveillants ou suspects. Cette approche empêche les payloads contrôlés par des attaquants d’atteindre le LLM dès le départ. La mise en œuvre de listes blanches (ou de politiques « deny by default ») est particulièrement importante pour les outils faisant le lien entre les contenus externes et les systèmes de mémoire internes.

Journalisation et surveillance

Les agents d’IA peuvent exécuter des actions complexes de manière autonome, sans supervision directe des développeurs. Pour cette raison, une observabilité complète est essentielle.

Amazon Bedrock propose les Model Invocation Logs, qui enregistrent chaque paire de prompt et de réponse. De plus, la fonctionnalité Trace offre une visibilité détaillée sur les étapes de raisonnement de l’agent, l’utilisation des outils et les interactions avec la mémoire. Ensemble, ces outils facilitent l’analyse forensique, la détection d’anomalies et la réponse à incident.

Prisma AIRS est conçu pour assurer une protection en temps réel des applications, modèles, données et agents d’IA. La solution analyse le trafic réseau et le comportement applicatif afin de détecter des menaces telles que l’injection de prompt, les attaques de denial-of-Service et l’exfiltration de données, tout en appliquant des mesures de protection en ligne, au niveau du réseau et des API.

AI Access Security a été conçu pour offrir une visibilité et un contrôle accrus sur l’utilisation des solutions de GenAI tierces. Cette solution contribue à prévenir les fuites de données, les usages non autorisés et les résultats potentiellement préjudiciables, grâce à l’application de politiques de sécurité et à la surveillance de l’activité des utilisateurs. Ensemble, Prisma AIRS et AI Access Security permettent de sécuriser le développement d’applications d’entreprise reposant sur l’IA ainsi que leurs interactions avec des systèmes externes.

Cortex Cloud assure une analyse et une classification automatiques des actifs liés à l’IA, qu’il s’agisse de modèles commerciaux ou autogérés, afin de détecter les données sensibles et d’évaluer la posture de sécurité associée. Le contexte d’analyse est déterminé en fonction du type d’IA, de l’environnement cloud d’hébergement, du niveau de risque, de la posture de sécurité et des jeux de données utilisés.

Une évaluation de sécurité de l’IA Unit 42 peut vous aider à identifier de manière proactive les menaces les plus susceptibles de cibler votre environnement d’IA.

Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse à incident ou composez l’un des numéros suivants :

  • Amérique du Nord : Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
  • Royaume-Uni : +44 20 3743 3660
  • Europe et Moyen-Orient : +31.20.299.3130
  • Asie : +65.6983.8730
  • Japon : +81 50 1790 0200
  • Australie : +61.2.4062.7950
  • Inde : 00080005045107

Palo Alto Networks a partagé ces conclusions avec les autres membres de la Cyber Threat Alliance (CTA). Les membres de la CTA s’appuient sur ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et perturber de manière coordonnée les activités des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.

Pour aller plus loin

Modèle de prompt de résumé de session des agents Bedrock

Modèle de prompt d’orchestration des agents Bedrock

Références

Enlarged Image