Le Blue Teaming de l’IA expliqué : les trois couches dans lesquelles un contrôle peut réellement résider

Demandez à une équipe de sécurité où résident ses garde-fous IA et la réponse désigne généralement un document de politique, un prompt système ou une fonctionnalité d'un fournisseur. Aucun de ces éléments n'est un contrôle. Un contrôle est ce qui décide, au moment d'une action, si cette action a lieu — et pour un agent IA, seuls trois endroits peuvent décider : le modèle, la passerelle qui le précède et l'environnement qui l'entoure. Tout ce qu'une équipe bleue peut honnêtement promettre provient des deuxième et troisième. C'est la question des couches, et elle précède toute autre décision d'une équipe bleue, y compris ce qu'il faut journaliser et qui appeler. C'est aussi pourquoi les preuves de terrain comptent : l'archive des incidents IArecense 400 incidents d'agents de 2024-12 au 2026-10-17, et la plupart ne racontent pas un modèle qui se comporte mal. Ils racontent un déploiement sans aucune couche capable de dire non.

Le blue teaming au sens de l’IA consiste à mettre ces couches en place, à ajuster ce qu’elles détectent et à disposer d’une réponse rodée pour le jour où l’une d’elles se déclenche. C’est peu glamour, cela ne produit aucun score, et c’est la seule moitié de la paire red-team/blue-team qui modifie le chiffre du risque.

Ce dont une équipe bleue hérite, et ce dont elle n’hérite pas

Le blue teaming traditionnel repose sur un ensemble d’hypothèses que les déploiements d’IA brisent discrètement. Les journaux étaient supposés complets, car le réseau voyait chaque paquet. Les actifs étaient supposés énumérables, car quelqu’un devait les provisionner. Le comportement était supposé déterministe, car un programme fait la même chose avec les mêmes entrées. Aucune des trois ne survit au contact d’un agent.

Ce qu’une équipe bleue hérite à la place, c’est d’un système dans lequel les décisions les plus lourdes de conséquences se prennent à l’intérieur d’une requête que la couche réseau traite comme du trafic HTTPS ordinaire vers un seul nom d’hôte. Le prompt, le contexte récupéré, les appels d’outils, la complétion — tout cela se trouve dans le corps d’une requête, et si personne ne capture ni n’analyse ce corps, le déploiement n’est fonctionnellement pas surveillé, quelle que soit la qualité du périmètre. La première tâche de l’équipe bleue n’est donc pas la détection ; c’est d’établir un capteur. Sans visibilité au niveau des requêtes et des outils, il n’y a rien à détecter, et tout contrôle en aval est décoratif.

Qui peut réellement faire appliquer le contrôle ?

Une fois qu'il existe un capteur, la question devient de savoir où chaque contrôle est autorisé à se trouver. La manière utile de représenter cela est selon la propriété plutôt que selon la technologie, car c'est la propriété qui détermine si un contrôle survit à la prochaine version.

La couche modèle appartient à celui qui l'a entraînée. Vous ne la configurez pas, vous ne pouvez pas voir à l'intérieur, et son comportement évolue lorsque le fournisseur livre une nouvelle version — ce qui peut arriver n'importe quel mardi. Ce que vous pouvez faire, c'est épingler une version et considérer tout changement de version comme une modification de votre posture de risque nécessitant un nouveau test. Ce que vous ne pouvez pas faire, c'est revendiquer un contrôle ici. « Le modèle refuse les demandes nuisibles » est une propriété sur laquelle vous comptez, pas un mécanisme que vous exploitez.

La couche de passerelle est l'endroit où chaque prompt et chaque complétion traverse un composant qui vous appartient. C'est là que résident les limites de budget et de débit, que les listes d'autorisation et les permissions d'outils sont appliquées, que la journalisation des requêtes et des réponses est complète par construction, et où une requête peut être réécrite, bloquée ou redirigée avant que le moindre token soit facturé. Les contrôles de passerelle sont aussi les seuls qui restent attachés lorsque vous changez de modèle, ce qui compte plus qu'il n'y paraît : les équipes qui placent leurs contrôles dans les prompts les perdent entièrement le jour où elles migrent.

