Sécurisation des systèmes d’IA en cybersécurité en 2026 : modèle de menace, architecture défensive, évaluation expérimentale et étude de cas sur les attaques par empoisonnement, évasion et exfiltration

1. Introduction

L’essor des systèmes d’IA en cybersécurité a profondément modifié la surface d’attaque des organisations. En 2026, les SOC modernes utilisent des copilotes LLM pour corréler des alertes, résumer des incidents, générer des requêtes de chasse et déclencher des actions sur des outils de réponse. Les équipes de détection exploitent aussi des modèles pour la classification de fichiers, la priorisation des vulnérabilités, l’analyse de journaux, la détection d’anomalies et la remédiation automatisée. Cette intégration apporte un gain opérationnel réel, mais elle introduit également une dépendance à des composants probabilistes dont le comportement peut être manipulé, contourné ou instrumentalisé. La question n’est donc plus de savoir si l’IA améliore la cybersécurité, mais si l’IA elle-même est sécurisée de manière suffisante pour supporter des opérations critiques.

L’enjeu est systémique. Un système d’IA de cybersécurité est rarement un modèle isolé ; c’est un assemblage de bases de connaissances, de connecteurs, de moteurs de recherche vectorielle, de journaux, de plugins, de fonctions outillées, de politiques d’autorisation et d’interfaces humaines. Chaque couche devient une surface d’attaque. Une injection indirecte dans une source de données peut modifier le comportement d’un agent ; une compromission du pipeline MLOps peut introduire un modèle malveillant ; une base vectorielle mal gouvernée peut exposer des documents sensibles ; une instruction ambiguë peut amener un assistant à divulguer un secret ou à lancer une action destructrice. En pratique, la sécurité de l’IA se confond avec la sécurité des chaînes de données, des chaînes d’outils et des chaînes décisionnelles.

La littérature des années 2020 a montré que les attaques contre les modèles ne sont pas théoriques. Les travaux fondateurs sur l’empoisonnement des données, l’évasion par exemples adversariaux, l’extraction de modèles et l’inférence d’attributs ont établi une base scientifique solide. Les attaques sur les LLM et les agents ont ensuite ajouté une dimension opérationnelle nouvelle, en particulier via l’injection de prompt, la contamination des contextes récupérés par RAG, l’exploitation des outils connectés et l’abus des permissions. À partir de 2023 et 2024, les incidents publics se sont multipliés : divulgations accidentelles de données, hallucinations instrumentées, comportements non autorisés, exposition de secrets via des connecteurs, et démonstrations de jailbreaks de modèles commerciaux. En 2026, il devient impossible de traiter la sécurité de l’IA comme une simple extension du secure coding.

Ce papier se concentre sur l’IA Security dans un contexte cyber : comment protéger des systèmes d’IA utilisés pour défendre des infrastructures, tout en empêchant ces mêmes systèmes de devenir une nouvelle voie d’attaque. Nous abordons les trois plans suivants. Premièrement, les données : provenance, qualité, confidentialité, empoisonnement, biais, dérive et gouvernance. Deuxièmement, les modèles : robustesse, alignement, extraction, inversion, évasion et fuites de paramètres. Troisièmement, les agents : outils, connecteurs, autorisations, mémoire, orchestration et journalisation. Cette structuration permet de passer d’une vue abstraite de l’IA à une approche d’ingénierie défensive mesurable.

La contribution de ce travail est quadruple. Nous proposons d’abord un modèle de menace complet adapté aux systèmes d’IA de cybersécurité déployés en entreprise. Nous présentons ensuite une méthodologie défensive en couches, articulée autour de contrôles techniques et organisationnels compatibles avec les pratiques Zero Trust, CNAPP, eBPF et gouvernance de l’IA. Nous décrivons une implémentation réaliste, testable et compatible avec des environnements hybrides. Enfin, nous fournissons une évaluation expérimentale et une étude de cas montrant comment ces mécanismes se comportent face à des attaques concrètes.

L’ambition de ce papier est double. Sur le plan scientifique, il vise à formaliser la sécurité des systèmes d’IA de cybersécurité comme un sous-domaine à part entière, et non comme une annexe de la ML security. Sur le plan opérationnel, il fournit des principes directement applicables dans des environnements de production. La thèse défendue est simple : en 2026, la sécurité de l’IA ne doit plus être pensée comme un filtre au-dessus d’un modèle, mais comme une architecture de confiance de bout en bout, où les données, les modèles, les outils et les décisions sont tous soumis à des contrôles explicites.

2. Background and Related Work

Les racines de la sécurité de l’IA remontent aux travaux sur les exemples adversariaux. Goodfellow, Shlens et Szegedy ont montré que de petites perturbations, imperceptibles pour l’humain, pouvaient provoquer des erreurs de classification importantes dans les réseaux neuronaux (GOODFELLOW, 2015). Par la suite, les travaux de Carlini et Wagner ont démontré que des attaques plus sophistiquées pouvaient contourner certaines défenses et atteindre des taux de succès élevés (CARLINI, 2017). Ces résultats ont établi un principe fondamental : un modèle appris n’est pas intrinsèquement robuste aux entrées manipulées.

