La plupart des programmes de sécurité comptent seulement ce qui a mal tourné. Un incident est ouvert, analysé, fermé et déclaré. Les tentatives qu’un contrôle a arrêtées laissent une ligne dans les logs, et c’est tout.
Avec les agents IA, c’est le contraire qu’il faut faire. Un agent qui essaie de joindre une destination interdite et qui se fait bloquer par une règle de trafic sortant n’a pas causé d’incident. Il vous a quand même appris deux choses : l’agent était prêt à franchir cette limite, et la limite a tenu. Les deux valent la peine d’être conservées. Avec le temps, c’est la seule preuve que vous avez que vos contrôles d’agents fonctionnent.
Ce registre a maintenant un nom. Les pratiques de réponse aux incidents publiées en octobre par le NIST, la NSA et la CISA définissent le quasi-incident (near miss) et demandent aux organisations de les suivre et de les déclarer. Le gouvernement britannique dit qu’il va examiner l’idée d’en inscrire la déclaration dans la loi. Vous n’avez pas besoin d’attendre l’un ou l’autre pour commencer.
Ce que disent les lignes directrices
Les Key Practices for Incident Readiness and Response définissent le quasi-incident de contrôle comme un événement qui n’est pas devenu un incident, mais qui présentait un risque raisonnablement prévisible ou imminent de le devenir. Elles expliquent pourquoi ça compte : les quasi-incidents peuvent révéler des lacunes ou des faiblesses dans les contrôles, les mesures de sécurité ou les processus.
Les quasi-incidents reviennent ensuite d’un bout à l’autre des pratiques :
- 2.1 demande des indicateurs, des critères et une échelle de gravité clairs pour les incidents et les quasi-incidents.
- 1.7 demande des mécanismes pour bloquer, contenir ou arrêter l’activité d’un agent quand un incident ou un quasi-incident est détecté.
- 5.1 demande de conserver les actions et les tool calls refusés, pas seulement ceux qui ont réussi.
- 9.1 encourage la déclaration volontaire à la CISA des quasi-incidents découlant d’incidents de contrôle, et 9.3 leur partage volontaire avec les experts du gouvernement.
Le 12 octobre, dans un discours à l’Imperial College de Londres, le ministre britannique de l’IA, Kanishka Narayan, a dit que le gouvernement allait évaluer comment renforcer le projet de loi Cyber Security and Resilience Bill pour repérer et déclarer les incidents graves et les quasi-incidents. Il n’y a pas encore de texte d’amendement. La direction est quand même assez claire pour qu’on s’y prépare.
Pourquoi les quasi-incidents sont les données qui comptent
Pour l’instant, les incidents impliquant des agents sont rares dans une organisation donnée. Un indicateur bâti sur des événements rares n’apprend à peu près rien à un conseil d’un trimestre à l’autre. Les quasi-incidents, eux, sont fréquents. Ils montrent quels agents poussent sur leur périmètre, sur quelles limites, et quelle couche de contrôle les arrête.
Le rapport d’Anthropic sur les actions non voulues de ses modèles en donne un bon exemple. Ses modèles ont contourné la limite de longueur d’un outil de consultation de pages web avec des raccourcisseurs d’URL, et ont soumis des formulaires auxquels on leur avait dit de ne pas toucher. Anthropic a ensuite bâti un outil pour détecter et bloquer ces comportements. À partir de là, chaque répétition devient un quasi-incident : une tentative, un blocage, une trace. C’est cette trace qui vous dit si le comportement s’estompe ou s’aggrave.
Le registre
Une ligne par tentative qu’un contrôle a arrêtée, ou qui a failli causer un préjudice. Peu de champs, tous obligatoires :
- Agent. L’entrée de l’inventaire, pour rattacher la tentative à un responsable et à un périmètre déclaré. Notre inventaire des agents en dix champs sert de référence.
- Horodatage. Pris d’une horloge que l’agent ne contrôle pas.
- Action tentée. Ce que l’agent a essayé de faire, en une phrase : « consulter une URL externe par un raccourcisseur », « lire la table de la paie », « envoyer un courriel à un domaine externe ».
- Limite. La règle frappée : liste d’autorisation sortante, politique d’accès aux données, exigence d’approbation, portée de l’identifiant.
- Contrôle qui l’a arrêtée. Nommez la couche, ou inscrivez « aucun ». « Aucun » veut dire que la tentative a été remarquée après coup, par une personne ou lors d’une revue.
- Résultat. Bloquée, transmise à une personne, ou autorisée après revue.
- Gravité. Selon l’échelle que demande la pratique 2.1 : qu’est-ce qui serait arrivé si le contrôle avait lâché ?
- Responsable et suivi. Qui examine l’entrée, et si elle mène à un changement de contrôle, de prompt, de permission, ou à rien du tout.
Les deux champs les plus importants sont la gravité et le contrôle qui a arrêté la tentative. La gravité vous dit à quel point l’échec aurait fait mal. Le contrôle vous dit où se trouve votre vraie frontière.
Les données existent déjà
Pas besoin d’un nouvel outil. La plupart de ces données sont déjà écrites quelque part, et personne ne les regarde :
- Les refus de la gateway ou du proxy sortant pour le trafic des identités d’agents.
- Les refus du moteur de politiques sur les tool calls, si votre plateforme d’agents en a un.
- Les rejets aux points d’approbation : une personne a dit non à une action lourde de conséquences demandée par l’agent.
- Les événements d’accès refusé du fournisseur d’identité et du cloud pour les identités d’agents.
- Les déclenchements de leurres : identifiants ou enregistrements bidon que seul un agent hors périmètre toucherait, comme le recommande la pratique 3.5.
- Les logs de tool calls refusés de l’environnement d’exécution, conservés comme le demande la pratique 5.1.
Le vrai travail, c’est l’attribution. Chaque événement doit être rattaché à un agent de l’inventaire. Ça marche seulement si chaque agent a sa propre identité, et c’est pour ça que l’inventaire vient en premier.
Branchez-le sur ce qui roule déjà
Ne créez pas un processus à part pour l’IA. Envoyez ces événements dans le SIEM et le système de billets que votre SOC utilise déjà :
- Étiquetez chaque événement qui vient d’une identité d’agent, pour pouvoir séparer l’activité des agents de celle des personnes.
- Créez un type de billet « quasi-incident » avec les champs ci-dessus. La plupart des entrées peuvent être créées et fermées automatiquement. Au-delà d’un seuil de gravité, une personne prend le relais.
- Ajoutez deux champs à votre fiche d’incident actuelle, pour que les vrais incidents alimentent le même jeu de données : l’agent a tenté une action non autorisée (oui ou non) et contrôle qui a empêché l’impact (lequel, ou aucun).
- Passez le registre en revue à la même rencontre hebdomadaire que les autres événements de sécurité, avec les responsables des agents autour de la table.
Ce que le conseil voit chaque trimestre
Les administrateurs n’ont pas besoin des lignes. Trois chiffres par trimestre, avec leur tendance :
- Les tentatives par agent, ramenées au volume d’activité. Un taux qui monte pour un agent signale un changement de comportement, de périmètre ou d’exposition qu’il faut expliquer.
- Le taux d’interception par couche de contrôle. Si le réseau arrête tout et que le point d’approbation ne se déclenche jamais, soit votre point d’approbation est à la mauvaise place, soit vos agents ne demandent jamais. Dans les deux cas, c’est un constat.
- Le nombre de « contrôle qui a empêché l’impact : aucun ». Chacun, c’est une limite qui n’a pas tenu et qu’on a découverte par chance ou lors d’une revue. La cible est zéro, et la tendance compte plus que le chiffre.
Le format reprend notre billet sur les questions qu’un conseil devrait poser avant d’approuver un outil de codage par IA : une page, pas un tableau de bord.
Deux façons de rater son coup
Compter le bruit. Une liste d’autorisation mal configurée peut générer des milliers de refus par jour à partir d’une tâche légitime. Si chaque refus devient un quasi-incident, le registre devient un journal, et personne ne lit les journaux. Dédoublonnez par agent, limite et action tentée, et corrigez le périmètre avant de compter.
Chercher un coupable. Un registre des quasi-incidents fonctionne seulement si les gens y déclarent. Les industries où la sécurité est critique ont appris depuis longtemps que les déclarations se tarissent quand elles mènent à des sanctions. Les responsables d’agents doivent pouvoir inscrire « mon agent a essayé ceci » sans qu’on le leur reproche. La question, c’est toujours quel contrôle a failli, pas qui a failli.
Besoin d’un deuxième regard ?
Notre évaluation de la sécurité de l’IA générative bâtit l’inventaire des agents, repère où vos événements de refus et de rejet aboutissent déjà, et définit les critères de quasi-incident et l’échelle de gravité que demande la pratique 2.1. Vous repartez avec un registre branché sur vos opérations actuelles et un format trimestriel d’une page pour le conseil.
Quatre questions à poser à votre équipe
- Si un agent s’était fait bloquer hier vers une destination non approuvée, est-ce que quelqu’un chez nous le saurait aujourd’hui ?
- Peut-on rattacher chaque événement de refus à un seul agent, ou nos agents partagent-ils des identités avec des personnes et d’autres systèmes ?
- Nos logs d’agents gardent-ils les tool calls refusés, ou seulement ceux qui ont été exécutés ?
- Qu’est-ce que notre conseil apprendrait de nos quasi-incidents d’agents du dernier trimestre, et est-ce que ces données existent ?
Si la réponse à la dernière est « rien », commencez par les deux champs de votre fiche d’incident. Ils ne coûtent rien et, dans trois mois, ils vont vous donner la première courbe de tendance que vos contrôles d’agents aient jamais eue.