La couche environnement est celle qui est entièrement la vôtre : les identifiants et leurs portées, la sortie réseau, l’accès aux fichiers, les limites du bac à sable sur le temps d’horloge et les dépenses. C’est aussi là qu’une exécution compromise fait ses dégâts. Un agent que l’on a amené à agir malveillamment est dangereux exactement à la mesure de ce que l’environnement a permis à cette action d’atteindre — et l’environnement est le seul endroit où le « moindre privilège » est un changement de configuration plutôt qu’un problème de recherche.

Le test pratique de tout contrôle de l'IA proposé tient en une question : laquelle de ces trois couches le fait appliquer ? Si la réponse est la couche modèle, le contrôle n'est qu'un espoir. Si la réponse est « le prompt système », il s'agit d'une suggestion à l'intérieur de la couche modèle, ce qui est pire qu'un espoir car elle s'accompagne d'une documentation qui prétend le contraire.

Détecter : ce qu’un agent émet réellement

La détection pour les agents repose sur un ensemble de signaux différent de celui de la détection pour les humains. Il n’y a pas d’anomalie de connexion à corréler. Ce qu’il y a à la place, c’est un flux de requêtes à la structure exceptionnellement riche, et quatre familles de signaux sur lesquels il vaut la peine d’alerter.

• Volume et forme des appels d’outils. Un agent qui appelle soudainement un outil de lecture de fichiers quarante fois dans une seule tâche, ou dont la séquence d’outils passe de trois étapes à trente, mérite qu’on y regarde de plus près — non pas parce qu’il est malveillant, mais parce que la distribution a changé.

• Provenance du contenu à la frontière. Quel texte dans l’invite provient de l’utilisateur, quel texte de la récupération, quel texte d’un résultat d’outil et quel texte de la mémoire. La plupart de la détection d’injection d’invite se résume à « du texte d’instruction est apparu dans un canal qui ne devrait transporter que des données », et vous ne pouvez pas calculer cela à moins que la passerelle n’étiquette la provenance à l’entrée.

• Sorties réseau et limites de périmètre. Demandes vers des destinations hors de la liste d’autorisation, lectures de chemins hors périmètre, tentatives d’utilisation d’identifiants en dehors du service auquel ils sont destinés. Ce sont des signaux de haute précision et peu coûteux, car l’environnement sait déjà ce qui était autorisé.

• Les coûts et la latence comme indicateur indirect. Une boucle qui s'emballe et une compromission se traduisent tous deux par un changement de pente de la courbe des coûts. Les alertes budgétaires sont la détection la moins glamour de la pile, et parmi les plus rapidement rentabilisées.

Ce qui est délibérément absent de cette liste, c’est un classifieur chargé de juger si une complétion était nuisible. C’est l’idée de détection vers laquelle les équipes se tournent en premier, et celle qui vieillit le plus mal : elle dérive avec le modèle, elle a un taux de faux positifs qui entraîne vos analystes à l’ignorer, et elle ne vous donne rien à mettre dans un runbook.

Contenir : les trois leviers qui stoppent une exécution défaillante

Le confinement d’un agent est plus simple qu’il n’y paraît, car trois réglages couvrent presque tout. Budget plafonne ce qu’une exécution peut dépenser, ce qui limite à la fois les dommages financiers et le rayon d’impact d’une boucle. Périmètre plafonne ce qu’une exécution peut toucher — les outils activés pour cette tâche, les chemins, les locataires. Bac à sable plafonne combien de temps il peut s’exécuter et ce à quoi il peut accéder pendant son exécution. Tous les trois sont des paramètres de passerelle ou d’environnement, ce qui revient à dire qu’ils peuvent être appliqués.

Le principe de conception qui compte est une portée par tâche plutôt qu'une portée par agent. Un agent doté d'un ensemble d'autorisations permanentes est un agent dont les autorisations s'accumuleront jusqu'à ce que quelqu'un les audite ; un agent qui reçoit un identifiant d'accès limité à la tâche pour la durée d'une tâche dispose d'une frontière qui expire d'elle-même. La seconde demande plus de travail à construire et coûte bien moins cher à défendre.

C’est également là qu’une passerelle justifie son nom. Les contrôles qui se trouvent devant chaque appel de modèle — les appels d’outils et MCP évalués avant leur exécution, la politique de contenu et le masquage des données personnelles appliqués avant que la requête ne soit facturée — sont les mêmes, que le modèle derrière eux soit celui utilisé le trimestre dernier ou celui livré la semaine dernière. Cette continuité est le véritable produit : non pas un meilleur filtre, mais un endroit où le filtre réside et qui ne bouge pas quand le modèle change.

