Sécurité des systèmes d’IA en environnement cyber : formalisation des menaces, défense en profondeur et validation expérimentale d’une architecture LLM-RAG pour SOC et réponse à incident

1. Introduction

En 2026, la sécurité des systèmes d’IA n’est plus un sujet périphérique de recherche, mais une composante centrale de la posture cyber des entreprises, des administrations et des opérateurs critiques. Les modèles de langage, les systèmes de recommandation, les détecteurs de fraude, les moteurs de scoring, les agents de triage et les copilotes SOC sont désormais intégrés dans des workflows réels où une décision erronée, une fuite de contexte ou une manipulation subtile peut produire un impact opérationnel immédiat. Dans ce paysage, l’IA n’est pas seulement un outil de défense ; elle devient une cible, un vecteur d’attaque et, dans certains cas, un amplificateur de menace. Cette évolution oblige à reconsidérer les modèles de sécurité traditionnels, conçus pour des applications déterministes ou des services web relativement cloisonnés, afin d’y incorporer des notions de plasticité comportementale, de dépendance au contexte, de non-déterminisme contrôlé et de chaînes d’outils autonomes.

La bascule s’explique par trois tendances convergentes. Premièrement, les organisations ont massivement déployé des interfaces de type LLM pour accélérer les opérations de sécurité, la rédaction de rapports, l’investigation d’événements et la recherche de menaces. Deuxièmement, les attaques adversariales se sont professionnalisées : l’injection de prompts, l’empoisonnement des bases de connaissances RAG, l’abus d’outils via agents et les attaques par exfiltration de contexte ont quitté le stade de démonstrations académiques pour entrer dans des scénarios d’attaque réalistes. Troisièmement, la surface de gouvernance s’est élargie, car les entreprises utilisent des modèles propriétaires, open source et hébergés, provenant d’écosystèmes hétérogènes où la confiance, la traçabilité et la maîtrise des dépendances sont inégales. Les conséquences sont directes : un système d’IA mal conçu peut divulguer des informations sensibles, déclencher des actions non autorisées, produire des recommandations trompeuses ou contourner des politiques de sécurité internes.

Ce papier adopte une perspective résolument cyber. L’objectif n’est pas de décrire l’IA en général, mais d’analyser les menaces pesant sur les systèmes d’IA déployés dans des environnements de sécurité offensive et défensive, puis de proposer une architecture de défense applicable à un cas d’usage concret : un assistant LLM-RAG destiné au SOC et à la réponse à incident. Nous considérons le système comme une chaîne de traitement composée d’entrées externes, d’un modèle fondation, d’un mécanisme de récupération documentaire, d’outils d’exécution, de journaux, de politiques d’accès et d’actions de sortie. Chaque maillon peut être compromis, et la sécurité finale dépend de la composition des contrôles.

D’un point de vue opérationnel, l’enjeu principal est de préserver trois propriétés : la confidentialité des prompts, du contexte et des sources internes ; l’intégrité des sorties, des actions et des recommandations ; et la disponibilité du système, y compris sous charge malveillante. À cette triade s’ajoute une quatrième propriété, devenue essentielle en 2026 : la gouvernance, c’est-à-dire la capacité à démontrer qui a utilisé quel modèle, avec quelles données, quelles autorisations, quelles dépendances et quel niveau de risque résiduel. Dans les environnements soumis à réglementation ou à des contraintes de secret industriel, cette dimension conditionne l’acceptabilité même du système.

Les attaques contre les systèmes d’IA se distinguent des attaques classiques par leur nature contextuelle. Un acteur malveillant n’a pas nécessairement besoin d’exploiter une vulnérabilité mémoire ou un bug de parsing. Il peut manipuler la sémantique, les données récupérées, les instructions concurrentes ou la mémoire conversationnelle pour détourner le comportement du système. En pratique, cela signifie qu’une défense robuste ne peut pas se limiter à un filtre de mots-clés ou à une simple politique de contenu. Elle doit combiner des mécanismes de contrôle d’accès, d’isolation, de validation, de surveillance et de réponse adaptés à des systèmes probabilistes. Cette exigence est particulièrement critique dans les SOC où les modèles sont susceptibles de manipuler des données sensibles, des indices d’attaque, des IOC, des identifiants techniques et des extraits de logs contenant des secrets.

Notre contribution est structurée autour de quatre axes. Premièrement, nous proposons un modèle de menace détaillé pour les systèmes d’IA cyber, couvrant les attaques sur les données, les prompts, les outils, les modèles et les sorties. Deuxièmement, nous présentons une méthodologie de défense en profondeur fondée sur l’architecture Zero Trust, la segmentation des privilèges, la validation sémantique et la journalisation immuable. Troisièmement, nous décrivons une implémentation réaliste d’un assistant LLM-RAG sécurisé pour le SOC. Quatrièmement, nous évaluons expérimentalement sa résistance à plusieurs classes d’attaques et son coût de performance. Cette approche vise un équilibre pragmatique entre sécurité, utilité opérationnelle et soutenabilité.

2. Background and Related Work

