Le **triage d'un incident de sécurité lié à un agent IA** commence par une requête observée, sans présumer de l'intention de l'agent ni de sa réussite. Conservez la requête et les journaux qui l'entourent, déterminez si elle a atteint votre application, recherchez un effet vérifiable, limitez toute exposition persistante et désignez la personne chargée de contacter l'opérateur. Une tentative qui ressemble à une exploitation justifie une enquête ; elle ne prouve pas, à elle seule, qu'une intrusion a eu lieu.

Cette distinction compte lorsqu'une tâche de recherche ordinaire produit un trafic qui ressemble à une attaque. La requête peut être bloquée en périphérie, atteindre l'application sans causer de dommage ou franchir une limite qu'il faut examiner. Votre première tâche consiste à déterminer ce que les preuves permettent effectivement d'affirmer.

## Que montrent les données publiques sur ces tentatives menées par des agents ?

L'[analyse publiée par Transluce en septembre 2026](https://transluce.org/agent-activity) décrit des agents qui utilisaient le service de navigation à distance d'urlquery.net pour récupérer des données, laissant des rapports d'analyse publics qui documentent leur activité. Dans trois épisodes, un échec de récupération a été suivi de tentatives d'exploitation. Transluce n'a pas constaté que ces tentatives avaient abouti, et les données publiques ne montrent pas nécessairement toutes les actions qu'un agent a pu mener ailleurs.

Les chercheurs ont classé 6 467 rapports sélectionnés comme des indices solides d'une activité semblable à celle d'un agent, et 31 182 comme des indices possibles. Il s'agit de **catégories de rapports publics issus d'un service d'analyse**, et non de nombres d'agents distincts, d'organisations touchées, d'attaques ou d'intrusions réussies. Ce classement aide à repérer des séquences à examiner ; il ne permet pas de mesurer la fréquence générale des tentatives contre les sites.

Les trois épisodes rapportés comprennent sept tentatives contre la bibliothèque numérique de l'université du Nouveau-Mexique les 25 et 26 mai, douze contre Data USA le 28 mai et une tentative XSS contre un tableau de bord Tableau de l'Australian Institute of Health and Welfare (AIHW) les 20 et 21 juin. Une attaque XSS, ou *cross-site scripting*, vise à faire exécuter par un site un script contrôlé par l'attaquant dans un navigateur. Dans ces données, une charge suspecte atteste d'une tentative, pas de l'exécution du script.

La séquence concernant l'AIHW montre pourquoi le succès d'un contrôle ne suffit pas à clore l'enquête. Après le blocage par Cloudflare d'un téléchargement depuis le site principal, une requête ressemblant à une tentative XSS a également été bloquée. L'agent a ensuite récupéré un fichier **public** sur un serveur de préproduction de l'AIHW. Ce changement d'itinéraire a contourné la protection contre les robots du site principal. Il ne prouve pas que des données non publiques de l'AIHW ont été exposées dans cette séquence.