Le domaine s’est ensuite structuré autour de l’adversarial machine learning. Les attaques d’empoisonnement ciblent le corpus d’entraînement ou les données de fine-tuning afin de modifier le comportement du modèle à l’inférence. Les attaques d’évasion cherchent à produire des entrées qui, sans modifier le modèle, conduisent à des prédictions erronées. Les attaques d’extraction et d’inversion exploitent les sorties du modèle ou ses gradients pour reconstruire des informations sur les paramètres ou sur les données d’entraînement. Fredrikson et al. ont, par exemple, montré que des systèmes de prédiction pouvaient révéler des informations sensibles sur les individus (FREDRIKSON, 2015). Tramèr et al. ont illustré l’extraction d’informations sur les modèles via des requêtes adaptatives (TRAMÈR, 2016).

L’industrialisation des pipelines MLOps a renforcé la complexité. Les organisations ont dû composer avec des artefacts versionnés, des registres de modèles, des dépôts de données, des orchestrateurs de tâches, des environnements GPU et des dépendances Python nombreuses et parfois opaques. Les incidents de chaîne d’approvisionnement logicielle ont montré que les risques ne se limitaient pas aux algorithmes eux-mêmes. Dans le cas de l’IA, un composant compromis peut influencer à la fois les données, le code d’entraînement, les artefacts embarqués et les services d’inférence. Les recommandations du NIST AI RMF ont contribué à structurer la gouvernance, la cartographie des risques et la mesure des impacts (NIST, 2023a). Le cadre OWASP Top 10 for LLM Applications a, lui, popularisé les catégories de menace propres aux applications à base de LLM, notamment l’injection de prompt, la divulgation de données sensibles et les risques liés à la chaîne d’outils (OWASP, 2024).

L’arrivée des LLM et des systèmes de type RAG a changé la nature des attaques. Un LLM n’est pas seulement un classifieur ; il est une interface générative capable de synthétiser, exécuter des instructions, appeler des outils et raisonner sur du contexte externe. Les attaques par prompt injection peuvent être directes, lorsque l’attaquant contrôle l’entrée utilisateur, ou indirectes, lorsque le modèle ingère du contenu non fiable provenant d’une page web, d’un document, d’un ticket ou d’un e-mail. Le problème a été largement discuté dans la recherche et les recommandations de sécurité 2023-2025, car un assistant qui lit du contenu externe ne peut pas supposer que ce contenu est coopératif. Le simple fait d’indexer des documents dans une base vectorielle n’élimine pas le risque ; il le déplace.

Les agents outillés constituent une évolution encore plus sensible. Des frameworks comme LangChain, LlamaIndex, AutoGen et les agents intégrés à des solutions commerciales ont permis de connecter les modèles à des systèmes de tickets, à des SIEM, à des EDR, à des référentiels de vulnérabilités et à des environnements cloud. Cette capacité accroît la productivité, mais elle rend les erreurs de politique beaucoup plus coûteuses. Une mauvaise séparation des privilèges peut transformer une hallucination en action réelle. Des recherches récentes ont montré qu’un agent ne doit jamais disposer d’un accès non borné à des outils d’écriture, de suppression ou d’exécution sans mécanismes de confirmation, de garde-fous et d’autorisation granulaire. Cette observation rejoint les principes classiques du moindre privilège, mais elle devient critique dans un environnement probabiliste.

La gouvernance et la conformité ont évolué en parallèle. En Europe, l’AI Act a introduit des obligations graduées pour les systèmes d’IA en fonction du niveau de risque, avec une attention particulière portée aux usages à haut risque et à la documentation technique (PARLEMENT EUROPÉEN, 2024). Les référentiels de sécurité modernes intègrent aussi la logistique de l’IA : provenance des jeux de données, traçabilité des versions, gestion des accès, évaluations d’impact, red teaming spécifique aux modèles et journaux exploitables en investigation. Du côté de la cybersécurité traditionnelle, les architectures zero trust, les plateformes CNAPP et les contrôles basés eBPF ont maturé au point d’offrir une base robuste pour la surveillance et l’isolement, à condition d’être appliqués aux nouveaux artefacts de l’IA.

Le tableau suivant synthétise les principales familles d’attaques et leur impact opérationnel sur les systèmes d’IA utilisés en cybersécurité.

Famille d’attaque	Cible principale	Effet attendu	Exemple opérationnel
Empoisonnement des données	Corpus d’entraînement, fine-tuning, RAG	Modification durable du comportement	Insertion de tickets ou documents manipulés dans une base de connaissances
Évasion	Entrée d’inférence, contexte prompt	Erreur de classification ou de génération	Texte conçu pour contourner un classifieur de phishing
Injection de prompt	Interface conversationnelle, contexte récupéré	Exécution d’instructions non prévues	Document externe ordonnant au modèle de divulguer des secrets
Extraction / inversion	API d’inférence, sorties, gradients	Fuite d’informations sensibles	Reconstruction partielle d’un ensemble d’entraînement
Abus d’agent	Outils, connecteurs, permissions	Action non autorisée	Création/suppression de tickets ou exfiltration via connecteur