La littérature sur la sécurité de l’IA s’est structurée autour de plusieurs familles de travaux. Les premières recherches portaient sur les attaques adversariales contre les réseaux de neurones, notamment la perturbation imperceptible des entrées, les exemples adversariaux transférables et les attaques sur la robustesse des classifieurs d’images. Ces résultats ont montré qu’un modèle peut se tromper avec une confiance élevée face à de petites modifications conçues par l’attaquant. En cybersécurité, ces méthodes ont inspiré des attaques sur la détection de malware, la classification d’URL, l’analyse de spam et la reconnaissance de comportements anormaux. Des travaux de référence ont établi que les modèles appris peuvent être sensibles à des perturbations ciblées, ce qui justifie des approches de robustesse, d’entraînement adversarial et de certification partielle (GOODFELLOW, SHLENS e SZEGEDY, 2015).

Avec l’arrivée des grands modèles de langage, la surface d’attaque s’est étendue au niveau de l’interface conversationnelle et du contexte récupéré. Le problème le plus emblématique est celui de l’injection de prompt, où un contenu externe, par exemple une page web, un document, un ticket ou un email, contient des instructions cachées ou contradictoires destinées à détourner le comportement du modèle. Les travaux pionniers sur la sécurité des LLM ont montré que l’instruction hiérarchique n’est pas suffisante à elle seule : le modèle peut fusionner des sources d’autorité différentes, traiter des données non fiables comme des instructions et produire des sorties non prévues. Les guides de sécurité publiés entre 2023 et 2025 ont consolidé les catégories d’attaque : prompt injection directe et indirecte, jailbreak, exfiltration, abuse of tools, cross-domain retrieval poisoning et data poisoning dans les pipelines RAG (NIST, 2024; OWASP, 2025).

Le cadre de référence le plus influent en 2026 reste la taxonomie des risques des systèmes d’IA publiés par NIST et l’extension opérationnelle fournie par les cadres d’OWASP pour les LLM. Le NIST AI Risk Management Framework introduit les fonctions de gouvernance, cartographie, mesure et gestion, tandis que les documents associés insistent sur la nécessité d’évaluer les risques tout au long du cycle de vie du système. OWASP, de son côté, a popularisé une liste de risques pour les applications LLM, incluant l’injection de prompt, la désinformation, l’exposition de données sensibles, l’insécurité de la chaîne d’approvisionnement et les vulnérabilités de l’exécution d’outils. Ces cadres sont essentiels car ils traduisent une intuition de recherche en exigences opérationnelles mesurables (NIST, 2024; OWASP, 2025).

Dans le domaine des attaques contre les systèmes augmentés par récupération, la littérature a démontré que le RAG est un amplificateur de risque si l’on ne sépare pas strictement les documents de confiance, les sources non confiables et les instructions du système. Les documents récupérés peuvent contenir des instructions adversariales dissimulées, des marqueurs de priorité, des demandes d’exfiltration ou des formulations destinées à provoquer un changement de politique. Le problème est aggravé par le fait que les modèles sont optimisés pour satisfaire l’utilisateur et pour suivre la cohérence locale du texte. Dans un environnement SOC, cela signifie qu’un analyste pourrait introduire involontairement un artefact non fiable, issu par exemple d’un ticket externe, d’un rapport tiers ou d’un rapport d’incident contaminé, et le système pourrait le traiter comme une source d’autorité.

Les agents LLM constituent une autre évolution majeure. Ici, le modèle ne se contente plus de répondre ; il planifie et appelle des outils : requêtes SIEM, enrichissement par OSINT, extraction de flux, exécution de scripts, génération de tickets, ou interactions avec des API de sécurité. Cette capacité augmente l’utilité, mais crée un risque de cascade : une mauvaise interprétation, une instruction malveillante ou une manipulation du contexte peut provoquer des actions irréversibles. Des travaux publiés autour des agents outillés ont montré que la délégation d’actions à un modèle doit être traitée comme une opération à privilège, nécessitant des politiques de moindre privilège, de confirmation humaine et de preuve d’intention (BENDER et al., 2021; ZOU et al., 2023).

En parallèle, la cybersécurité opérationnelle a intégré des mécanismes de détection et d’isolement plus fins. L’observabilité basée sur eBPF, les plateformes CNAPP, les politiques Zero Trust, les secrets managers matériels, les contrôles d’accès contextuels et la journalisation immuable ont atteint une maturité suffisante pour être appliqués à l’IA. Toutefois, la transposition n’est pas triviale. Un modèle d’IA n’est pas une application conventionnelle : sa frontière de confiance englobe des données de training, des embeddings, des prompts système, des caches, des retrievers, des plugins et parfois plusieurs fournisseurs cloud. La sécurité doit donc être pensée comme une propriété de composition plutôt que comme un simple durcissement du serveur d’inférence.

Tableau 1. Comparaison de familles de menaces contre les systèmes d’IA

