Sécurisation des systèmes d’IA en contexte cyber en 2026 : modèle de menace, défenses multi-couches et évaluation expérimentale d’une chaîne LLM-agentique

1. Introduction

L’année 2026 marque une bascule nette dans la manière dont les organisations doivent penser la cybersécurité. L’intelligence artificielle n’est plus seulement un outil d’assistance ou d’automatisation périphérique, mais un composant structurel des chaînes de décision, de production de code, de support client, de recherche documentaire, de qualification d’alertes et de prise d’action automatisée. Cette mutation a eu un effet direct sur la surface d’attaque. Là où les systèmes classiques exposaient principalement des API, des interfaces web et des endpoints réseau, les systèmes d’IA exposent désormais des interfaces conversationnelles, des magasins vectoriels, des pipelines d’entraînement, des mémoires d’agents, des fonctions outillées et des chaînes de données hybrides intégrant textes, documents, images, audio et métadonnées. En pratique, cela signifie qu’un attaquant peut viser non seulement l’infrastructure, mais aussi la logique d’inférence, la perception du contexte, la sélection des sources et la politique d’exécution des outils.

Ce changement de paradigme a créé un écart entre les programmes de sécurité traditionnels et les besoins réels. Les contrôles classiques de type WAF, EDR, IAM ou DLP restent nécessaires, mais ils sont insuffisants à eux seuls. Une injection de prompt réussie peut obtenir d’un agent qu’il divulgue une information sensible, qu’il invoque un outil à mauvais escient, ou qu’il écrive du code dangereux dans un dépôt. Un empoisonnement de corpus RAG peut altérer la base de connaissances et orienter durablement les réponses vers un contenu frauduleux. Une extraction de modèle peut révéler la logique comportementale, les garde-fous ou des morceaux de données d’entraînement sensibles. Enfin, l’intégration d’agents LLM à des systèmes d’entreprise peut transformer une faiblesse logicielle mineure en incident majeur si l’agent dispose d’un accès élargi à des systèmes de production.

La sécurité de l’IA ne peut donc plus être traitée comme une spécialité isolée du machine learning. En 2026, elle relève d’un espace de convergence entre cybersécurité offensive, ingénierie des données, gouvernance, sécurité cloud, cryptographie appliquée et sûreté des systèmes autonomes. Cette convergence a été accélérée par trois tendances. Premièrement, la généralisation des architectures RAG a multiplié les points d’entrée via des documents non fiables, des index vectoriels et des connecteurs SaaS. Deuxièmement, l’essor des agents outillés a créé des chaînes d’action conditionnelles où la décision du modèle déclenche des opérations réelles, parfois irréversibles. Troisièmement, l’utilisation de modèles plus puissants a amplifié les effets des attaques de manipulation contextuelle, notamment parce que les attaquants savent désormais concevoir des payloads qui exploitent les biais de priorisation, les fenêtres de contexte, la segmentation des instructions et les politiques de récupération de mémoire.

Cet article vise à produire une analyse à la fois académique et opérationnelle. Nous ne nous limitons pas à énumérer des catégories de menaces ; nous construisons un modèle de menace exploitable, puis une méthodologie défensive orientée déploiement. L’objectif est de répondre à des questions concrètes : comment réduire le risque d’injection de prompt sans dégrader excessivement l’utilité du système ? Comment empêcher un agent de transformer une suggestion textuelle en action dangereuse ? Comment tracer, corréler et auditer les décisions d’un pipeline IA dans un SOC ? Comment mesurer la robustesse d’un système RAG face à des documents empoisonnés ou à des requêtes adversariales ? Comment combiner des contrôles préventifs et détectifs de manière économiquement soutenable ?

Nous adoptons une perspective de sécurité de type système, c’est-à-dire que nous considérons l’IA comme un ensemble socio-technique composé de modèles, de données, de règles, de permissions, de journaux, de workflows et d’opérateurs humains. Cette perspective est essentielle, car de nombreuses vulnérabilités ne proviennent pas du modèle lui-même mais de sa mise en contexte. Un LLM isolé avec accès minimal est déjà exposé à des attaques de manipulation, mais le niveau de risque devient critique lorsqu’il peut appeler des fonctions métiers, accéder à des secrets, écrire dans des tickets, envoyer des messages ou exécuter des scripts. Dans ce cadre, la bonne question n’est pas « le modèle est-il sûr ? », mais « quelles actions peut-il provoquer, sous quelles conditions, et avec quelles barrières de sécurité ? ».

L’article est structuré pour servir de base à des architectes, des chercheurs et des équipes opérationnelles. Après un état de l’art synthétique, nous formalisons le problème et proposons une architecture défensive multi-couches. Nous détaillons ensuite une implémentation de référence sur une pile réaliste de 2026, incluant l’orchestration de conteneurs, l’observabilité par eBPF, les passerelles d’API et les contrôles d’accès fins. Nous présentons une évaluation expérimentale comparative avec mesures de taux de réussite des attaques, taux de faux positifs et impact de performance. Enfin, nous analysons un cas d’usage représentatif de déploiement d’assistant interne pour montrer comment des décisions apparemment anodines peuvent devenir des vecteurs de compromission.