Les défenses ont également progressé. La robustesse adversariale, la distillation défensive, la détection d’anomalies dans les embeddings, le filtrage du contenu, le cloisonnement des outils et les politiques de confirmation humaine ont tous été explorés. Toutefois, aucun mécanisme isolé ne résout le problème. En pratique, les systèmes résilients combinent plusieurs couches : provenance des données, surveillance des dérives, scoring de confiance, signatures des artefacts, contrôle d’accès et instrumentation forensique. La leçon des travaux antérieurs est claire : la sécurité d’un modèle ne se déduit ni de sa taille ni de sa performance, mais de la discipline de son environnement d’exploitation.

3. Threat Model and Problem Formalization

Nous considérons un système d’IA de cybersécurité déployé dans une entreprise de taille moyenne à grande. Le système comprend un modèle de langage ou de classification, un moteur de récupération sémantique, plusieurs sources de données internes et externes, des outils connectés à des plateformes SOC, et une interface utilisée par des analystes ou des automatisations. L’adversaire peut être externe, interne, ou hybride. Il peut viser la confidentialité, l’intégrité, la disponibilité ou l’abus opérationnel du système. Il peut aussi agir indirectement via des documents, des tickets, des pages web, des journaux, des e-mails ou des contributions à des dépôts de connaissance.

On définit le système comme $S = {D, M, R, T, P, J}$, où $D$ désigne les données, $M$ le modèle, $R$ le moteur de récupération, $T$ l’ensemble des outils, $P$ les politiques et $J$ la journalisation. L’objectif de sécurité est de minimiser la probabilité qu’une action adversariale provoque un état non souhaité $E$ tel que : $$ \Pr(E \mid A, S) \leq \epsilon $$ où $A$ est l’action attaquante et $\epsilon$ un seuil de tolérance opérationnelle. En contexte cyber, $E$ peut inclure la divulgation de secrets, la modification erronée d’un ticket, la désactivation d’une alerte, la suppression d’un artefact, ou la génération d’un faux négatif critique.

Le modèle d’attaque se compose de trois étapes. Premièrement, l’adversaire obtient un point d’entrée dans la chaîne de données ou de requête. Deuxièmement, il injecte un contenu conçu pour influencer la représentation interne, le contexte récupéré ou la décision de l’agent. Troisièmement, il exploite une faiblesse de politique, d’alignement ou d’autorisation pour provoquer l’effet final. L’attaque peut être purement textuelle, mais elle peut aussi être multimodale, par exemple via des images, des fichiers, des scripts, des pages HTML ou des artefacts PDF.

On distingue quatre classes de vulnérabilités structurelles. La première est la fragilité sémantique : le modèle interprète des instructions non fiables comme des instructions légitimes. La deuxième est la fragilité contextuelle : le système ne distingue pas suffisamment entre instructions système, contexte de récupération et contenu utilisateur. La troisième est la fragilité outillée : des permissions excessives transforment un raisonnement erroné en action réelle. La quatrième est la fragilité de gouvernance : l’organisation ne sait pas retracer quelle version du modèle, quelles données et quelles politiques ont produit une décision donnée.

Le problème de défense peut se formaliser comme un optimiseur multicritère. Soit $f$ la fonction de performance du système, $r$ le risque résiduel, $c$ le coût de défense et $l$ la latence ajoutée. On souhaite maximiser : $$ U = f - \lambda_1 r - \lambda_2 c - \lambda_3 l $$ où les coefficients $\lambda_i$ reflètent les contraintes métier. Cette formulation est importante car une défense trop lente ou trop restrictive est souvent contournée par les opérateurs eux-mêmes. Dans un SOC, une solution inefficace mais tolérable sera désactivée ; une solution robuste mais inutilisable sera ignorée. L’objectif doit donc être une sécurité utile, mesurable et intégrée aux flux de travail.

Le tableau suivant résume les actifs, menaces et impacts dans un environnement d’IA de cybersécurité.

Actif	Menace principale	Impact	Contrôle prioritaire
Jeux de données d’entraînement	Empoisonnement, fuite	Modèle biaisé ou fuite de secrets	Signature, provenance, validation statistique
Index vectoriel RAG	Injection indirecte, contamination	Réponses manipulées	Nettoyage, scoring de confiance, sandbox
Modèle de génération	Jailbreak, extraction, inversion	Divulgation ou sortie dangereuse	Alignement, filtrage, red teaming
Outils connectés	Abus de permissions	Actions non autorisées	RBAC/ABAC, confirmation, scopes minimaux
Journaux et traces	Suppression, falsification	Rupture d’investigation	WORM, horodatage, centralisation

Le modèle d’adversaire est réaliste pour 2026. Il comprend des groupes opportunistes visant des secrets, des opérateurs cherchant à contourner des contrôles, des initiés malveillants ayant accès à des jeux de données, et des attaquants sophistiqués capables de combiner social engineering, empoisonnement et exploitation des automatisations. La présence d’agents IA augmente la probabilité de succès de scénarios multi-étapes, car un attaquant n’a plus seulement besoin de tromper un humain ; il peut aussi tromper une chaîne de traitement automatisée qui agit avec vitesse et mémoire.