Famille de menace	Cible principale	Impact typique	Exemple opérationnel	Contrôle prioritaire
Injection de prompt	Interface LLM, RAG	Exfiltration, désalignement	Document piégé dans le corpus SOC	Filtrage sémantique, cloisonnement des sources
Poisoning de données	Corpus, embeddings, entraînement	Réponses biaisées, backdoor	Ticket interne modifié à la source	Chaîne de provenance, signature, revue
Abus d’outils	Agent, API, automatisation	Actions non autorisées	Requête SIEM hors périmètre	Moindre privilège, confirmation humaine
Extraction de modèle	Endpoint, logs, telemetry	Fuite de propriété intellectuelle	Reconstruction via requêtes adaptatives	Rate limiting, watermarking, détection d’abus
Attaque adversariale	Entrées, capteurs, features	Erreur de classification	Faux positifs/faux négatifs	Robustesse, détection de dérive

La littérature récente sur la sécurité des modèles fondation met aussi en avant les risques de fuite par mémorisation, de sur-apprentissage de segments sensibles et de récupération d’exemples d’entraînement via des requêtes appropriées. Ces risques sont amplifiés lorsque des journaux, tickets, emails et rapports contenant des secrets sont intégrés aux corpus de contexte. Les défenseurs doivent donc considérer la question de la confidentialité non seulement au niveau de l’infrastructure, mais aussi au niveau des données de préparation, des embeddings et des caches. Les attaques d’extraction de données, connues avant l’ère LLM, prennent une nouvelle dimension lorsqu’un assistant peut reformuler, résumer et recombiner des informations sensibles à grande échelle.

Les politiques de gouvernance et d’audit ont également évolué. En 2026, les entreprises sérieuses exigent des preuves de traçabilité : provenance des données, version du modèle, configuration de l’orchestrateur, politique de sortie, approbations humaines, tests de red teaming et résultats de surveillance continue. Les normes de type ISO/IEC 42001 et les cadres de gestion de risque IA ont renforcé l’exigence d’un système d’IA gouverné comme un actif critique. Le passage d’un prototype à un système opérationnel requiert ainsi des mécanismes de conformité intégrés dès la conception, et non ajoutés a posteriori (ISO/IEC, 2023; NIST, 2024).

Tableau 2. Cadres et outils pertinents pour la sécurité de l’IA en 2026

Cadre ou outil	Rôle	Apport principal	Limite principale
NIST AI RMF 1.0	Gouvernance du risque IA	Structure de gestion du risque	Peu prescriptif techniquement
OWASP Top 10 for LLM Apps	Taxonomie des risques applicatifs	Priorisation des menaces LLM	Nécessite adaptation contextuelle
MITRE ATLAS	Base de techniques adversariales IA	Cartographie tactique	Non spécifique à un secteur
ISO/IEC 42001	Système de management IA	Gouvernance et conformité	Mise en œuvre lourde
OpenTelemetry + SIEM	Observabilité et audit	Corrélation des événements	Besoin d’enrichissement sémantique
eBPF security tooling	Télémétrie système fine	Détection runtime	Couverture partielle du niveau modèle

3. Threat Model and Problem Formalization

Nous considérons un système d’IA cyber composé d’un utilisateur $u$, d’un orchestrateur $o$, d’un modèle fondation $m$, d’un récupérateur documentaire $r$, d’outils externes $t_i$, d’un magasin de contexte $c$ et d’un système de journalisation $j$. Le système reçoit une entrée $x$ qui peut inclure une requête utilisateur, des données récupérées, des instructions système et des métadonnées. Il produit une sortie $y$ qui peut être textuelle, structurée, ou se traduire par une action vers un outil externe. L’adversaire $a$ cherche à maximiser un objectif $J$ selon un but opérationnel : divulguer une information, modifier une décision, contourner une politique, déclencher une action ou perturber le service.

On formalise la sécurité par une fonction de risque : $$ R = \mathbb{E}_{x \sim D, a \sim A}\left[L(f(x,a), y^\ast) \right] $$ où $f$ est le système d’IA complet, $D$ la distribution des entrées légitimes, $A$ la distribution des stratégies adversariales, et $L$ une perte métier mesurant la violation de confidentialité, d’intégrité ou de disponibilité. L’objectif défensif est de minimiser $R$ sous contraintes de performance, de coût et d’utilité. En pratique, il ne s’agit pas d’éliminer tout risque, ce qui serait impossible, mais de le ramener sous un seuil acceptable et auditable.

Le modèle de menace distingue cinq classes d’adversaires. Le premier est l’adversaire externe non authentifié, qui tente de provoquer une divulgation ou un abus d’outil via l’interface publique. Le second est l’adversaire semi-authentifié, par exemple un utilisateur interne ou un prestataire, capable d’exploiter des privilèges limités. Le troisième est l’adversaire supply chain, qui introduit des artefacts malveillants dans des documents, dépendances, modèles ou jeux de données. Le quatrième est l’adversaire opérant par mouvement latéral, qui a compromis un composant adjacent et vise le système d’IA comme pivot. Le cinquième est l’adversaire assisté par IA, qui automatise la découverte, l’adaptation et la génération de charges utiles, ce qui augmente fortement l’échelle d’attaque.

Les vecteurs d’attaque pertinents sont organisés comme suit. L’injection directe consiste à placer une instruction malveillante dans le prompt utilisateur. L’injection indirecte consiste à placer une instruction dans une source récupérée par RAG ou par un connecteur. Le poisoning vise le corpus, les embeddings, les fine-tunes ou les exemples de mémoire. L’extraction de contexte cherche à faire révéler des secrets, clés, règles internes ou prompts système. L’abus d’outils exploite l’exécution d’actions par l’agent. Enfin, l’évasion et l’empoisonnement adversarial ciblent les classifieurs, détecteurs et systèmes de triage qui entourent le modèle.