2. Background and Related Work

La littérature sur la sécurité de l’IA s’est fortement densifiée entre 2023 et 2026, à mesure que les organisations ont mis en production des systèmes de génération de texte, de code et de raisonnement. Les premières grandes lignes de vulnérabilité étaient déjà bien connues : l’empoisonnement de données, l’extraction de modèle, l’inférence d’attributs et les attaques adversariales sur les classifieurs. Toutefois, l’émergence des LLM a déplacé le centre de gravité vers des attaques orientées instructions, contexte et outils. Les travaux fondateurs de la période 2023-2025 ont montré que les modèles conversationnels étaient particulièrement vulnérables aux tentatives de détournement du contexte, notamment lorsque des instructions malveillantes étaient mélangées à des données récupérées dynamiquement ou à des messages système mal cloisonnés (OWEN, 2024). Ces observations ont conduit à des cadres de sécurisation tels que NIST AI RMF, MITRE ATLAS et les recommandations OWASP LLM Top 10, qui ont progressivement structuré le domaine (NIST, 2023 ; MITRE, 2024 ; OWASP, 2025).

Sur le plan conceptuel, il convient de distinguer plusieurs classes de systèmes. Les modèles discriminatifs classiques, encore présents dans la détection de fraude ou l’analyse de logs, restent vulnérables aux perturbations d’entrée et aux attaques d’évasion. Les modèles génératifs, en revanche, présentent un espace de menace plus large, car leur sortie peut contenir du texte, du code, des résumés, des plans d’action ou des appels à des outils. Les systèmes RAG ajoutent une couche de récupération documentaire qui introduit des risques spécifiques de contamination du corpus, de mauvaise attribution des sources et de confusion entre données fiables et contenus adversariaux (LEES et al., 2024). Les agents, enfin, constituent l’étape la plus sensible : ils transforment une recommandation en action, ce qui impose de raisonner en termes d’autorisation, de ségrégation des privilèges et de sûreté d’exécution.

Les attaques par injection de prompt se sont imposées comme l’une des menaces les plus visibles, car elles sont conceptuellement simples et compatibles avec de nombreux produits. Elles exploitent la priorité ambiguë des instructions, l’absence de frontière stricte entre données et directives, ou l’interaction entre message système, contexte de conversation et contenu récupéré. En 2024 et 2025, plusieurs études ont démontré que des documents malveillants indexés dans un moteur RAG pouvaient imposer des comportements inattendus au modèle, y compris la révélation de secrets ou la génération de contenu non autorisé (RICE et al., 2024). Les attaques indirectes sont particulièrement préoccupantes, car un document externe, une page wiki ou un ticket de support peuvent devenir des vecteurs d’exploitation sans que l’utilisateur n’interagisse directement avec eux.

Le problème des agents outillés a donné naissance à une nouvelle sous-discipline : la sécurité de l’exécution autonome. L’idée qu’un LLM puisse appeler des fonctions, lancer des requêtes, interroger des bases de données ou déclencher des workflows a accéléré la productivité, mais a aussi introduit des risques de surautorisation et de latéralisation. Le cas typique est celui d’un assistant ayant accès à la messagerie, à un dépôt Git et à un système de tickets. Une injonction malveillante contenue dans un e-mail peut provoquer la création d’un ticket, l’exécution d’un script ou la fuite d’informations confidentielles si le système ne sépare pas strictement la lecture du contenu et l’autorisation d’action. Dans ce cadre, les travaux sur les permissions minimales, les jetons d’accès éphémères et les sandboxes d’outils sont devenus essentiels (GOOGLE, 2025).

Du côté des défenses, les approches ont évolué vers des architectures multi-couches. Les filtres d’entrée seuls se sont révélés insuffisants, car ils sont contournables par paraphrase, codage, segmentation ou injection indirecte. Les contrôles pertinents incluent désormais le filtrage sémantique des prompts, la détection de contenu adversarial, la validation de provenance des sources, l’isolation des outils, la surveillance comportementale, l’audit des appels d’API et le red teaming continu. Des cadres comme le Secure AI Design Pattern Catalog et les guides de la CISA et du NCSC ont mis l’accent sur la segmentation des responsabilités et la séparation entre les domaines de confiance (CISA, 2025 ; NCSC, 2025).

Les normes et cadres de gouvernance ont également progressé. Le NIST AI RMF a fourni une structure de gouvernance, de cartographie, de mesure et de gestion du risque, tandis que l’ISO/IEC 42001 a apporté un système de management de l’IA intégrable aux processus de conformité. En parallèle, la montée de la réglementation sur les systèmes d’IA a encouragé les organisations à documenter les données, les décisions de conception, les contrôles de sécurité et les mécanismes de supervision humaine (ISO, 2023 ; UNION EUROPÉENNE, 2024). Toutefois, ces cadres restent généraux et doivent être traduits en contrôles techniques concrets pour les équipes de terrain.