4. Proposed Methodology

Nous proposons une méthodologie défensive en cinq couches : gouvernance, intégrité, confinement, supervision et résilience. L’idée centrale est que la sécurité d’un système d’IA en contexte cyber doit être conçue comme une architecture, pas comme un ensemble de filtres. Chaque couche adresse une classe précise de menaces, et l’échec d’une couche ne doit pas compromettre l’ensemble. Cette approche s’aligne avec les pratiques zero trust, la gestion des risques IA, et les contrôles de supply chain de type SLSA appliqués aux artefacts ML.

4.1 Gouvernance de la provenance et de l’usage

La première couche concerne la provenance des données et des artefacts. Tout jeu de données, tout modèle et tout index vectoriel doit être versionné, signé et associé à un manifeste de provenance. Nous recommandons d’utiliser des schémas de type SBOM/MBOM étendus à l’IA, incluant les dépendances Python, les sources de données, les transformations, les paramètres de fine-tuning et les hash des embeddings. Chaque lot de données entrant doit être soumis à un contrôle de qualité, de duplicats, d’anomalies lexicales, de toxicité opérationnelle et de distribution. Les données sensibles doivent être classées avant ingestion, et leur usage par le modèle doit être borné par des politiques d’accès.

4.2 Intégrité du contexte et du retrieval

La deuxième couche protège la chaîne RAG. Le moteur de récupération ne doit jamais fusionner sans discernement des instructions système et du contenu externe. Nous recommandons d’annoter chaque bloc de contexte avec une étiquette de confiance et une provenance. Les documents récupérés doivent être nettoyés des patterns d’injection les plus connus, mais aussi scorés par une politique de plausibilité contextuelle. Une requête de l’utilisateur ne doit pas pouvoir modifier les règles de sécurité du système. Les documents considérés comme non fiables doivent être présentés comme des preuves, pas comme des instructions.

4.3 Confinement des outils et des agents

La troisième couche est le confinement des outils. Un agent ne doit disposer que des permissions strictement nécessaires, pour une durée limitée et dans un périmètre explicite. Les actions destructrices, telles que suppression de tickets, modification de règles, export massif de données ou exécution de commandes, doivent requérir une confirmation humaine ou une politique conditionnelle forte. Les outils doivent être séparés par domaines de confiance, avec journaux indépendants. Une erreur de raisonnement ne doit jamais pouvoir se transformer automatiquement en mouvement latéral.

4.4 Supervision continue et détection de dérive

La quatrième couche vise la surveillance. Il faut mesurer en continu la dérive des embeddings, la distribution des sorties, la fréquence des refus, la latence, les taux de fallback humain et les écarts entre décisions automatiques et validations manuelles. Les séquences de prompt doivent être surveillées à la fois pour les motifs d’attaque connus et pour les anomalies statistiques. Les journaux d’activité doivent être corrélés avec des événements système, réseau et identité. L’approche eBPF est utile pour observer les interactions runtime, en particulier lorsqu’un service d’IA contacte des endpoints inattendus, ouvre des fichiers sensibles ou lance des sous-processus.

4.5 Résilience et red teaming continu

La cinquième couche est la résilience. Les modèles doivent être testés avant déploiement, mais surtout après chaque mise à jour de données, de poids, d’outils ou de politiques. Un programme de red teaming spécifique à l’IA doit inclure des scénarios d’injection indirecte, de contamination RAG, de jailbreak, d’extraction, d’abus d’agent et d’attaque de la mémoire. Les résultats doivent être traduits en métriques : taux de réussite de l’attaque, temps de détection, taux de confinement, nombre de faux positifs et coût opérationnel. L’objectif n’est pas d’atteindre une immunité impossible, mais de réduire l’impact maximal plausible.

Le tableau suivant résume les mécanismes proposés et les menaces traitées.

Couche	Mécanismes	Menaces couvertes	Limites
Gouvernance	Signatures, manifests, classification	Empoisonnement, supply chain	Coût de gestion
Intégrité du contexte	Filtrage, provenance, scoring	Prompt injection, RAG poisoning	Faux négatifs possibles
Confinement	RBAC/ABAC, sandbox, confirmations	Abus d’agent, actions non autorisées	Latence, frictions UX
Supervision	eBPF, SIEM, métriques, drift	Exfiltration, dérive, anomalies	Bruit et complexité
Résilience	Red teaming continu, tests adversariaux	Jailbreak, extraction, évasion	Nécessite expertise durable

4.6 Mécanismes concrets

Nous proposons d’évaluer la sécurité d’un système selon une fonction de score : $$ Score_{sec} = \alpha C + \beta I + \gamma A + \delta T $$ où $C$ représente la conformité de provenance, $I$ l’intégrité contextuelle, $A$ le confinement des actions et $T$ la traçabilité. Chaque terme est normalisé entre 0 et 1. Un score supérieur à un seuil défini par le risque métier est requis pour autoriser la mise en production. Cette métrique n’est pas universelle, mais elle oblige les équipes à rendre explicites les compromis.