Récupérer : rejouer, corriger, retester

La récupération après un incident d’IA présente un avantage sur celle après un incident réseau : l’intégralité de l’exécution est généralement enregistrée. Le prompt, le contexte, les appels d’outils, les complétions, les timings — si la passerelle les a journalisés, l’incident peut être rejoué, ce qui constitue un point de départ plus solide que ce que la plupart des analyses forensiques obtiennent.

Le rejeu remplit trois fonctions successives. Il établit ce qui s’est réellement produit, plutôt que ce que la transcription laisse penser être arrivé après que plusieurs personnes l’ont résumée. Il identifie le contrôle qui aurait dû se déclencher, ce qui fait la différence entre corriger un symptôme et corriger une frontière. Et il produit le cas de régression : une entrée enregistrée qui doit désormais être bloquée, exécutée sur la nouvelle configuration pour prouver qu’elle l’est.

L’étape de correctif est celle où les équipes bleues se trompent le plus souvent de cible. Si le constat portait sur un comportement du modèle, les mesures d’atténuation disponibles se situent toutes en dehors du modèle — une réduction du périmètre, un filtre au niveau de la passerelle, une autorisation retirée de l’environnement. Si le constat portait sur un comportement du système, le correctif se trouve dans la configuration et le test de régression est peu coûteux. Dans les deux cas, retester n’est pas facultatif, car le correctif et la version du modèle évoluent tous deux, et un contrôle qui a été vérifié sur la version du mois dernier est une affirmation sur le mois dernier.

Répéter le jour où ça se déclenche

Un runbook qui n'a jamais été lu sous pression est un document, pas une capacité. La répétition qui rapporte est étroite et spécifique : prenez un incident d'agent plausible, déroulez-le de bout en bout et chronométrez chaque étape. Qui le remarque ? Combien de temps avant qu'un humain ne se penche sur la bonne ligne de journal ? Qui peut arrêter l'exécution — une personne nommée, ou un comité ? Qui peut révoquer l'identifiant, et combien de temps la révocation met-elle à se propager ? Qui décide s'il faut prévenir quelqu'un à l'extérieur de l'entreprise ?

Deux de ces questions prennent régulièrement les équipes en défaut. « Qui peut arrêter le processus » échoue lorsque l’arrêt nécessite une personne qui dort, car la réponse doit être un mécanisme plutôt qu’une personne : un plafond budgétaire ou un coupe-circuit qu’un ingénieur d’astreinte peut déclencher seul. « Combien de temps prend la révocation » échoue parce que les identifiants sont souvent mis en cache dans des composants qui ne figuraient pas dans le schéma.

Lire les archives est la forme de répétition la moins coûteuse qui soit, car elle vous permet d’hériter de la structure d’incident des autres au lieu d’inventer la vôtre. Prenez une poignée d’entrées qui ressemblent à votre déploiement et, pour chacune, posez les trois questions ci-dessus. Les entrées pour lesquelles vous ne pouvez pas y répondre sont les lacunes de votre runbook, et vous les avez trouvées avant l’incident plutôt qu’après.

L'asymétrie qu'il vaut la peine d'énoncer clairement

Le red teaming et le blue teaming ne sont pas des activités symétriques et ne devraient pas faire l’objet de budgets comme s’ils l’étaient. Un exercice de red team est délimité par un calendrier et produit un ensemble de constats qui s’obsolètent à mesure que la cible change. Les contrôles d’une blue team persistent, s’accumulent et sont la seule chose qui se dresse réellement entre une mauvaise entrée et un mauvais résultat. Un engagement peut trouver une limite ; seule l’autre peut la tenir.

Ce qui rend le standard honnête d’une blue team peu glamour et vérifiable. Pour chaque contrôle que vous revendiquez, vous devriez pouvoir nommer la couche qui l’applique, la ligne de journal qui prouve qu’il s’est déclenché, l’alerte qui vous prévient lorsqu’il ne s’est pas déclenché, et la personne qui peut couper l’exécution. Quatre phrases. Si l’un de ces éléments manque, le contrôle n’est qu’un document de politique, et les documents de politique ne lisent pas les corps des requêtes.