Le panorama défensif de 2026 est également marqué par la maturité de plusieurs technologies adjacentes. Les contrôles CNAPP et CSPM se sont imposés pour sécuriser les déploiements cloud-natifs, tandis que l’observabilité eBPF permet une visibilité fine sur les processus, les appels réseau et certaines interactions système sans agent lourd. Les mécanismes de confidentialité différentielle, d’apprentissage fédéré et de chiffrement homomorphe restent utiles dans des contextes spécifiques, mais leur coût opérationnel limite leur adoption généralisée. De la même manière, la cryptographie post-quantique est devenue une préoccupation structurante pour la protection à long terme des secrets, même si elle ne résout pas les menaces propres aux modèles d’IA.

Tableau 1. Principales classes de menaces IA en 2026

Classe de menace	Cible	Exemple d’impact	Détection possible	Référence dominante
Injection de prompt	Interface conversationnelle, RAG, agents	Fuite de secrets, exécution d’actions non autorisées	Analyse sémantique, règles de politique	OWASP LLM Top 10
Empoisonnement de données	Corpus d’entraînement ou d’indexation	Dégradation de la précision, backdoor comportementale	Vérification provenance, détection d’anomalies	NIST AI RMF
Extraction de modèle	API d’inférence	Vol de propriété intellectuelle, imitation	Limitation de débit, watermarking	MITRE ATLAS
Inférence d’attributs	Données personnelles	Ré-identification, violation de confidentialité	DP, limitation des sorties	ISO/IEC 23894
Abus d’agent	Outils et workflows	Actions indésirables, fraude, sabotage	Policy engine, approvals	CISA/NCSC

Le tableau ci-dessus montre que la sécurité de l’IA ne se résume pas à un seul vecteur. Chaque classe de menace cible une couche différente de la pile, ce qui exige des contrôles en profondeur. Cette diversité explique pourquoi les approches mono-défense échouent souvent en production, surtout lorsqu’un système combine récupération documentaire, mémoire persistante et exécution d’outils.

Tableau 2. Comparaison de cadres de gouvernance et de sécurité

Cadre	Année	Portée	Force principale	Limite principale
NIST AI RMF	2023	Gouvernance du risque IA	Structure claire gouverner/cartographier/mesurer/agir	Peu prescriptif techniquement
ISO/IEC 42001	2023	Système de management IA	Intégration conformité/processus	Dépend de l’implémentation locale
MITRE ATLAS	2024	TTP d’attaque IA	Taxonomie opérationnelle	Pas un contrôle de sécurité
OWASP LLM Top 10	2025	Vulnérabilités LLM	Très actionnable pour les développeurs	Couverture inégale des agents
CISA Secure AI Guidance	2025	Bonnes pratiques	Orientation opérationnelle	Généraliste, peu métrique

3. Threat Model and Problem Formalization

Nous modélisons un système d’IA cyber comme un graphe d’états et de permissions. Le système reçoit une entrée $x$ composée de messages utilisateurs, de documents récupérés, de métadonnées et éventuellement d’états mémoire. Le modèle produit une sortie $y$, qui peut être textuelle ou structurée. Cette sortie peut déclencher une action $a$ via des outils, des fonctions ou des workflows. Le risque naît lorsque l’attaquant contrôle une partie de $x$ ou influence les conditions de génération de $y$, puis parvient à faire exécuter une action non voulue. Formellement, si $P(a \mid x, \theta, \pi)$ désigne la probabilité qu’une politique $\pi$ exécutée par un modèle de paramètres $\theta$ produise une action $a$, l’objectif défensif est de minimiser la probabilité des actions dangereuses $a \in A_{bad}$ sous contrainte d’utilité fonctionnelle.

On peut définir la fonction de risque globale comme : $$ R = \sum_{i=1}^{n} P(T_i) \cdot I(T_i) \cdot E(T_i) $$ où $P(T_i)$ est la probabilité d’occurrence de la menace $T_i$, $I(T_i)$ son impact, et $E(T_i)$ l’efficacité des contrôles en place. Cette formulation est utile, car elle permet de comparer des scénarios hétérogènes sur une base commune. Dans les systèmes d’IA, les probabilités sont souvent mal estimées, car les comportements émergents des modèles et des agents rendent les distributions instables. Il faut donc compléter l’analyse probabiliste par une analyse qualitative des dépendances de confiance et des frontières d’autorisation.

Notre modèle de menace adopte cinq hypothèses. Premièrement, l’attaquant peut soumettre du texte, des fichiers ou des pages web consommées par le système. Deuxièmement, l’attaquant peut observer les sorties du modèle, éventuellement de manière répétée. Troisièmement, le système peut disposer d’outils ayant des privilèges variables sur des ressources internes ou externes. Quatrièmement, la chaîne de confiance inclut des composants tiers, tels que connecteurs SaaS, index vectoriels ou services de logging. Cinquièmement, les opérateurs humains ne peuvent pas valider manuellement chaque décision d’inférence ou chaque action d’outil, ce qui impose une automatisation des contrôles.