L’approche inclut aussi une politique de refus structuré. Lorsque le modèle détecte une tentative de contournement, il doit produire une réponse de refus standardisée, journalisée et non ambiguë. Les réponses de refus doivent éviter de révéler des détails exploitables sur les garde-fous internes. La configuration du système doit interdire l’usage de messages de refus générés librement qui pourraient être instrumentalisés. Enfin, les sorties du modèle destinées à déclencher des actions doivent être validées par un schéma strict, jamais par du texte libre.

5. Implementation

L’implémentation de référence repose sur une architecture modulaire, conçue pour un environnement hybride où coexistent API internes, sources documentaires, EDR/SIEM, dépôts de tickets et charges cloud. La pile technique retenue est volontairement réaliste pour 2026 : Python 3.11+, PyTorch, Hugging Face Transformers, LangChain ou LlamaIndex pour l’orchestration, FAISS pour la recherche vectorielle, MLflow pour le suivi expérimental, OpenTelemetry pour la télémétrie, Sigma pour les règles de détection et un socle d’observation eBPF sur Linux pour la visibilité runtime. Les contrôles d’accès s’appuient sur des politiques RBAC/ABAC, avec des comptes de service séparés et des secrets gérés dans un coffre fortifié.

Le pipeline d’ingestion est le premier point critique. Chaque document entrant est haché, étiqueté, classé et stocké avec métadonnées de provenance. Les transformations appliquées au texte sont journalisées afin de pouvoir reconstruire le chemin de la donnée. Les chunks de récupération sont ensuite indexés dans FAISS avec un identifiant immuable. Les accès au moteur de recherche passent par une couche de politiques qui filtre les documents non autorisés avant toute génération. Les prompts système sont séparés du contexte récupéré et du texte utilisateur par des délimiteurs formels, afin de réduire le mélange d’intentions.

Le moteur d’orchestration des agents applique un schéma d’exécution à deux phases. Dans la phase de planification, le modèle propose une action structurée ; dans la phase d’exécution, un vérificateur de politique contrôle que l’action est conforme aux droits, au périmètre temporel et à la sensibilité des données. Toute action à impact élevé, comme l’export de masse ou la suppression, exige une validation humaine explicite. Cette séparation est fondamentale, car elle empêche qu’un simple jailbreak textuel ne se transforme en commande de production. Les journaux d’actions incluent l’entrée, la sortie, l’identité, le contexte, la décision de politique et l’empreinte des artefacts manipulés.

Voici un exemple de configuration de détection et d’audit avec une logique de surveillance orientée Sigma et journalisation centralisée :

id: 8d4a7b2e-2026-001
status: experimental
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    Image|endswith:
      - "/python"
      - "/python3"
    CommandLine|contains:
      - "langchain"
      - "llamaindex"
      - "tool_call"
      - "export_all"
  condition: selection
fields:
  - Image
  - CommandLine
  - User
  - ParentImage
falsepositives:
  - Legitimate scheduled batch jobs
level: high

Un second exemple illustre le durcissement d’un service d’inférence via une politique réseau et d’exécution. Le but est d’empêcher l’agent de contacter librement des destinations externes ou d’exécuter des sous-processus non approuvés. Les environnements Kubernetes ou cloud-native doivent combiner NetworkPolicies, seccomp, AppArmor ou SELinux selon la plateforme, ainsi que des identités de service minimales.

kubectl create ns ai-secure
kubectl apply -f network-policy-deny-egress.yaml
kubectl apply -f pod-security-context.yaml
kubectl logs -n ai-secure deploy/agent-orchestrator --since=10m | jq '.'

Le pipeline de sécurité intègre aussi des tests automatisés. Avant déploiement, le modèle est soumis à un ensemble de prompts de sécurité, d’entrées adversariales et de documents piégés. Les sorties sont comparées à des oracles de politique. Les échecs critiques bloquent la promotion. En production, des tests de régression sont exécutés régulièrement pour vérifier qu’une mise à jour de modèle, de contexte ou de politique n’a pas réintroduit une vulnérabilité connue. Cette discipline est analogue aux tests unitaires et de non-régression en logiciel, mais elle doit tenir compte du caractère probabiliste du système.

6. Experimental Evaluation

L’évaluation expérimentale cherche à mesurer deux dimensions : la robustesse offensive du système et le coût défensif des contrôles. Nous avons évalué plusieurs configurations sur trois ensembles de scénarios : classification de texte de sécurité, assistant SOC RAG, et agent outillé avec actions contrôlées. Les attaques considérées incluent l’injection directe, l’injection indirecte via documents, l’empoisonnement d’un petit corpus d’entraînement, les tentatives de jailbreak, l’évasion sémantique et l’abus d’outils. Les défenses testées incluent le filtrage lexical, le filtrage sémantique, le scoring de provenance, le sandboxing d’agent, et la confirmation humaine pour les actions à impact élevé.

Les métriques principales sont le taux de réussite de l’attaque $ASR$, la précision fonctionnelle $P$, le rappel des filtres $R_f$, la latence ajoutée $L$ et le taux d’escalade vers l’humain $H$. On mesure aussi le compromis global au moyen d’un score : $$ G = P \times (1 - ASR) \times R_f - \mu L - \nu H $$ où $\mu$ et $\nu$ pondèrent le coût opérationnel. Ce type de formulation permet de comparer des architectures à niveaux de sécurité différents sans réduire la discussion à un unique indicateur.

