Un meilleur modèle résoudra-t-il l'injection de requêtes ?

Non. La vulnérabilité est structurelle : les instructions et le contenu arrivent par le même canal, sous forme de texte. Les meilleurs modèles augmentent le coût d'une attaque ; seul le harness limite son rayon d'action.

En quoi cela diffère-t-il de la gouvernance de l'IA ?

La gouvernance décide de ce qui est autorisé et de qui en est responsable. La cyberdéfense rend difficile l'abus de ce qui est autorisé. Elles partagent des preuves — journaux, évaluations, approbations — c'est pourquoi elles sont généralement construites ensemble.

Par quoi une équipe devrait-elle commencer ?

Rédigez le modèle de menace pour un agent, listez la pire chose qu'on pourrait lui faire faire, et supprimez sa capacité à le faire sans intervention humaine. Tout le reste n'est que raffinement.

Cela s'applique-t-il aux agents qui ne font que lire ?

Oui, avec une surface plus réduite. Un agent en lecture seule peut toujours exfiltrer ce qu'il lit, de sorte que les limites de contexte et le contrôle de sortie restent importants même si aucun outil ne peut écrire.

GouvernanceMis à jour 2026-08-22 · Version 1.0

Qu'est-ce que la cyberdéfense de l'IA ?

La cyberdéfense de l'IA est la pratique consistant à protéger les systèmes d'IA — modèles, agents, outils qu'ils appellent et données auxquelles ils accèdent — contre les attaques qui exploitent la façon dont ces systèmes raisonnent et agissent. Pour les agents, il ne s'agit pas d'une couche ajoutée après coup : les contrôles qui bloquent une attaque sont les mêmes composants du harness qui permettent à l'agent de fonctionner — permissions des outils, limites de contexte, barrières d'approbation, observabilité. Défendre un agent revient à concevoir son harness.

Preuve: Observation du secteurConfiance: ÉlevéSource: Observation du secteurSource: Publication scientifiqueSource: Expérience personnelle

Lisible par machine: JSON

Définition

La cyberdéfense de l'IA est la pratique consistant à protéger les systèmes d'IA, ainsi que les organisations qui les exploitent, contre les attaques ciblant l'IA elle-même — ses entrées, son contexte, ses outils et son autonomie — grâce à des contrôles implémentés dans le harness autour du modèle plutôt que dans les poids du modèle.

Points clés

Le modèle est rarement la surface d'attaque ; c'est le harness qui l'entoure qui l'est.
Les attaques ciblent les entrées, la mémoire, les outils et l'autonomie d'un agent — pas ses paramètres.
Vous ne pouvez pas corriger un modèle de langage contre l'injection de requêtes. Vous devez limiter ce qu'un agent détourné est capable de faire.
Chaque contrôle défensif est également un contrôle de fiabilité : moindre privilège, validation, barrières d'approbation, journaux d'audit.
Deux directions partagent ce nom : défendre les systèmes d'IA et utiliser l'IA pour défendre. Elles partagent des outils, pas des modèles de menace.

Contexte

La sécurité applicative classique suppose que le code décide et que les données sont inertes. Un agent brise cette hypothèse : il lit du contenu non fiable puis prend des décisions à partir de celui-ci, de sorte que tout document, page web ou réponse d'outil est une instruction potentielle.

C'est là que l'adoption en entreprise stagne. L'examen de sécurité est le bloqueur le plus courant entre la démo d'un agent et sa mise en production, car le risque est inhabituel : le système se comporte exactement comme prévu et fait pourtant l'objet d'abus.

Architecture

Limite d'entrée — le contenu non fiable est délimité et étiqueté comme donnée, jamais concaténé dans le canal d'instructions.

Couche d'outils — chaque outil dispose de l'identifiant le plus restreint possible lui permettant de fonctionner, et déclare s'il est en lecture seule.

Barrière d'action — les actions irréversibles ou à forte valeur s'arrêtent pour obtenir une approbation humaine au lieu de s'en remettre au jugement du modèle.

Contrôle de sortie — les destinations sortantes sont sur liste autorisée, de sorte que l'exfiltration nécessite une faille ouverte délibérément.