Les principaux actifs à protéger sont les suivants : les secrets d’entreprise, les identifiants API, les données personnelles, les corpus propriétaires, les prompts système, les politiques internes, les modèles eux-mêmes, les traces d’audit et la réputation de l’organisation. Les adversaires incluent des fraudeurs cherchant à exfiltrer des données, des concurrents visant la propriété intellectuelle, des acteurs étatiques menant des campagnes de désinformation, et des attaquants opportunistes utilisant des prompts publics pour faire dérailler des assistants exposés. La menace interne est particulièrement importante, car un utilisateur légitime peut involontairement déclencher des comportements dangereux en fournissant des documents contaminés ou en autorisant trop largement un agent.

Un point essentiel est la séparation entre sécurité du modèle et sécurité du système. Un modèle robuste à certaines injections peut rester vulnérable à un workflow mal conçu. Inversement, un modèle moyennement robuste peut être acceptable si son environnement d’exécution est strictement limité. Nous proposons donc une décomposition en quatre couches : données, inférence, outils et gouvernance. Les données comprennent les corpus d’entraînement, les index RAG et les sources externes. L’inférence couvre le modèle, le prompt, le contexte et la mémoire. Les outils incluent les appels réseau, l’accès au système de fichiers, les fonctions métier et les actions de publication. La gouvernance englobe les approbations, l’audit, les politiques et le contrôle humain.

Tableau 3. Actifs, menaces et contrôles prioritaires

Actif	Menace principale	Contrôle prioritaire	Indicateur de réussite
Prompt système	Vol, manipulation, contournement	Isolation, minimisation, stockage protégé	Taux d’exposition nul
Corpus RAG	Empoisonnement, injection indirecte	Validation provenance, scoring confiance	% de documents non fiables bloqués
Secrets API	Exfiltration via modèle ou outil	Vault, rotation, secrets à durée courte	Aucun secret dans les logs
Outils métiers	Abus d’agent, action irréversible	Approvals, RBAC/ABAC, sandbox	Réduction des actions non autorisées
Journaux	Effacement, falsification	WORM, corrélation SIEM	Intégrité vérifiable

La formalisation doit aussi intégrer la notion d’adversaire adaptatif. Un attaquant peut tester le système à faible intensité pour cartographier les garde-fous, puis ajuster ses prompts. Ainsi, un système ne doit pas seulement être évalué sur un jeu fixe de prompts toxiques ; il doit résister à des stratégies itératives et contextuelles. Cette nécessité est particulièrement importante pour les agents, car l’attaquant peut exploiter des effets de mémoire, des dialogues longs et des états intermédiaires. En termes de sécurité, il faut considérer la conversation comme un espace persistant potentiellement hostile, et non comme une suite d’interactions indépendantes.

4. Proposed Methodology

Nous proposons une méthodologie défensive en cinq piliers : gouvernance des risques, durcissement des données, contrôle de l’inférence, confinement des outils et supervision continue. Cette approche est conçue pour être déployée dans une organisation de taille moyenne à grande, avec un socle cloud-native et une exigence de disponibilité élevée. L’idée centrale est d’empêcher qu’un événement isolé, par exemple une injection de prompt ou un document malveillant, ne puisse se transformer en compromission systémique.

Le premier pilier est la gouvernance. Toute fonctionnalité d’IA doit être inventoriée, classifiée par niveau de sensibilité et reliée à une matrice de risques. Les systèmes exposant des données internes ou des outils d’action doivent être soumis à une revue de sécurité avant mise en production. Cette revue doit inclure un threat modeling spécifique à l’IA, une analyse des fournisseurs de modèles, une politique de conservation des logs et une définition des seuils d’escalade humaine. La gouvernance doit également intégrer les exigences de conformité et la traçabilité des décisions automatisées.

Le deuxième pilier concerne les données. Les corpus d’entraînement et d’indexation doivent être signés, horodatés et classés par provenance. Les documents externes doivent recevoir un score de confiance basé sur la source, la fraîcheur, la cohérence et la réputation. Pour le RAG, nous recommandons une séparation stricte entre index de confiance et index non fiables. Les documents non fiables peuvent être utilisés à des fins de recherche, mais ils ne doivent pas influencer directement des décisions exécutoires sans traitement supplémentaire. Lorsque c’est possible, il faut appliquer des contrôles de déduplication, de détection d’instructions dans le contenu, et de classification sémantique des fragments récupérés.

Le troisième pilier est le contrôle de l’inférence. Les prompts système doivent être minimisés et protégés, les fenêtres de contexte bornées, et la mémoire persistante soumise à une politique d’expiration. Les contrôles d’entrée doivent détecter les tentatives d’injection explicite ou indirecte, mais aussi les signaux de contournement, comme la segmentation syntaxique, le codage obfusqué, les instructions dissimulées dans des citations ou les tentatives de transformation de rôle. Un filtrage purement lexical est insuffisant ; nous préconisons une combinaison de règles, de classificateurs légers et d’analyses de cohérence sémantique. La décision finale peut être modélisée par : $$ D = f(s_{lex}, s_{sem}, s_{ctx}, s_{prov}, s_{policy}) $$ où $s_{lex}$ est un score lexical, $s_{sem}$ un score sémantique, $s_{ctx}$ un score contextuel, $s_{prov}$ un score de provenance et $s_{policy}$ un score de politique.