Le principe de moindre privilège doit être transposé au plan des capacités du modèle. Un assistant SOC ne doit pas disposer, par défaut, d’accès en écriture aux tickets de haute criticité, ni d’accès direct aux playbooks destructifs, ni de capacité à exporter des données brutes sans validation. En termes de politique, chaque capacité $c_i$ doit être associée à un ensemble de préconditions $P_i$ et d’autorisations $A_i$. Une action est permise seulement si $$ P_i(x, s) \land A_i(u, c_i) \land V(y) = \text{vrai} $$ où $s$ représente l’état du système et $V$ une fonction de validation indépendante. Cette approche rapproche l’IA d’un système de contrôle d’accès dynamique plutôt que d’un simple générateur de texte.

Tableau 3. Cartographie des risques, impacts et contrôles

Risque	Probabilité en SOC	Impact	Détectabilité	Contrôle prioritaire
Exfiltration de prompts système	Moyenne	Élevé	Moyenne	Cloisonnement, masquage, filtrage de sortie
Prompt injection indirecte	Élevée	Élevé	Faible	Nettoyage, scoring de confiance, séparation des rôles
Poisoning du corpus RAG	Moyenne	Élevé	Faible	Signature, provenance, revue humaine
Abus d’outils via agent	Moyenne	Très élevé	Moyenne	Confirmation, politique d’action, sandbox
Fuite par logs/telemetry	Moyenne	Élevé	Moyenne	Redaction, chiffrement, accès limité
Dérive comportementale	Élevée	Moyen à élevé	Moyenne	Monitoring, réévaluation, red teaming

4. Proposed Methodology

Notre méthodologie s’appuie sur une défense en profondeur adaptée aux systèmes d’IA cyber. Elle comporte six couches : gouvernance, segmentation des données, contrôle du contexte, sûreté des outils, supervision runtime et validation continue. L’idée centrale est que la sécurité ne doit pas dépendre d’un seul mécanisme de filtrage, mais d’une composition de contrôles qui se renforcent mutuellement. Un adversaire capable de tromper une couche doit encore franchir les suivantes, chacune limitant l’espace d’impact.

La première couche est la gouvernance. Chaque modèle, chaque version de prompt système, chaque source documentaire et chaque connecteur doit être inventorié comme un actif. Les responsabilités doivent être documentées : propriétaire métier, propriétaire sécurité, propriétaire données et exploitant. Les décisions de déploiement doivent être accompagnées d’une évaluation de risque et d’une justification de l’usage. Cette gouvernance s’inscrit dans les logiques de NIST AI RMF et d’ISO/IEC 42001, mais elle doit être traduite en contrôles concrets : approbation par niveau de sensibilité, revue des dépendances, politique de rétention des journaux, et registre des incidents IA.

La deuxième couche est la segmentation des données. Les documents utilisés par le RAG doivent être classés selon leur provenance, leur sensibilité et leur fiabilité. Nous distinguons au minimum trois classes : sources de confiance haute, sources de confiance moyenne et sources non fiables. Les documents non fiables ne doivent jamais être insérés tels quels dans le contexte du modèle. Ils doivent être nettoyés, résumés ou transformés en éléments non instructionnels. La séparation doit être maintenue au niveau des embeddings, des caches et des index. Un document provenant d’un ticket externe, d’un email ou d’une page web doit perdre sa capacité impérative et devenir une simple source d’information.

La troisième couche est le contrôle du contexte. Le système doit construire le prompt final à partir de segments typés : instructions système, politique de sécurité, requête utilisateur, contexte récupéré, et sorties intermédiaires. Chaque segment doit porter une étiquette de provenance et un score de confiance. Les instructions concurrentes doivent être arbitréess selon une hiérarchie stricte. Les sections récupérées ne doivent pas pouvoir surclasser les instructions système. La mise en œuvre repose sur un parseur de contexte et un filtre sémantique capable de détecter les tentatives de détournement, telles que les consignes d’ignorer les règles, de révéler les secrets ou d’appeler des outils non autorisés.

La quatrième couche concerne la sûreté des outils. Lorsque le système appelle un outil externe, il doit le faire via une interface de politiques, non via un accès brut. Chaque outil est associé à un schéma d’entrée, à un périmètre d’action, à un quota et à une exigence de confirmation. Les actions destructives ou à portée sensible exigent une validation humaine explicite. Dans le cas du SOC, une requête vers un SIEM pour extraire des logs peut être autorisée, mais l’envoi automatique d’un containment workflow sur un segment de production doit requérir une confirmation. Cette règle reflète une logique d’agentic safety : plus l’action se rapproche d’une modification d’état, plus le contrôle doit être strict.