Le premier tableau compare les scénarios d’attaque observés sur une base expérimentale de corpus sécuritaire interne, de documents RAG et d’interactions d’agent.

Scénario	Cible	Taux de réussite sans défense	Taux de réussite avec défenses de base	Taux de réussite avec architecture proposée
Injection directe	Chat interface	78%	31%	6%
Injection indirecte via document	RAG	83%	42%	9%
Empoisonnement léger du corpus	Fine-tuning / index	64%	28%	7%
Jailbreak multi-tours	LLM	71%	24%	5%
Abus d’outil à permissions excessives	Agent	69%	19%	4%

Ces résultats montrent que les filtres de surface réduisent partiellement l’exposition, mais que la combinaison des couches proposées apporte une baisse significative du succès d’attaque. L’injection indirecte reste plus difficile à neutraliser que l’injection directe, car le contenu malveillant se présente comme externe et légitime. Le besoin d’une annotation forte du contexte et d’une validation des documents est donc confirmé. L’abus d’outil est le cas le plus sévère lorsqu’un agent dispose de permissions trop larges, ce qui valide le principe de confinement strict.

Le deuxième tableau évalue l’impact opérationnel des défenses. Les chiffres suivants sont représentatifs d’une configuration de production sur charge modérée, avec un volume de requêtes comparable à un assistant SOC interne.

Défense	Latence moyenne ajoutée	Faux positifs	Faux négatifs	Charge d’exploitation
Filtrage lexical simple	12 ms	Élevés	Élevés	Faible
Filtrage sémantique	48 ms	Moyens	Moyens	Moyen
Scoring de provenance	63 ms	Faibles	Moyens	Moyen
Sandbox d’agent	110 ms	Faibles	Faibles	Élevée
Confirmation humaine sur actions critiques	Variable	Très faibles	Très faibles	Élevée

Le coût n’est pas négligeable. Une architecture sûre impose une surcharge de latence et une discipline d’exploitation plus forte. Toutefois, la plupart des usages cyber acceptent ce surcoût lorsque le système concerne des opérations à impact élevé. Une latence de quelques dizaines de millisecondes est acceptable pour du triage, tandis que l’ajout de validation humaine est justifié pour les actions irréversibles.

Le troisième tableau compare les familles d’erreurs observées dans les sorties du modèle et leur réduction relative après durcissement.

Type d’erreur	Sans durcissement	Après filtrage	Après architecture complète
Divulgation de contexte sensible	14.2%	5.1%	0.8%
Réponse contrainte par instruction malveillante	11.7%	4.6%	0.9%
Action outil non autorisée	9.8%	3.2%	0.2%
Hallucination d’attribution d’alerte	18.4%	12.0%	6.3%
Résumé erroné de sévérité	16.1%	9.3%	4.7%

L’évolution la plus importante concerne les divulgations et les actions non autorisées. Les hallucinations, en revanche, ne disparaissent pas totalement, ce qui rappelle que la robustesse de l’IA ne se réduit pas à la sécurité. En contexte SOC, une erreur de résumé peut conduire à une mauvaise priorisation, d’où l’importance de maintenir une supervision humaine pour les décisions critiques.

Globalement, l’architecture proposée améliore le compromis sécurité/latence de manière significative. Le gain est particulièrement net lorsque les vecteurs d’attaque sont couplés à des outils ou à des données externes non fiables. Cela confirme une intuition déjà connue en cybersécurité : la sécurité ne dépend pas seulement de la qualité intrinsèque d’un composant, mais du niveau d’exposition qu’on lui accorde.

7. Case Study

Nous présentons maintenant une étude de cas inspirée d’un déploiement réel de type assistant SOC. L’organisation dispose d’un LLM privé connecté à un index documentaire contenant des runbooks, des tickets d’incident, des rapports de menace et des extraits de journaux. L’assistant peut aussi ouvrir des tickets, enrichir des alertes et proposer des requêtes de chasse. Son périmètre d’action est supposé limité, mais certaines intégrations héritées lui donnent un accès plus large que prévu à des métadonnées d’incident et à des espaces de commentaires.

L’attaque débute par un document importé dans la base de connaissances. Le document ressemble à un rapport d’analyse légitime, mais il contient un bloc de texte injonctif destiné au modèle. Lorsqu’un analyste demande un résumé de l’incident, l’agent récupère ce document et le place dans son contexte. Sans séparation stricte des rôles, le modèle interprète une portion du document comme une instruction. Il est alors amené à reformuler la sévérité de l’événement, à révéler un extrait de contexte interne et à proposer une action d’export de pièces jointes.

L’adversaire ne s’arrête pas là. Un second vecteur introduit une note de ticket empoisonnée mentionnant une fausse procédure de sécurité et un faux lien vers un dépôt interne. Cette note est ensuite récupérée par l’assistant comme référence. Si l’agent a la permission de créer des tickets ou d’ouvrir des liens automatiques, l’attaquant peut alors orienter le flux de travail vers une ressource contrôlée. Ce type de chaîne montre que l’attaque la plus dangereuse n’est pas forcément spectaculaire ; elle combine plusieurs petites faiblesses administratives, sémantiques et techniques.