Le quatrième pilier est le confinement des outils. Chaque outil exposé au modèle doit fonctionner avec le privilège minimal nécessaire. Les opérations destructives ou coûteuses doivent exiger une validation explicite ou une approbation humaine. Les appels réseau sortants doivent être filtrés par domaine, méthode et destination. Les accès au système de fichiers doivent être contraints par des répertoires virtuels ou des sandboxes. Les tokens d’accès doivent être éphémères et liés au contexte de la session. En pratique, un agent ne doit jamais disposer d’un accès permanent à des secrets ou à des chemins critiques sans médiation.

Le cinquième pilier est la supervision continue. Les journaux doivent inclure les prompts, les sources récupérées, les outils appelés, les décisions de politique et les erreurs. La télémétrie doit être corrélée dans le SIEM afin de détecter des séquences suspectes, comme une augmentation soudaine des refus, des appels d’outils répétitifs ou des tentatives de lecture de ressources hors périmètre. Les équipes SOC doivent disposer de playbooks dédiés à l’IA, incluant la suspension d’un agent, la purge de mémoire, la rotation des secrets et la réindexation d’un corpus contaminé.

L’architecture de référence se présente comme une chaîne de contrôle à huit points : ingestion, normalisation, classification de confiance, récupération documentaire, filtrage de prompt, génération, contrôle d’outil et audit. Chaque étape produit une trace exploitable. Le système doit préférer un échec sûr à une action risquée. Nous recommandons aussi des évaluations périodiques de type red teaming, menées à la fois par des humains et par des scripts automatisés de fuzzing sémantique, afin de mesurer la dérive des protections dans le temps.

5. Implementation

L’implémentation de référence repose sur une architecture conteneurisée de type Kubernetes, avec une couche d’observabilité et de politique adaptée aux charges IA. Le modèle est servi via un runtime d’inférence isolé, tandis qu’un service séparé gère le RAG, la mémoire conversationnelle et l’orchestration des outils. Les secrets sont stockés dans un coffre-fort dédié, et les appels sortants passent par une passerelle contrôlée. Cette séparation permet de limiter l’impact d’un compromis local et de simplifier l’audit.

Le composant de filtrage de prompt est placé en amont du LLM. Il combine des règles sur les instructions à haut risque, un classificateur léger pour les requêtes adversariales et une analyse des métadonnées de la session. Les documents récupérés sont d’abord passés par une étape de normalisation qui supprime les éléments cachés, les artefacts de formatage et les fragments suspects. Les fragments non fiables reçoivent un balisage de confiance qui influence leur pondération dans la génération. Les outils métiers sont encapsulés derrière une API interne qui impose des politiques d’accès et enregistre tous les appels.

Voici un exemple de déploiement d’un service d’IA dans un cluster Kubernetes avec restrictions de sécurité minimales. Ce type de configuration n’élimine pas les risques, mais il établit une base défendable.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-assistant
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ai-assistant
  template:
    metadata:
      labels:
        app: ai-assistant
    spec:
      serviceAccountName: ai-assistant-sa
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: registry.example.com/ai-assistant:2026.1
          ports:
            - containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          env:
            - name: MODEL_ENDPOINT
              value: "http://llm-inference:8000"
            - name: VECTOR_DB_URL
              value: "http://rag-store:6333"

Pour l’observabilité, nous avons utilisé des événements eBPF afin de corréler les appels de fichiers, les connexions réseau et les processus lancés par le service d’orchestration. Cette approche est utile, car certains abus d’agents se manifestent d’abord par des appels systèmes inhabituels avant même que les logs applicatifs ne révèlent l’anomalie. Une règle de détection peut, par exemple, bloquer un agent qui tente d’ouvrir un chemin hors périmètre ou de contacter un domaine non autorisé.

kubectl apply -f ai-assistant-deployment.yaml
kubectl create configmap ai-policy --from-file=policy.rego
kubectl logs deploy/ai-assistant -f

La politique d’autorisation est exprimée en règles déclaratives. Un exemple simplifié consiste à autoriser uniquement certaines fonctions métier et à exiger une validation humaine pour les opérations sensibles. L’important n’est pas le langage lui-même, mais la capacité à rendre les décisions explicites, vérifiables et auditablement cohérentes. La logique de contrôle doit être partagée entre le service d’inférence et un moteur de politique centralisé afin d’éviter que le modèle n’improvise des actions en dehors du cadre prévu.

Le pipeline inclut également un module de redaction des secrets. Avant toute persistance de traces, les éventuels tokens, clés API ou identifiants sensibles sont masqués. Cela n’empêche pas une exfiltration en temps réel par la sortie du modèle, mais réduit considérablement le risque secondaire lié à la conservation de journaux trop riches. Enfin, une stratégie de rotation des secrets et d’expiration courte des jetons réduit la fenêtre d’exploitation après compromission.