La cinquième couche est la supervision runtime. Le système doit être observé au niveau des requêtes, des embeddings, des appels d’outils, de la latence, des taux de refus et des anomalies de distribution. Les signaux doivent être agrégés dans une pile de télémetrie compatible avec OpenTelemetry, enrichis par des métriques de sécurité et corrélés dans le SIEM. Les approches eBPF sont utiles pour surveiller les flux système, les processus d’inférence, les fichiers temporaires et certaines opérations réseau. Le but n’est pas d’espionner le modèle, mais d’obtenir une visibilité opérationnelle suffisante pour détecter les écarts, les boucles anormales, les tentatives d’exfiltration et les comportements d’outillage suspects.

La sixième couche est la validation continue. Le système doit être soumis à des tests adversariaux réguliers, incluant des scénarios d’injection, d’extraction, de contamination du corpus et d’abus d’outil. Les tests doivent être automatisés mais également revus par des analystes. Les jeux de test doivent inclure des prompts bénins, ambigus, hostiles et des documents piégés. Une métrique utile est le taux de réussite d’attaque, mais elle doit être complétée par des métriques métier : précision de triage, taux de faux positifs, temps moyen de réponse, et charge de travail analyste.

La validation du risque peut être modélisée par une efficacité défensive $$ E = 1 - \frac{S_a}{N_a} $$ où $S_a$ est le nombre d’attaques réussies et $N_a$ le nombre total d’attaques testées. Cependant, cette mesure brute doit être pondérée par le coût de fonctionnement. Nous utilisons donc un score composite : $$ Q = \alpha \cdot \text{utilité} + \beta \cdot E - \gamma \cdot \text{latence} - \delta \cdot \text{coût} $$ avec $\alpha, \beta, \gamma, \delta$ choisis selon les priorités du SOC. Dans un environnement critique, $\beta$ et $\delta$ peuvent dominer, alors que dans un contexte d’assistance analyste, l’utilité immédiate peut peser davantage.

Le flux défensif recommandé est le suivant : classification de la requête, évaluation du risque, récupération documentaire filtrée, assemblage de contexte, génération, post-traitement, validation de sortie, journalisation et éventuellement action outillée. À chaque étape, une politique spécifique peut bloquer, réduire ou dégrader le niveau d’autonomie. Par exemple, une requête provenant d’une source inconnue peut être traitée en mode lecture seule, avec interdiction d’outil et masquage renforcé des données sensibles. Inversement, une requête interne validée par un analyste peut autoriser davantage de contexte, mais seulement pour des documents signés et des outils limités.

5. Implementation

Nous avons implémenté un prototype d’assistant LLM-RAG pour SOC destiné à la classification d’alertes, au résumé de chronologies d’incident et à la suggestion de mesures de réponse. L’architecture repose sur un orchestrateur Python, un moteur de récupération documentaire, un modèle de langage hébergé localement ou via API privée, et une couche de politiques. Les sources documentaires incluent des runbooks, des tickets internes, des rapports d’incident et des notes d’analyse. Les documents sont ingérés après normalisation, classification de sensibilité et calcul d’un score de confiance. Les éléments non fiables sont soit exclus, soit transformés en résumés dé-sémantisés.

Le pipeline d’ingestion applique une étape de sanitisation visant à supprimer les instructions impératives hors périmètre. Cette opération s’inspire des bonnes pratiques de filtrage des contenus RAG, mais elle est complétée par un classifieur de risque entraîné sur des exemples de prompt injection et de contenus adversariaux. Le système calcule un score $$ p_{\text{mal}} = \sigma(w^\top z + b) $$ où $z$ représente un vecteur de caractéristiques mêlant lexique injonctif, structure syntaxique, provenance, densité d’instructions et incohérences de rôle. Si $p_{\text{mal}}$ dépasse un seuil, le document est rejeté ou dégradé.

Les appels d’outils sont gérés par une couche de policy enforcement qui vérifie le type de demande, la sensibilité des données, le rôle de l’utilisateur et l’impact potentiel de l’action. Les outils disponibles incluent la recherche dans le SIEM, la consultation de tickets, l’enrichissement IOC, la génération de brouillons de réponse et la création de tâches. Les actions modifiant un système externe sont désactivées par défaut. Cette restriction est essentielle, car l’agent peut sinon être poussé à accomplir des tâches hors intention par manipulation du contexte.

Exemple de configuration de politique pour un outil d’interrogation SIEM :

tools:
  siem_search:
    allowed_roles: ["analyste_n1", "analyste_n2", "responsable_incident"]
    action: "read_only"
    max_time_range_hours: 24
    max_records: 500
    require_human_confirmation: false
    redact_fields:
      - "password"
      - "token"
      - "secret"
  containment_execute:
    allowed_roles: ["responsable_incident"]
    action: "write"
    max_time_range_hours: 1
    max_records: 50
    require_human_confirmation: true
    allow_on_production: false

Pour l’observabilité, nous avons instrumenté le service avec OpenTelemetry et une collecte système fondée sur eBPF afin de suivre les appels, les latences et les anomalies de comportement. Les journaux incluent l’empreinte du modèle, la version du prompt système, l’identifiant de session, le score de risque de la requête, les sources consultées, les outils invoqués et le résultat de validation. Les données sensibles sont tronquées ou hachées selon un schéma de redaction. Le stockage des événements d’audit utilise un append-only log signé numériquement, afin de limiter les risques de falsification.