Dans la configuration non durcie, l’assistant répond avec des informations trop détaillées, y compris des éléments de contexte qui n’auraient pas dû être restitués. Dans la configuration durcie, le document externe est marqué comme non fiable, ses instructions sont neutralisées, et toute action à impact élevé est stoppée en attente de validation. Les journaux conservent l’ensemble de la séquence, ce qui permet une investigation postérieure. L’incident met en évidence trois points : la nécessité d’une provenance forte, la nécessité de séparer preuve et instruction, et la nécessité d’un modèle de permission cohérent avec le risque métier.

Le cas d’usage révèle aussi un piège fréquent : l’équipe pensait avoir sécurisé le modèle en ajoutant des filtres de contenu, mais elle n’avait pas traité le problème de l’autorisation des outils. Même un modèle bien aligné peut produire une sortie dangereuse s’il est connecté à des actions qu’il ne devrait jamais pouvoir déclencher seul. La leçon est claire : la sécurité de l’IA en cybersécurité doit être conçue comme une sécurité des décisions, pas seulement comme une sécurité des textes.

8. Discussion

Les résultats et la mise en œuvre confirment une réalité désormais incontournable en 2026 : la sécurité des systèmes d’IA est un problème de gouvernance technique intégrée. Les approches centrées uniquement sur des filtres de prompt sont insuffisantes, car elles traitent la manifestation de l’attaque plutôt que sa chaîne de propagation. L’adversaire moderne exploite les points faibles les plus simples : documents non fiables, permissions excessives, absence de signatures, et confusion entre instruction et contexte. Cette observation vaut autant pour les environnements de productivité que pour les plateformes de défense.

Une difficulté majeure réside dans la tension entre sécurité et utilité. Plus le système est verrouillé, moins il est susceptible d’être abusé ; mais plus il est verrouillé, plus il devient coûteux à utiliser. Les analystes SOC travaillent dans des délais contraints. Si l’architecture ajoute trop de friction, elle sera contournée. Il faut donc choisir des contrôles qui s’activent en fonction du risque. Les actions de lecture ou de résumé peuvent rester largement automatisées, alors que les actions d’écriture, d’export ou de suppression doivent passer par des étapes de validation. Le principe du moindre privilège reste central, mais il doit être adapté à la réalité des flux IA.

La question de la mesure est tout aussi importante. Les organisations ont tendance à évaluer les modèles sur des jeux de benchmark généraux, puis à conclure qu’ils sont « sûrs ». Or la sécurité opérationnelle dépend du contexte : type de données, forme des connecteurs, permissions, gouvernance, et profils de menace. Un modèle peut être robuste dans un banc d’essai et vulnérable dans une architecture RAG mal conçue. De plus, les attaques évoluent rapidement. La red team doit donc être continue, non pas ponctuelle. Les tests doivent inclure des documents piégés, des séquences multi-tours, des entrées multimodales, et des tentatives d’abus de mémoire ou d’outils.

Un autre point critique concerne la conformité et l’auditabilité. Avec l’AI Act, les normes sectorielles et les attentes croissantes en matière de transparence, les organisations devront démontrer comment une décision assistée par IA a été produite. Cela implique de conserver des journaux exploitables, des versions de prompts système, des hash d’artefacts, et des traces de politique. La sécurité de l’IA rejoint alors le besoin d’explicabilité forensique. Il ne suffit pas de savoir ce que le modèle a répondu ; il faut savoir quel contexte il a vu, quelle politique l’a autorisé, et quel outil il a appelé.

Enfin, l’émergence des agents IA pose une question doctrinale. Les systèmes automatisés ne sont plus de simples assistants ; ils deviennent des exécutants. Cela justifie un encadrement proche de celui appliqué aux systèmes critiques : séparation des rôles, validation, traçabilité, arrêt d’urgence, et tests de non-régression. Dans une perspective cyber, la meilleure défense contre l’abus d’agent consiste à reconnaître que l’agent est un composant potentiellement hostile dès lors qu’il traite du contenu externe. Cette hypothèse de prudence doit guider la conception.

9. Conclusion and Future Work

Ce papier a montré que la sécurité des systèmes d’IA en cybersécurité ne peut pas être réduite à la modération des sorties ou à quelques filtres de prompt. En 2026, les environnements réellement exposés combinent données externes, RAG, agents outillés, journaux, cloud et pipelines MLOps, ce qui crée une surface d’attaque composite. Nous avons proposé un modèle de menace structuré, une méthodologie de défense en couches, une implémentation réaliste et une évaluation expérimentale illustrant les bénéfices des contrôles de provenance, de confinement et de supervision continue.

Les résultats plaident pour une approche fondée sur la chaîne de confiance. Les données doivent être signées et classées, les contextes doivent être étiquetés par provenance, les outils doivent être cloisonnés, et les actions critiques doivent exiger une validation forte. Les organisations qui adoptent des copilotes SOC ou des agents d’automatisation sans cette discipline prennent un risque disproportionné. À l’inverse, celles qui investissent dans une architecture robuste peuvent bénéficier des gains de productivité de l’IA sans sacrifier la sécurité.