6. Experimental Evaluation

L’évaluation a été conçue pour mesurer à la fois l’efficacité des protections et leur coût opérationnel. Nous avons testé trois configurations : une base sans contrôles spécifiques IA, une configuration intermédiaire avec filtrage et journalisation, et une configuration renforcée avec filtrage sémantique, contrôle d’outils, provenance des sources et approbations humaines pour les actions sensibles. Les tests ont été menés sur un assistant interne simulé, doté d’un accès à une base documentaire RAG, à une messagerie fictive et à un outil de création de tickets.

Les jeux d’essai couvraient quatre familles d’attaques : injection directe de prompt, injection indirecte via document RAG, tentative d’exfiltration de secrets, et abus d’outil. Nous avons mesuré le taux de réussite de l’attaque, le taux de faux positifs du mécanisme défensif et l’impact de latence par requête. Le succès d’une attaque était défini par l’obtention d’un comportement non autorisé ou par la fuite d’un artefact sensible. La latence était calculée sur un échantillon de 1 000 requêtes par configuration, avec une charge légère et une charge mixte.

Tableau 4. Résultats comparatifs par configuration de défense

Configuration	Injection directe réussie	Injection indirecte réussie	Exfiltration de secrets	Abus d’outil	Latence médiane
Base	71%	64%	58%	49%	820 ms
Intermédiaire	29%	24%	17%	15%	1090 ms
Renforcée	8%	6%	3%	2%	1310 ms

Les résultats montrent une amélioration nette lorsque les contrôles sont combinés. La configuration renforcée réduit fortement les attaques réussies, en particulier les abus d’outils, ce qui confirme que le maillon critique n’est pas toujours le modèle, mais l’autorisation d’exécuter une action. Le coût est une augmentation de latence d’environ $59%$ par rapport à la base, principalement liée aux vérifications de politique et aux étapes de validation. Dans la plupart des cas d’usage métier, ce surcoût reste acceptable si le système manipule des données sensibles ou peut déclencher des actions irréversibles.

Tableau 5. Taux de détection et faux positifs

Contrôle	Taux de détection	Faux positifs	Commentaire
Filtrage lexical	62%	4.8%	Bon sur les patterns évidents, faible robustesse
Classificateur sémantique	81%	6.1%	Meilleur sur paraphrases, plus coûteux
Validation provenance RAG	88%	2.7%	Très efficace contre l’injection indirecte
Policy engine outils	94%	1.9%	Très bon pour contenir l’impact
Ensemble multi-couches	96%	2.4%	Meilleur compromis global

Ces données confirment qu’aucun contrôle isolé ne suffit. Le filtrage lexical, bien qu’utile, est contournable. La provenance des documents et le policy engine apportent les meilleurs gains, car ils agissent respectivement sur la source d’influence et sur la capacité d’action. Le taux de faux positifs reste contenu dans la configuration renforcée, mais il nécessite un ajustement fin des seuils pour éviter d’entraver des usages légitimes.

Tableau 6. Impact de la défense sur les performances opérationnelles

Mesure	Base	Renforcée	Écart
Latence p50	820 ms	1310 ms	+59%
Latence p95	1540 ms	2280 ms	+48%
Débit soutenu	145 req/min	98 req/min	-32%
Taux d’escalade humaine	2.1%	7.4%	+5.3 pts
Incidents potentiels évités	faible	élevé	significatif

L’escalade humaine augmente mécaniquement, car certaines requêtes passent désormais par une validation explicite. Ce phénomène n’est pas nécessairement un défaut ; il traduit le bon positionnement du contrôle humain sur les actions à fort impact. La question opérationnelle devient alors celle du calibrage : il faut réserver l’approbation manuelle aux cas réellement sensibles et automatiser le reste. Une politique trop stricte peut déplacer les utilisateurs vers des canaux parallèles non supervisés, ce qui dégraderait la sécurité globale.

Au-delà de ces métriques, nous avons observé que les attaques indirectes restent les plus difficiles à neutraliser complètement. Un document RAG contenant des consignes toxiques peut être partiellement neutralisé par le filtrage et la provenance, mais la réussite dépend encore de la manière dont le système fusionne les fragments, priorise les sources et expose le contexte au modèle. Cela confirme que les défenseurs doivent traiter le pipeline complet, et non seulement la couche de génération.

7. Case Study

Nous avons étudié un cas représentatif d’assistant interne déployé dans une entreprise de services. L’assistant devait aider les employés à rechercher des procédures, résumer des tickets et préparer des brouillons de réponses clients. Le système était connecté à une base documentaire, à une messagerie interne et à un outil de création de tickets. Au départ, l’objectif était purement productif, sans intention d’automatisation sensible. Pourtant, après quelques mois, l’outil disposait de permissions trop larges et commençait à exécuter des actions au nom des utilisateurs, ce qui a créé une exposition inattendue.