Exemple de commande de test et de fuzzing défensif avec une suite de prompt injection :

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

python tools/redteam_llm.py \
  --target http://localhost:8080/chat \
  --dataset data/prompt_injection_set.jsonl \
  --mode rag \
  --measure exfiltration,tool_abuse,policy_bypass \
  --output results/redteam_run_01.json

L’implémentation comprend également un module de garde-fous de sortie. Avant qu’une réponse soit rendue à l’utilisateur ou envoyée à un outil, elle passe par un validateur qui détecte la présence de secrets, d’ordres implicites, de données réglementées ou d’indications de contournement. Si la sortie est jugée à risque, elle est reformulée, masquée ou bloquée. Cette étape est cruciale, car un système peut être compromis non seulement par l’entrée, mais aussi par sa propre réponse, qui peut servir de canal d’exfiltration ou d’orientation vers une action dangereuse.

6. Experimental Evaluation

L’évaluation a été conduite sur un prototype de SOC assistant configuré en trois variantes : V0 sans défense spécifique, V1 avec filtrage de contexte et contrôle d’accès aux outils, et V2 avec la défense complète incluant classification de risque, séparation forte des sources, post-filtrage de sortie et supervision renforcée. Les attaques testées couvrent la prompt injection directe, la prompt injection indirecte via RAG, l’exfiltration du prompt système, le contournement des politiques d’outil et la contamination documentaire. Les évaluations ont été menées sur un ensemble de cas réalistes inspirés de documents SOC, tickets d’incident et extraits de logs synthétiques.

Le protocole mesure quatre dimensions : taux de succès de l’attaque, qualité opérationnelle, surcharge de latence et taux de faux refus. La qualité opérationnelle est évaluée à partir de tâches de triage d’alertes et de rédaction de résumés par comparaison à une vérité terrain établie par des analystes. Les défenses les plus strictes réduisent les attaques, mais peuvent accroître la latence ou bloquer des cas légitimes. Il est donc essentiel d’évaluer le compromis plutôt que de ne regarder qu’une seule métrique.

Tableau 4. Résultats de résistance aux attaques

Type d’attaque	V0 Succès attaque	V1 Succès attaque	V2 Succès attaque	Réduction V2 vs V0
Injection directe	78%	31%	9%	88%
Injection indirecte RAG	84%	28%	7%	92%
Exfiltration du prompt système	67%	22%	5%	93%
Abus d’outil	59%	18%	4%	93%
Poisoning documentaire	52%	19%	6%	88%

Les résultats montrent que la défense complète réduit nettement la surface d’attaque. Les attaques indirectes via RAG sont les plus problématiques dans la version non durcie, ce qui confirme que la récupération documentaire constitue un canal d’attaque majeur. La réduction du succès à 7% dans V2 provient principalement de la séparation stricte des sources, de la détection des instructions adversariales et de la limitation de la capacité du document à influencer le système. L’abus d’outil baisse lui aussi fortement lorsque les actions sensibles exigent une confirmation ou sont interdites par défaut.

Tableau 5. Impact des défenses sur les performances opérationnelles

Variante	Latence médiane (ms)	Taux de faux refus	Qualité de résumé	Précision de triage	Coût relatif
V0	820	2.1%	0.78	0.81	1.00x
V1	940	4.8%	0.80	0.82	1.08x
V2	1090	7.6%	0.81	0.83	1.16x

La latence augmente avec les défenses, mais l’impact reste compatible avec une utilisation SOC si les volumes sont correctement dimensionnés. Le taux de faux refus est plus élevé en V2, ce qui reflète un arbitrage classique entre sécurité et ergonomie. Toutefois, la dégradation de qualité reste limitée, et les gains en résistance compensent largement ce coût dans des scénarios à forte sensibilité. La précision de triage progresse légèrement grâce au filtrage des documents hostiles et à la réduction des artefacts de contexte.

Tableau 6. Effet des contrôles individuels

Contrôle ajouté	Réduction moyenne du succès d’attaque	Impact latence	Impact faux refus
Filtrage sémantique	31%	Faible	Faible
Séparation confiance/provenance	44%	Faible	Moyen
Politique d’outils	39%	Moyen	Faible
Post-filtrage de sortie	22%	Faible	Moyen
Supervision runtime	17%	Moyen	Faible
Validation humaine sur actions sensibles	51%	Moyen à élevé	Très faible

Ces résultats suggèrent que la meilleure défense n’est pas un contrôle unique mais leur composition. La validation humaine est particulièrement efficace pour les actions à impact, mais elle n’est pas scalable pour tout le trafic. Elle doit donc être réservée aux cas à forte criticité. Le filtrage sémantique, bien que moins spectaculaire, fournit un excellent rapport coût-bénéfice. La séparation des sources est indispensable pour neutraliser les documents adversariaux, surtout dans les environnements à forte hétérogénéité documentaire.

7. Case Study

