Les équipes de sécurité devraient examiner une séquence inhabituelle d’utilisation d’outils avant de conclure qu’un agent IA en est la cause. Le rapport publié par Wiz le 29 octobre fournit des indices comportementaux utiles pour cette enquête, mais le contrôle réellement exploitable reste un récit corrélé des actions, des identités et des résultats. Une suite de commandes rapide ou un script très bavard, à eux seuls, ne permettent pas d’établir l’identité de l’opérateur ni le degré d’automatisation.
Dans The Rise of Agentic Attacks, Wiz décrit trois intrusions qu’il a étudiées et propose sept empreintes récurrentes d’activité agentique. Son analyse pose une question pratique aux défenseurs : la télémétrie existante permet-elle de distinguer un travail d’automatisation autorisé d’une séquence d’attaque évolutive utilisant les mêmes outils ?
Traitez le rapport comme une source d’enquête
Wiz décrit des cas impliquant un service Flowise exposé, une passerelle d’exploitation Java et un backend d’agent IA accessible via une interface MCP. Parmi les indices proposés figurent une itération soutenue, un raisonnement rédigé à l’intérieur des outils, une adaptation après des échecs et une exploration large des chemins possibles.
Il s’agit des constats et des interprétations de Wiz. Le rapport indique que la solidité des preuves et le degré d’autonomie varient selon les cas. Sa discussion sur l’ampleur future des attaques et sur l’attribution relève d’une évaluation, non d’un taux d’incident mesuré à l’échelle du secteur. La couverture secondaire confirme la publication du rapport et son périmètre ; elle ne valide pas indépendamment la télémétrie sous-jacente des incidents.
La recommandation de Maetra est d’utiliser ces indices comme des hypothèses d’enquête et de les confronter aux propres enregistrements de l’environnement. Répondez aux comportements nuisibles démontrés même si l’étiquette IA reste incertaine.
Reconstituez la séquence qui a changé de direction
Commencez par l’action pertinente la plus ancienne que vos enregistrements permettent d’établir. Reliez l’identité initiatrice, le processus, la requête d’outil, la cible et le résultat. Recherchez ensuite un changement significatif après une erreur ou un refus. L’étape suivante suivait-elle un repli approuvé, ou cherchait-elle une autre ressource ou un autre identifiant ?
Supposons qu’une tâche autorisée d’inventaire reçoive une erreur d’autorisation lors de l’énumération d’un service. Une tentative ultérieure de lire des identifiants ou d’inspecter des systèmes sans rapport justifierait un examen, en raison des limites de la tâche, qu’un modèle l’ait choisie ou non. Il s’agit d’un exemple hypothétique de détection, et non d’une affirmation concernant l’une des victimes de Wiz.
Conservez une part suffisante du résultat renvoyé pour expliquer l’action suivante. Une chronologie ne contenant que les requêtes peut faire passer de simples tentatives répétées pour un comportement adaptatif, tandis qu’une chronologie ne contenant que des alertes peut masquer le lien entre un échec initial et une escalade ultérieure. Utilisez des références de corrélation lorsqu’elles existent et consignez les lacunes lorsque les systèmes ne peuvent pas les fournir.
Comparez l’activité suspecte à l’automatisation autorisée
La vitesse d’exécution machine est courante dans les logiciels légitimes. Bâtissez la comparaison autour de ce que la charge de travail était autorisée à faire : sa définition de tâche, son propriétaire, sa fenêtre d’exécution, le périmètre des ressources et les destinations attendues. Demandez-vous si une action donnée correspond à ce contexte avant de traiter le volume comme le signal décisif.
Pour un agent interne de maintenance, la référence pertinente peut inclure un petit ensemble approuvé de points de terminaison et un chemin de reprise prévisible. Pour un scanner, une énumération plus large peut être attendue. Une règle de détection doit expliquer pourquoi la combinaison observée est inhabituelle pour cette identité et cette tâche, plutôt que de supposer qu’un balayage large est forcément malveillant ou piloté par une IA.
Des plans rédigés à l’intérieur des scripts peuvent aider l’enquêteur à comprendre l’intention, mais leur présence constitue un élément de preuve à interpréter. Les commentaires peuvent être copiés, trompeurs ou sans rapport avec l’exécution. Conservez l’artefact d’origine, sa provenance et les événements montrant ce qui a réellement été exécuté. Distinguez les affirmations de l’artefact de la conclusion de l’enquêteur.
Choisissez la réponse en fonction du risque observé
Définissez quelles preuves suffisent pour restreindre un identifiant, isoler une charge de travail ou transmettre à la réponse à incident dans le cadre du processus existant de l’organisation. Une décision de réponse peut reposer sur un accès non autorisé à des secrets ou sur des écritures inattendues, sans exiger de certitude quant au modèle ou au cadre agentique en cause.
Évitez de transformer une hypothèse d’attribution en blocage automatique généralisé. Corrélez d’abord la ressource, l’identité et l’action, puis appliquez l’autorité de réponse adaptée au risque démontré. Si une réponse automatisée est autorisée, l’équipe doit tout de même connaître sa cible, son périmètre et son effet attendu. Le rapport de Wiz ne valide pas la configuration de réponse d’une organisation particulière.
Le guide sur les preuves d’audit fournit des éléments de contexte sur la conservation des enregistrements de décision et d’exécution. Limitez la collecte de charges utiles sensibles à ce que l’enquête exige, avec des contrôles appropriés d’accès et de conservation. Un magasin de preuves de sécurité ne doit pas devenir une nouvelle copie incontrôlée d’identifiants ou de données privées.
Testez une requête d’outil suspecte dans son contexte
Prenez un exemple assaini issu d’un exercice autorisé et notez la tâche, l’action d’outil proposée et la destination attendue. Examinez le comportement dangereux séparément de la question de savoir qui l’a généré. L’exercice reste ainsi utile même si la même action aurait pu être écrite par une personne ou par un script conventionnel.
Maetra Secure analyse les prompts, les appels d’outils et les sorties à la recherche de menaces à l’exécution. Il n’identifie pas un attaquant et ne remplace pas la télémétrie cloud. Utilisez le bac à sable Secure pour examiner une requête d’outil délimitée, puis reliez le constat au processus de preuve et de réponse que votre équipe de sécurité applique déjà.
Sources
- Wiz: The Rise of Agentic Attacks, 29 octobre 2026. Rapport d’enquête principal et critères comportementaux proposés.
- The Injection: report summary, 29 octobre 2026. Couverture secondaire du rapport, sans vérification indépendante des incidents.