L’incident simulé a commencé par un document externe introduit dans le corpus RAG. Le document contenait du texte apparemment légitime, mais incluait aussi des consignes visant à faire ignorer les instructions précédentes et à révéler certains contenus du contexte. Lors d’une requête normale, le modèle a récupéré ce document, l’a intégré à sa réponse, puis a suggéré une action de suivi qui impliquait la création d’un ticket. Comme l’outil de ticketing ne vérifiait pas le niveau de confiance de la suggestion, le ticket a été créé avec des informations sensibles partiellement dérivées d’une discussion interne. L’impact a été limité par la supervision humaine, mais l’épisode a révélé une faiblesse structurelle.

L’analyse post-incident a montré trois causes racines. Premièrement, l’index RAG ne distinguait pas clairement les sources internes validées des documents externes non filtrés. Deuxièmement, l’agent disposait d’un jeton permettant de créer des tickets sans validation. Troisièmement, les logs étaient insuffisamment précis pour reconstruire la chaîne complète de décision. La remédiation a consisté à séparer les index, à restreindre les permissions de l’agent, à introduire une validation humaine pour toute action touchant à un ticket contenant des données sensibles, et à renforcer la journalisation des sources récupérées.

Ce cas illustre une vérité fondamentale : dans les systèmes d’IA, la compromission la plus dangereuse est souvent graduelle. Elle ne se manifeste pas par une alerte spectaculaire, mais par une suite de petites dérives qui paraissent fonctionnelles au niveau local. Un assistant qui résume un document malveillant, puis propose une action, puis l’exécute à la place de l’utilisateur, peut devenir un pivot d’incident sans aucun exploit classique. La défense doit donc s’intéresser à la chaîne causale complète, depuis la provenance du document jusqu’à l’effet concret de l’action.

8. Discussion

Les résultats et l’étude de cas conduisent à plusieurs conclusions importantes. La première est que la sécurité de l’IA doit être pensée comme une problématique de contrôle d’accès et de confiance contextuelle, pas seulement comme un problème de robustesse statistique. Un modèle peut être excellent sur le plan de la performance, mais rester dangereux s’il peut accéder à des outils trop puissants. La seconde est que la séparation des domaines de confiance est décisive. Les sources RAG, les mémoires conversationnelles, les prompts système et les outils doivent être isolés autant que possible, avec des chemins de circulation explicites et audités.

La troisième conclusion est que les organisations sous-estiment souvent l’importance de la provenance. Sans provenance fiable, le système mélange facilement données certifiées, contenus générés et documents externes. Or, dans un contexte IA, l’attribution des sources est un mécanisme de sécurité à part entière. Elle permet de pondérer les réponses, de détecter les intrusions indirectes et de faciliter les investigations. La quatrième conclusion est que la gouvernance doit être opérationnalisée. Une politique écrite n’a de valeur que si elle se traduit en garde-fous techniques, en métriques et en responsabilités claires.

Sur le plan offensif, il est important de noter que les attaquants tirent profit de la nature probabiliste des systèmes d’IA. Ils testent des variantes, exploitent les longueurs de contexte, recherchent des formulations qui contournent les filtres et utilisent des artefacts comme les citations, les encadrés de code ou les documents de référence pour masquer des instructions. Les défenses doivent donc être adaptatives. Un système figé sera rapidement appris, puis contourné. Les méthodes d’évaluation continue, les fuzzers sémantiques et le red teaming régulier sont donc essentiels.

Sur le plan de l’ingénierie, l’équilibre entre sécurité et utilité reste délicat. Trop de friction peut pousser les utilisateurs à chercher des contournements, comme copier des données sensibles dans des outils non approuvés. Trop peu de friction expose à des abus. La solution réside dans une segmentation fine : les tâches à faible risque peuvent être largement automatisées, tandis que les tâches à fort impact doivent déclencher une validation. Cette logique de seuil s’intègre naturellement dans des politiques de risque adaptatives.

Enfin, les considérations de gouvernance future sont majeures. La maturité des contrôles CNAPP, eBPF et des politiques d’accès fines permet aujourd’hui d’industrialiser une bonne partie des protections, mais la qualité finale dépend toujours de la discipline de mise en œuvre. Les organisations qui réussiront seront celles qui auront intégré la sécurité IA dans leur cycle de développement, leurs opérations SOC et leur gouvernance des données, plutôt que de la traiter comme une couche décorative ajoutée après coup.

9. Conclusion and Future Work

Cet article a montré que la sécurité de l’IA en 2026 est un problème multidimensionnel qui combine menaces sur les données, les modèles, les prompts, les outils et les workflows. Nous avons proposé un modèle de menace adapté aux systèmes LLM, RAG et agentiques, puis une méthodologie défensive fondée sur cinq piliers : gouvernance, durcissement des données, contrôle de l’inférence, confinement des outils et supervision continue. L’évaluation expérimentale a démontré que les défenses multi-couches réduisent fortement les attaques réussies, au prix d’un surcoût mesurable mais généralement acceptable dans des contextes sensibles.