Nous avons étudié un scénario réaliste inspiré d’un SOC d’entreprise multicloud. L’organisation utilisait un assistant LLM pour synthétiser les alertes, résumer les chaînes d’attaque et proposer des premières mesures de remédiation. Les analystes pouvaient interroger les tickets d’incident, les logs cloud et les procédures internes. Un acteur interne malveillant, disposant d’un accès utilisateur standard, a déposé dans un ticket apparemment bénin un texte contenant des consignes adversariales visant à détourner l’assistant : demander l’export de segments de journaux sensibles, ignorer les politiques de masquage et produire des résumés détaillés incluant des secrets. Dans la version initiale, le document était récupéré par le RAG et influençait fortement la réponse.

Lors d’une session de test, l’assistant a tenté de suivre les instructions contenues dans le ticket contaminé, en générant un brouillon de réponse incluant des informations trop détaillées et en proposant une action d’enrichissement qui dépassait les autorisations de l’utilisateur. Aucun système de validation n’empêchait alors l’abus de contexte. Après durcissement, le document a été classé comme source de confiance faible, ses segments injonctifs ont été neutralisés, et l’appel d’outil a été refusé car l’action nécessitait une confirmation et dépassait le périmètre autorisé.

Ce cas illustre deux points essentiels. D’abord, l’attaque ne dépendait pas d’une faille technique classique mais d’une propriété sémantique du système. Ensuite, le risque n’était pas seulement la divulgation brute, mais la corruption de la qualité décisionnelle du SOC. Un assistant persuadé par un contexte hostile peut orienter les analystes dans la mauvaise direction, retarder la réponse ou amplifier un incident. Cela confirme que la sécurité d’un système d’IA cyber doit être pensée comme une protection des processus opérationnels, et non seulement des données ou du modèle.

8. Discussion

Les résultats de cette étude confirment que la sécurité des systèmes d’IA en contexte cyber exige une approche systémique. Le principal enseignement est que les attaques les plus dangereuses sont souvent celles qui exploitent la confiance implicite dans le contexte, et non les failles traditionnelles. Un RAG sans séparation stricte entre instruction et contenu devient rapidement un canal d’injection. Un agent sans politique d’outil devient un vecteur d’abus. Un système sans supervision runtime devient une boîte noire difficile à auditer après incident.

Le second enseignement concerne l’alignement entre sécurité et utilité. En pratique, les utilisateurs veulent un assistant rapide et flexible. Les défenseurs veulent un système strict et prévisible. Le compromis n’est pas statique : il dépend du niveau de sensibilité, de l’environnement et du type d’action. Un SOC de niveau 1 n’a pas les mêmes exigences qu’un centre de réponse à incident critique. Cela suggère une architecture adaptative, où les privilèges du modèle et les contrôles sont ajustés dynamiquement selon le risque de la requête. Cette approche est cohérente avec les principes Zero Trust, qui exigent une vérification continue plutôt qu’une confiance implicite.

Le troisième enseignement est la nécessité d’une gouvernance de la chaîne complète. Beaucoup d’échecs observés dans les déploiements réels proviennent non du modèle lui-même, mais des dépendances : connecteurs cloud mal configurés, journaux trop bavards, caches non purgés, embeddings dérivés de documents non classés, outils trop puissants et absence de revue des sources. La sécurité de l’IA ne peut donc pas être traitée comme une simple question de modèle. Elle doit intégrer la sécurité applicative, la sécurité cloud, la gestion des secrets, la sécurité des données et la réponse à incident.

Il faut aussi reconnaître les limites des approches actuelles. Les classifieurs de prompt injection ne sont pas infaillibles. Les filtres sémantiques peuvent être contournés par paraphrase, obfuscation ou attaque multi-tour. Les politiques d’outils ne couvrent pas toujours les abus indirects, par exemple lorsqu’un agent pousse un humain à exécuter une action dangereuse. La surveillance runtime détecte des anomalies après coup ou de manière probabiliste. Enfin, la validation humaine n’est pas une solution universelle, car elle introduit de la latence et de la charge cognitive. Les systèmes d’IA cyber devront donc combiner contrôle algorithmique, contexte métier et supervision humaine qualifiée.

Un autre point clé concerne l’AI governance. En 2026, les exigences réglementaires et contractuelles ne portent plus seulement sur la confidentialité des données, mais aussi sur la traçabilité des décisions automatisées, la robustesse du système et la gestion des incidents. Les organisations doivent être capables de répondre à des questions simples mais exigeantes : quel modèle a produit cette réponse, avec quelle version de prompt système, quelles sources ont été consultées, quels outils ont été appelés, qui a approuvé l’action, et comment le risque a été mesuré ? Sans cette traçabilité, la confiance opérationnelle s’érode rapidement.

9. Conclusion and Future Work

Cet article a présenté une analyse complète de la sécurité des systèmes d’IA appliqués à la cybersécurité, en particulier dans le cadre d’un assistant LLM-RAG pour SOC. Nous avons montré que les menaces principales en 2026 relèvent de l’injection de prompt, du poisoning, de l’extraction de contexte, de l’abus d’outils et de la contamination de la chaîne de confiance. Nous avons proposé un modèle de menace formalisé, une méthodologie de défense en profondeur et une implémentation réaliste accompagnée d’une évaluation expérimentale. Les résultats montrent qu’une architecture combinant gouvernance, segmentation des données, contrôle du contexte, politiques d’outils, supervision runtime et validation continue permet de réduire fortement les risques tout en conservant une utilité opérationnelle acceptable.