Observabilité — chaque appel d'outil, ses arguments et son résultat sont enregistrés, car un incident que vous ne pouvez pas reconstruire est un incident que vous ne pouvez pas résoudre.

Évaluation contradictoire — les cas d'injection et d'abus s'exécutent dans la CI aux côtés des tests fonctionnels, de sorte qu'une régression fait échouer un build plutôt qu'un client.

Composants

Modèle de menace pour l'agent spécifiqueIdentifiants d'outils au moindre privilègeLimite de confiance entre instructions et contenuBarrière d'approbation humaine pour les actions irréversiblesListe autorisée de sortieJournal d'audit infalsifiable des appels d'outilsSuite d'évaluations contradictoiresProcédure de réponse aux incidents couvrant le comportement de l'agent

Avantages

Les contrôles sont auditables et testables, contrairement aux assurances au niveau du modèle qui ne peuvent pas être vérifiées de l'extérieur.
Le même travail garantit la fiabilité : un agent qui ne peut pas supprimer le mauvais enregistrement par malveillance ne peut pas non plus le supprimer par erreur.
Il s'aligne directement sur les obligations auxquelles les organisations sont déjà confrontées — obligations de robustesse et de cybersécurité de l'EU AI Act, ISO/IEC 42001, NIST AI RMF.
Il donne à l'examen de sécurité un élément concret à approuver, ce qui débloque la mise en production.

Risques

Théâtre de la sécurité : un modèle de garde-fous filtrant le texte alors que l'agent détient toujours une clé API avec droits d'écriture.
Une restriction excessive qui rend l'agent inutile et pousse les utilisateurs vers des copies non officielles sans aucun contrôle.
Supposer que les paramètres par défaut des fournisseurs sont sûrs, en particulier pour les serveurs d'outils tiers que personne dans l'équipe n'a analysés.
Traiter cela comme un examen ponctuel plutôt que comme un cycle de vie : nouvel outil, nouvelle surface d'attaque.

Outils et technologies

OWASP Top 10 pour les applications LLM — vocabulaire de risque partagéMITRE ATLAS — tactiques et techniques d'adversaires observées contre les systèmes d'IANIST AI RMF et son profil d'IA générativeBibliothèques de validation et de garde-fous d'entrée/sortieEnvironnements d'exécution isolés (sandbox) et proxys de sortieHarnesses d'évaluation contradictoire intégrés à la CI

Exemples

Un agent qui lit une boîte de réception partagée et peut envoyer des e-mails : un e-mail injecté lui ordonne de transférer les vingt derniers messages à une adresse externe.
Un agent de codage détenant un jeton de dépôt, orienté vers une dépendance dont le fichier README contient des instructions cachées.
Un client MCP qui se connecte à un serveur d'outils tiers dont les descriptions d'outils contiennent des instructions destinées au modèle plutôt qu'au développeur.

FAQ

Un meilleur modèle résoudra-t-il l'injection de requêtes ?: Non. La vulnérabilité est structurelle : les instructions et le contenu arrivent par le même canal, sous forme de texte. Les meilleurs modèles augmentent le coût d'une attaque ; seul le harness limite son rayon d'action.
En quoi cela diffère-t-il de la gouvernance de l'IA ?: La gouvernance décide de ce qui est autorisé et de qui en est responsable. La cyberdéfense rend difficile l'abus de ce qui est autorisé. Elles partagent des preuves — journaux, évaluations, approbations — c'est pourquoi elles sont généralement construites ensemble.
Par quoi une équipe devrait-elle commencer ?: Rédigez le modèle de menace pour un agent, listez la pire chose qu'on pourrait lui faire faire, et supprimez sa capacité à le faire sans intervention humaine. Tout le reste n'est que raffinement.
Cela s'applique-t-il aux agents qui ne font que lire ?: Oui, avec une surface plus réduite. Un agent en lecture seule peut toujours exfiltrer ce qu'il lit, de sorte que les limites de contexte et le contrôle de sortie restent importants même si aucun outil ne peut écrire.