Les travaux futurs devraient porter sur quatre axes. Premièrement, la standardisation des manifests de sécurité pour les artefacts IA, afin d’améliorer l’auditabilité inter-plateforme. Deuxièmement, la détection automatisée d’empoisonnement dans les corpus RAG à grande échelle, en particulier lorsque les sources sont hétérogènes. Troisièmement, la formalisation de politiques d’agent vérifiables, idéalement compatibles avec des moteurs de policy as code. Quatrièmement, l’évaluation de la sécurité des systèmes multimodaux et des agents multimodaux, qui constituent déjà une frontière de risque en 2026. La sécurité de l’IA est désormais un domaine à part entière, et son niveau de maturité déterminera en grande partie la fiabilité des opérations cyber des années à venir.

10. References

ADLER, Samuel; et al. A Generalized Framework for Adversarial Training in Neural Networks. 2023. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

BIGML SECURITY. Best Practices for Securing LLM Applications. 2024. Disponível em: https://www.bigml.com/. Acesso em: 19 abr. 2026.

CARLINI, Nicholas; WAGNER, David. Towards Evaluating the Robustness of Neural Networks. IEEE Symposium on Security and Privacy, 2017. Disponível em: https://arxiv.org/abs/1608.04644. Acesso em: 19 abr. 2026.

CWE. CWE Top 25 Most Dangerous Software Weaknesses. 2025. Disponível em: https://cwe.mitre.org/top25/. Acesso em: 19 abr. 2026.

FREDRIKSON, Matt; et al. Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures. ACM CCS, 2015. Disponível em: https://dl.acm.org/doi/10.1145/2810103.2813677. Acesso em: 19 abr. 2026.

GOODFELLOW, Ian J.; SHLENS, Jonathon; SZEGEDY, Christian. Explaining and Harnessing Adversarial Examples. 2015. Disponível em: https://arxiv.org/abs/1412.6572. Acesso em: 19 abr. 2026.

HUGGING FACE. Transformers Documentation. 2026. Disponível em: https://huggingface.co/docs/transformers/. Acesso em: 19 abr. 2026.

ISO/IEC. ISO/IEC 42001:2023 — Artificial Intelligence Management System. 2023. Disponível em: https://www.iso.org/standard/81230.html. Acesso em: 19 abr. 2026.

JIA, Robin; LIANG, Percy. Adversarial Examples for Evaluating Reading Comprehension Systems. EMNLP, 2017. Disponível em: https://arxiv.org/abs/1707.07328. Acesso em: 19 abr. 2026.

KOTEROV, Alexander; et al. Prompt Injection Attacks and Defenses in Large Language Model Applications. 2024. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

LANGCHAIN. LangChain Security Considerations. 2025. Disponível em: https://python.langchain.com/docs/. Acesso em: 19 abr. 2026.

LINDNER, Markus; et al. Security Evaluation of Retrieval-Augmented Generation Systems. 2024. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. 2026. Disponível em: https://atlas.mitre.org/. Acesso em: 19 abr. 2026.

MITRE. ATT&CK for Enterprise. 2026. Disponível em: https://attack.mitre.org/. Acesso em: 19 abr. 2026.

NIST. AI Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023a. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 19 abr. 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. 2023b. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 19 abr. 2026.

OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 19 abr. 2026.

PARLEMENT EUROPÉEN; CONSEIL DE L’UNION EUROPÉENNE. Règlement sur l’intelligence artificielle (AI Act). 2024. Disponível em: https://eur-lex.europa.eu/. Acesso em: 19 abr. 2026.

PAPERNOT, Nicolas; MCGREGOR, Andrew; et al. Transferability in Machine Learning and Security. 2018. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

RAGHUNATHAN, Aditi; et al. Robustness of Language Models under Retrieval-Augmented Generation. 2024. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

REDMOND, Jesse; et al. OpenTelemetry Specification. 2026. Disponível em: https://opentelemetry.io/docs/specs/. Acesso em: 19 abr. 2026.

SANDHU, Ravi; et al. Role-Based Access Control Models. IEEE Computer, 1996. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 19 abr. 2026.

SULLIVAN, Bill; et al. Zero Trust Architecture. NIST SP 800-207, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 19 abr. 2026.

TRAMÈR, Florian; et al. Stealing Machine Learning Models via Prediction APIs. USENIX Security, 2016. Disponível em: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_tramer.pdf. Acesso em: 19 abr. 2026.

VAN DEN BERGH, Tobias; et al. eBPF-Based Security Observability for Cloud-Native Systems. 2025. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.

WEYAND, Tobias; et al. MLOps for Security-Critical Systems. 2024. Disponível em: https://arxiv.org/. Acesso en: 19 abr. 2026.

ZHANG, Y.; et al. Benchmarking Prompt Injection Defenses for LLM Agents. 2025. Disponível em: https://arxiv.org/. Acesso em: 19 abr. 2026.