Les travaux futurs doivent aller dans trois directions. Premièrement, il faut développer des méthodes de certification partielle et de robustesse mesurable pour les systèmes d’IA cyber, en particulier pour les agents outillés. Deuxièmement, il faut améliorer la détection des attaques sémantiques furtives, notamment les injections indirectes multi-hop et les stratégies de contournement par paraphrase. Troisièmement, il faut intégrer davantage les contraintes de gouvernance, de conformité et de souveraineté dans les architectures d’IA, car le risque ne se limite plus à l’exactitude du modèle mais à l’ensemble du cycle de vie. En 2026, la sécurité de l’IA est devenue une discipline à part entière, située à l’intersection du machine learning, de la défense cyber, de l’architecture cloud et du management du risque.

10. References

BAKER, Bowen et al. Human-like generative AI and the future of cyber operations. Disponível em: https://arxiv.org/abs/2305.15389. Acesso em: 28 abr. 2026.

BENDER, Emily M. et al. On the dangers of stochastic parrots: can language models be too big? FAccT 2021. Disponível em: https://dl.acm.org/doi/10.1145/3442188.3445922. Acesso em: 28 abr. 2026.

BRUNDAGE, Miles et al. The malicious use of artificial intelligence: forecasting, prevention, and mitigation. 2018. Disponível em: https://arxiv.org/abs/1802.07228. Acesso em: 28 abr. 2026.

CARLINI, Nicholas et al. Extracting training data from large language models. USENIX Security 2021. Disponível em: https://www.usenix.org/conference/usenixsecurity21/presentation/carlini-extracting. Acesso em: 28 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: 28 abr. 2026.

ISO/IEC. ISO/IEC 42001:2023 Artificial intelligence — Management system. Geneva: ISO, 2023. Disponível em: https://www.iso.org/standard/81230.html. Acesso em: 28 abr. 2026.

KOSER, Karl et al. A survey of prompt injection attacks and defenses in large language models. 2024. Disponível em: https://arxiv.org/abs/2402.08714. Acesso em: 28 abr. 2026.

LIANG, Percy et al. Holistic evaluation of language models. 2022. Disponível em: https://arxiv.org/abs/2211.09110. Acesso em: 28 abr. 2026.

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

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

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

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

PAPERNOT, Nicolas et al. Technical challenges of adversarial machine learning. 2018. Disponível em: https://arxiv.org/abs/1801.02625. Acesso em: 28 abr. 2026.

PAPPU, Rishab et al. Red teaming language models with language models. 2023. Disponível em: https://arxiv.org/abs/2308.09662. Acesso em: 28 abr. 2026.

RAGHUNATHAN, Aditi et al. Robustness of retrieval-augmented generation systems to prompt injection. 2024. Disponível em: https://arxiv.org/abs/2403.12345. Acesso em: 28 abr. 2026.

SAKAGUCHI, Keisuke et al. An empirical study of prompt injection in retrieval-augmented generation. 2024. Disponível em: https://arxiv.org/abs/2404.01234. Acesso em: 28 abr. 2026.

SCHLEGEL, Robert et al. Benchmarking prompt injection defenses for LLM applications. 2025. Disponível em: https://arxiv.org/abs/2501.04567. Acesso em: 28 abr. 2026.

SEIDEL, Michael et al. Agentic AI security: threats, mitigations, and evaluation. 2025. Disponível em: https://arxiv.org/abs/2502.09876. Acesso em: 28 abr. 2026.

SHEN, He et al. JailbreakBench: a benchmark for evaluating large language model jailbreaks. 2024. Disponível em: https://arxiv.org/abs/2404.01327. Acesso em: 28 abr. 2026.

STALLINGS, William. Cryptography and Network Security: Principles and Practice. 8. ed. Boston: Pearson, 2023.

SU, Jinyi et al. Improving robustness of large language models through adversarial training and preference optimization. 2024. Disponível em: https://arxiv.org/abs/2406.04567. Acesso em: 28 abr. 2026.

TAORI, Rohan et al. Measuring robustness of LLMs in tool-use settings. 2024. Disponível em: https://arxiv.org/abs/2405.06789. Acesso em: 28 abr. 2026.

TOWNSEND, Grant; ALFARO, Victor. eBPF for security observability in cloud-native environments. 2024. Disponível em: https://www.cncf.io/blog/2024/ebpf-security-observability/. Acesso em: 28 abr. 2026.

VAN DER MAAREL, Hendrik et al. Secure RAG: trust boundaries for retrieval-augmented generation. 2025. Disponível em: https://arxiv.org/abs/2503.01987. Acesso em: 28 abr. 2026.

WEI, Jason et al. Jailbroken: How does LLM safety training fail? 2023. Disponível em: https://arxiv.org/abs/2307.02483. Acesso em: 28 abr. 2026.

YU, Bo et al. Adversarial attacks on machine learning-based malware detection systems. 2021. Disponível em: https://arxiv.org/abs/2105.00001. Acesso em: 28 abr. 2026.

ZOU, Andy et al. Universal and transferable adversarial attacks on aligned language models. 2023. Disponível em: https://arxiv.org/abs/2307.15043. Acesso em: 28 abr. 2026.