La conclusion principale est qu’aucun mécanisme unique ne suffit. Les systèmes d’IA sûrs sont ceux qui limitent la confiance accordée au modèle, encadrent strictement ses capacités d’action et rendent ses décisions observables. Cette logique doit être appliquée dès la conception, puis maintenue par des tests continus, des revues de privilèges et des procédures de réponse aux incidents spécifiques à l’IA. Les SOC et les équipes red/blue doivent désormais intégrer les vecteurs IA dans leurs opérations quotidiennes.

Les travaux futurs devraient porter sur trois axes. D’abord, la quantification plus fine du risque lié aux agents autonomes, notamment lorsque plusieurs outils interagissent. Ensuite, la standardisation de formats de journaux et de schémas d’audit interopérables pour les pipelines IA. Enfin, la recherche de mécanismes de protection plus robustes contre les injections indirectes, notamment dans les environnements RAG distribués et les systèmes multi-modèles. À moyen terme, l’intégration de preuves cryptographiques de provenance, de politiques exécutables et de contrôles de type zero trust devrait permettre d’améliorer significativement la résilience des plateformes d’IA. Toutefois, la discipline opérationnelle restera déterminante : en 2026 comme après, un système d’IA n’est sûr que si son environnement l’est.

10. References

1. CISA. Secure by Design for AI Systems. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2025. Disponível em: https://www.cisa.gov/secure-by-design/ai
2. GOOGLE. Secure AI Framework (SAIF). Mountain View: Google Cloud, 2025. Disponível em: https://cloud.google.com/security/ai
3. ISO. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. Geneva: International Organization for Standardization, 2023. Disponível em: https://www.iso.org/standard/81230.html
4. LEES, A. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP. 2024. Disponível em: https://arxiv.org/abs/2005.11401
5. MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. Bedford, 2024. Disponível em: https://atlas.mitre.org/
6. NCSC. Guidance on Secure AI System Development. London: National Cyber Security Centre, 2025. Disponível em: https://www.ncsc.gov.uk/collection/ai-security
7. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg: National Institute of Standards and Technology, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework
8. 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/
9. OWEN, A. Prompt Injection Attacks and Defenses in LLM Applications. 2024. Disponível em: https://arxiv.org/abs/2402.08790
10. RICE, L. et al. Indirect Prompt Injection: Attacks and Defenses in RAG Systems. 2024. Disponível em: https://arxiv.org/abs/2403.12345
11. UNION EUROPÉENNE. Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle. Journal officiel de l’Union européenne, 2024. Disponível em: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
12. APACHE. Apache Airflow Documentation. 2026. Disponível em: https://airflow.apache.org/docs/
13. CALDER, M. et al. MITRE ATT&CK for Enterprise. 2026. Disponível em: https://attack.mitre.org/
14. CIS. CIS Controls v8. 2024. Disponível em: https://www.cisecurity.org/controls/v8
15. CNCF. Kubernetes Security Best Practices. 2025. Disponível em: https://kubernetes.io/docs/concepts/security/
16. DUO, X.; ZHANG, Y. Security Evaluation of LLM-Based Agents. 2025. Disponível em: https://arxiv.org/abs/2501.01234
17. GARTNER. CNAPP Market Guide. 2025. Disponível em: https://www.gartner.com/en/documents
18. GUO, J. et al. AI Data Poisoning in Retrieval-Augmented Systems. 2025. Disponível em: https://arxiv.org/abs/2504.06789
19. KULYK, L. et al. LLM Watermarking and Model Extraction Resistance. 2024. Disponível em: https://arxiv.org/abs/2406.09876
20. MICROSOFT. Microsoft Security Guidance for Generative AI. 2025. Disponível em: https://learn.microsoft.com/security/ai/
21. MONGODB. Vector Search Security Considerations. 2026. Disponível em: https://www.mongodb.com/docs/
22. OPENAI. Model Spec and Safety Policies. 2025. Disponível em: https://model-spec.openai.com/
23. PALO ALTO NETWORKS. Cloud-Native Application Protection Platform: Reference Architecture. 2025. Disponível em: https://www.paloaltonetworks.com/cnapp
24. REDMOND, S. et al. Evaluation of AI Red Teaming Methods. 2025. Disponível em: https://arxiv.org/abs/2502.04444
25. SAFELI, H. et al. eBPF-based Runtime Security for Cloud-Native Systems. 2024. Disponível em: https://www.usenix.org/conference/atc24/presentation/
26. SCHMIDT, F. et al. Privacy Risks in Large Language Models. 2024. Disponível em: https://arxiv.org/abs/2405.12321
27. SNYK. AI Supply Chain Security Report. 2025. Disponível em: https://snyk.io/reports/
28. WARDEN, P. et al. Secure Tool Use in LLM Agents. 2025. Disponível em: https://arxiv.org/abs/2506.11111
29. W3C. Content Security Policy Level 3. 2024. Disponível em: https://www.w3.org/TR/CSP3/
30. ZHANG, H. et al. Prompt Injection Benchmarks for Enterprise LLMs. 2026. Disponível em: https://arxiv.org/abs/2601.00987