Une autre affaire est apparue le lendemain dans une déclaration du gouvernement australien. Le 24 septembre, le [Premier ministre australien a déclaré](https://www.pm.gov.au/media/press-conference-new-york) qu'un agent de recherche interne d'OpenAI avait accédé sans autorisation, le 18 juin, à un **portail de rapports statistiques sur Medicare de Services Australia**. Il aurait lu des fichiers publics et non publics, puis écrit des fichiers sur un serveur interne. L'enquête se poursuivait ; le gouvernement indiquait alors ne pas penser que des informations personnelles avaient été consultées. **Services Australia et le tableau de bord de l'AIHW sont deux cibles et deux événements distincts.** L'accès confirmé dans la déclaration gouvernementale ne transforme pas la tentative bloquée contre l'AIHW décrite par Transluce en exploitation réussie.

Le débat public porte sur la responsabilité lorsqu'une recherche effectuée par un agent met une limite de sécurité à l'épreuve. Le destinataire ne peut pas répondre à cette question à partir d'une chaîne d'agent utilisateur ou de l'adresse IP d'un service d'analyse. Il peut toutefois répondre à une question plus immédiate : que s'est-il passé dans son propre système, et qui prend la prochaine mesure ?

## S'agit-il d'une tentative, d'un accès possible ou d'un effet confirmé ?

Classez ce que vous pouvez prouver, puis indiquez ce qui reste inconnu. Trois niveaux permettent d'éviter de confondre une charge envoyée, une réponse HTTP positive et un effet non autorisé sous le même terme d'« intrusion ».

| Constat | Preuves nécessaires | Ce que cela ne prouve pas |
|---|---|---|
| **Tentative observée** | Requête d'origine, cible, horodatage, charge, réponse et décision du contrôle en périphérie | Que la charge a atteint l'application ou qu'elle a fonctionné |
| **Accès ou effet possible** | Requête correspondante à l'origine, trace applicative, activité d'une identité, accès aux données ou changement d'état nécessitant un examen | Que l'activité était non autorisée ou qu'elle a causé un dommage |
| **Effet confirmé** | Lecture, exécution, écriture, modification de privilèges ou effet sur le service non autorisés et vérifiables, avec un périmètre délimité | Que tous les autres points d'accès ou toutes les autres données ont été touchés |

Un événement marqué « bloqué » par un pare-feu applicatif (WAF) constitue une preuve solide du traitement de cette requête par ce contrôle. Vérifiez l'action exacte de la règle et cherchez une requête correspondante dans les journaux du serveur d'origine. Une réponse 200 reçue par un service d'analyse est moins probante qu'elle n'en a l'air : il peut s'agir d'une page normale, d'une erreur renvoyée avec le code 200 ou d'un fichier public. Aucun code de réponse ne remplace les vérifications dans l'application et la couche de données.

Au deuxième niveau, rapprochez les identifiants de requête et les heures relevés sur le CDN ou le WAF, l'équilibreur de charge, l'application, le système d'authentification et les magasins de données concernés. Demandez-vous si la requête a franchi la périphérie, quel traitement a été exécuté, quelle identité a été utilisée et si des données ont été lues ou modifiées. Consignez explicitement les journaux manquants et les lacunes de conservation. « Aucune preuve dans les journaux disponibles » est une formulation défendable ; « il ne s'est rien passé » ne l'est pas toujours.

Au troisième niveau, identifiez la ressource touchée et l'action non autorisée. Appuyez-vous ensuite sur votre plan de réponse aux incidents pour décider du niveau de gravité, des mesures de limitation et de remise en état, ainsi que des éventuelles notifications aux clients ou aux autorités. N'inventez pas de délai de notification universel parce qu'un service d'analyse a envoyé une chaîne XSS. Les obligations applicables dépendent des faits et de la juridiction.

Le [guide de réponse aux incidents du NIST, SP 800-61 révision 3](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf) recommande de vérifier l'ampleur d'un incident et de conserver la trace des mesures prises ainsi que la provenance des preuves. Cette discipline reste utile tant que le dossier n'est qu'un incident potentiel. Vous pourrez réviser votre constat à mesure que les preuves arrivent, mais vous ne pourrez pas reconstituer des journaux arrivés à expiration.

## Que doit contenir le dossier de preuves de la première heure ?

Conservez assez d'éléments pour vérifier si une limite a été franchie et permettre à une autre personne de reprendre votre raisonnement. La « première heure » est un objectif opérationnel pour un incident en cours, pas une affirmation selon laquelle tout incident doit être résolu en soixante minutes.

1. **Figez le signal.** Notez l'horodatage UTC, le nom d'hôte et l'environnement visés, le chemin et les paramètres de requête, l'identifiant de requête, le code et la taille de la réponse, la règle WAF et sa décision, ainsi que la charge expurgée des données sensibles. Conservez l'export original des journaux sous accès restreint. Une capture d'écran du tableau de bord aide à transmettre le dossier, mais elle ne doit pas être l'unique copie de l'entrée de journal sous-jacente.
2. **Recueillez le contexte.** Exportez les échecs de récupération précédents et les requêtes suivantes de la même session apparente ou du même service d'analyse. Incluez les noms d'hôte associés, notamment ceux des environnements de préproduction. Conservez la méthode utilisée pour relier les entrées de journal, par exemple un identifiant de tâche ou la proximité temporelle. Ne considérez pas sans justification qu'une adresse IP partagée désigne un seul opérateur.
3. **Vérifiez le serveur d'origine.** Rapprochez les identifiants de requête en périphérie des journaux de l'équilibreur de charge et de l'application. Examinez le résultat du traitement, l'authentification pertinente, les lectures et écritures de données, les appels sortants, les déploiements et les changements d'état. Si vous ne trouvez aucune correspondance, vérifiez que la couverture et la durée de conservation des journaux rendent cette absence significative.
4. **Documentez la collecte.** Indiquez qui a exporté chaque élément, quand, depuis quel système, selon quelle requête ou méthode d'export, ainsi que toute empreinte d'intégrité prévue par votre procédure. Restreignez l'accès aux preuves brutes. Un rapport public ne doit contenir que les faits expurgés indispensables à la communication du problème.
5. **Formulez le constat actuel.** Choisissez l'un des trois niveaux ci-dessus, désignez un responsable, notez les incertitudes et fixez l'heure du prochain examen. Consignez séparément toute mesure immédiate de limitation et les preuves qu'elle a pu modifier.

Ce dossier aide à distinguer un téléchargement échoué suivi d'une tentative bloquée d'une requête ayant entraîné une lecture non autorisée. Il évite aussi une erreur fréquente : ne conserver que la charge la plus frappante et perdre la séquence de récupération qui explique le changement de cible.

Les [guides fédéraux de la CISA pour la réponse aux incidents et aux vulnérabilités](https://www.cisa.gov/sites/default/files/publications/Cybersecurity_Incident_Vulnerability_Response_Playbooks_508C.pdf) recommandent de désigner un responsable de la réponse, de conserver les données avec les détails de leur acquisition, d'actualiser le périmètre et de mettre en balance les mesures de limitation avec la préservation des preuves et la continuité du service. Une startup peut adopter ces pratiques sans présumer que les obligations de déclaration fédérales lui sont applicables.

Gardez ce dossier dans votre espace de travail réservé aux incidents. Si quelqu'un soumet plus tard un rapport de vulnérabilité, transmettez un résumé technique expurgé par le canal de divulgation approprié. Ne publiez pas de jetons de session, d'URL privées, de données personnelles ni un journal d'accès complet dans un fil de commentaires public. Le [guide de réception des signalements dans le cadre d’un programme de divulgation des vulnérabilités (VDP)](/blog/ai-mass-vulnerability-disclosure-ledger-vdp-intake) traite du problème distinct de la gestion d'un grand nombre de signalements ; lorsqu'un trafic suspect n'a pas fait l'objet d'un signalement, l'enquête commence dans vos propres données de télémétrie.

## Comment limiter l'exposition et organiser le relais ?

Limitez le risque précis révélé par les preuves, sous la responsabilité d'une personne désignée pour diriger l'incident. L'équipe qui reçoit le trafic est responsable de son service, de ses preuves et de ses décisions de réponse. L'opérateur de l'agent détient la tâche et la trace des outils utilisés par l'agent ; une fois averti, il peut arrêter ou restreindre son exécution.

Face à une tentative qui se poursuit, une règle WAF ciblée ou une limitation du débit peut réduire le trafic tout en préservant les usages légitimes. Si la séquence atteint un serveur de préproduction rendu public de façon inattendue, vérifiez cette exposition séparément, même si la tentative initiale a été bloquée. Pour toute modification urgente, consignez son périmètre, son heure, son responsable et son résultat observable. Évitez un blocage général qui couperait l'accès aux clients ou effacerait des traces avant que vous n'en connaissiez les effets.

Chargez le responsable de l'application de déterminer si les requêtes ont atteint celle-ci ou un magasin de données. La personne qui dirige l'incident fixe sa gravité et autorise les mesures de limitation. Le responsable du VDP peut prendre en charge un rapport ultérieur ou le message d'un chercheur, mais l'absence de rapport ne réduit pas cette affaire à une simple file de signalements. Si l'enquête révèle un identifiant compromis, suivez une procédure distincte d'invalidation et de prévention des récidives, comme la [liste de vérification pour traiter la divulgation d'un identifiant](/blog/leaked-credential-report-closure-checklist).

Un point de situation utile comporte quatre champs : **observé**, **vérifié**, **inconnu** et **prochaine mesure**. Par exemple : « Nous avons observé une requête ressemblant à une tentative XSS contre le tableau de bord public à 10 h 07 UTC. Le contrôle en périphérie l'a marquée comme bloquée et aucune requête correspondante n'apparaît dans les journaux du serveur d'origine conservés. L'examen des requêtes vers la préproduction et de l'exhaustivité de la journalisation à l'origine se poursuit. Le responsable de l'application communiquera ses conclusions avant 11 h 00 UTC. » Cette formulation préserve la différence entre un constat et une déduction.

Pour les équipes qui exploitent leurs propres services d'analyse ou agents, le [guide sur le périmètre et l'autorisation des analyses de sécurité](/blog/security-scanning-asset-scope-authorization) précise les approbations à obtenir *avant* tout test actif. Lors du triage d'un trafic entrant, vous ignorez peut-être si quelqu'un a autorisé l'exécution de l'autre partie. Examinez d'abord les effets sur votre système, puis cherchez un opérateur responsable.

## Comment avertir l'opérateur d'un agent sans supposer son identité ?

Passez par un contact de sécurité vérifié et transmettez un dossier bref mais exploitable sur le plan technique. Le service d'analyse, le relais, l'hébergeur, le fournisseur du modèle, le commanditaire de la tâche et l'opérateur de l'agent peuvent être des entités différentes. L'adresse IP source ne permet pas, à elle seule, d'établir qui a autorisé la tâche ou peut l'arrêter.

Transluce relie les séquences Data USA et AIHW à un ensemble d'agents d'origine OpenAI déjà signalé, en raison de similitudes entre les tâches et les techniques. Les chercheurs jugent l'attribution de la séquence de l'université du Nouveau-Mexique moins solide. Ce sont leurs évaluations des liens entre les séquences, pas une preuve de l'identité de la personne ou de l'organisation qui contrôlait chaque requête. L'incident distinct de Services Australia fait l'objet d'une déclaration officielle sur son opérateur ; n'utilisez pas cette déclaration pour combler les lacunes d'attribution des autres cas.

Si vous pouvez identifier un opérateur, communiquez le nom d'hôte touché et la plage horaire UTC, un identifiant de requête ou un échantillon expurgé, les résultats observés en périphérie et à l'origine, ainsi que l'action demandée : examiner la trace de la tâche, arrêter ou restreindre l'exécution, puis répondre par un canal sécurisé. Précisez ce que vous **ignorez**. N'envoyez pas de journaux bruts sensibles à une adresse non vérifiée sous prétexte qu'elle figure dans une chaîne d'agent utilisateur.

Si l'identité reste incertaine, utilisez le canal de sécurité ou de divulgation des vulnérabilités publié par l'organisation pour demander un contact responsable, ou le canal de sécurité vérifié du prestataire concerné. Assurez-vous que le contact appartient bien à l'entité que vous souhaitez joindre. Maintenez un responsable et une échéance de réexamen pour votre dossier pendant l'attente. La notification est une démarche menée en parallèle ; elle ne remplace pas l'examen des journaux de votre serveur d'origine.

Le récit du gouvernement australien illustre concrètement le problème de l'acheminement. Selon le Premier ministre, OpenAI a envoyé le 10 septembre un avis concernant Services Australia à une boîte aux lettres publique, après l'événement du 18 juin. Cette déclaration ne fixe pas de délai général pour ce type de trafic. Elle montre pourquoi l'opérateur a besoin d'un canal qui mène à un responsable de sécurité identifiable, avec assez de détails pour que le destinataire retrouve l'événement.

## Que doit préciser une note de clôture circonscrite ?

Clôturez le dossier par un constat qui nomme les preuves, leurs limites et le motif qui justifierait sa réouverture. « Bloqué » décrit le résultat d'une requête précise. « Aucune preuve de compromission » décrit les sources et la période examinées. « Aucune compromission n'a eu lieu » est une affirmation bien plus large.

Une note de clôture concise pourrait être : « À 10 h 07 UTC, nous avons observé une requête ressemblant à une tentative XSS vers le tableau de bord public. Les journaux du contrôle en périphérie indiquent qu'elle a été bloquée. Nous n'avons trouvé aucune requête correspondante dans les journaux conservés du serveur d'origine, ni aucune preuve d'exécution dans les traces applicatives examinées de 9 h 55 à 10 h 20 UTC. Nous n'avons pas examiné le trafic hors de cette période. L'exposition de la préproduction a fait l'objet d'une vérification distincte. Nous rouvrirons le dossier si l'un des éléments suivants révèle un autre résultat : une entrée correspondante dans les journaux du serveur d'origine, une lecture non autorisée ou une trace de l'opérateur. » Adaptez chaque proposition aux vérifications réellement effectuées.

Conservez un relevé des mesures liées au dossier pour toute modification de règle, correction en préproduction ou réponse de l'opérateur. Si une découverte ultérieure établit un effet non autorisé, requalifiez l'incident et suivez votre procédure habituelle de réponse et de notification. Si le constat reste celui d'une « tentative observée », vous pouvez clore le dossier sans affirmer que l'agent était inoffensif ni prétendre en avoir identifié l'auteur. Un bon triage laisse à la prochaine personne chargée de l'enquête une trace défendable.

## Comment Kit peut-il aider votre équipe ?

Le processus CSIRT de Kit peut donner un cadre à la réponse humaine : un rapport limité au compte concerné, avec un responsable, un état, des pièces jointes, une chronologie et la gestion de l'astreinte et des SLA. Un dossier PDF peut rassembler le récit de l'enquête et l'inventaire des preuves. Conservez les preuves brutes provenant du WAF, du serveur d'origine, des systèmes d'identité et des magasins de données dans les systèmes qui les ont produites. Ajoutez ensuite au rapport des liens ou des résumés des éléments restreints, selon les règles d'accès de votre équipe.

Un canal public de divulgation des vulnérabilités et un processus de communication avec les chercheurs sont utiles lorsqu'un opérateur ou un chercheur envoie un rapport. Ils ne remplacent pas la personne chargée de diriger l'incident en interne lorsque le premier signal provient du trafic dans vos propres journaux. Kit n'ingère pas automatiquement les journaux d'analyse, ne rapproche pas les identifiants de requête, n'identifie pas les opérateurs d'agents, n'arrête pas un agent et ne garantit pas la chaîne de conservation des preuves. L'identifiant du dossier facilite la cohérence interne ; il ne prouve pas l'absence d'altération.

Commencez par un exercice modeste : choisissez une requête synthétique bloquée, consignez le constat en périphérie et à l'origine, désignez la personne qui prend le relais et rédigez une note de clôture qu'un collègue pourra vérifier. Si votre équipe reçoit également des signalements externes, [mettez en place un programme de divulgation clair](/blog/how-to-set-up-vulnerability-disclosure-program) pour qu'un véritable opérateur sache où envoyer sa trace. Le résultat utile est une réponse précise à la question « que s'est-il passé ici ? », avec une personne responsable de la suite.