Sécurité IA par architecture | RAG air-gapped en Rust | Lexiane

La sécurité d’un système IA en production n’est pas réductible à une liste de mesures appliquées après déploiement. Elle est la conséquence d’un ensemble de décisions d’architecture prises en amont — sur le langage, sur les frontières du système, sur la gestion mémoire, sur les surfaces d’exposition. Ces décisions déterminent ce qu’un attaquant peut atteindre, ce que le système peut laisser fuir, et ce qu’un auditeur peut vérifier.

Lexiane a été conçu avec cette logique : chaque propriété de sécurité est soit garantie mécaniquement par le compilateur, soit vérifiée par un test automatisé en intégration continue, soit rendue physiquement impossible par l’architecture. Il n’y a pas de propriétés de sécurité reposant uniquement sur des conventions de développement ou sur la vigilance individuelle des équipes.

---

Le paysage des menaces spécifiques aux systèmes RAG

Les systèmes RAG introduisent des vecteurs d’attaque qui n’existent pas dans les systèmes logiciels traditionnels. L’OWASP a publié en 2023, mis à jour en 2025, un référentiel des dix catégories de risques prioritaires pour les applications LLM — l’OWASP LLM Top 10. Parmi les plus critiques pour un système de traitement documentaire :

LLM01 — Injection de prompt. Un attaquant insère dans une requête des instructions destinées à contourner les politiques du système, à exfiltrer des données, ou à produire des contenus non conformes. Dans un système RAG exposé à des utilisateurs non entièrement de confiance — agents externes, utilisateurs internes avec des droits limités —, ce vecteur est le plus fréquemment exploité.

LLM06 — Divulgation d’informations sensibles. Le modèle de langage peut produire des réponses incorporant des données présentes dans le contexte récupéré, y compris des données personnelles ou des informations confidentielles que l’utilisateur requérant ne devrait pas voir. Dans un corpus multi-utilisateurs, l’absence de contrôle d’accès au niveau de la récupération crée ce risque systématiquement.

LLM02 — Gestion non sécurisée des sorties. Les sorties du LLM sont utilisées sans validation suffisante — dans des interfaces web (XSS), dans des appels système, ou retransmises à d’autres systèmes sans filtrage. Les sorties d’un LLM sont de la donnée non fiable et doivent être traitées comme telle.

LLM09 — Sur-confiance dans les sorties du modèle. Un système qui accepte et transmet les réponses du LLM sans vérification de leur ancrage dans les sources documentaires ouvre la voie à la désinformation opérationnelle — des réponses fausses présentées avec la même apparence de fiabilité que des réponses correctes.

À ces menaces spécifiques aux LLM s’ajoutent les menaces classiques amplifiées par la complexité des stacks IA : vulnérabilités mémoire introduites par les dépendances C/C++ sous-jacentes aux frameworks Python, chaîne d’approvisionnement logicielle (supply chain), surface d’attaque étendue par les processus secondaires et les appels réseau.

Lexiane adresse chacune de ces catégories — par des mécanismes distincts, vérifiables, et documentés.

---

Sécurité mémoire : ce que Rust exclut structurellement

La classe de vulnérabilités que Python et C++ ne peuvent pas éliminer

Les vulnérabilités liées à la gestion mémoire — buffer overflow, use-after-free, double free, pointeur nul déréférencé, race condition mémoire — constituent historiquement la majorité des vulnérabilités de sécurité critiques dans les systèmes logiciels. Google a documenté sur le projet Android que l’adoption de Rust comme langage système a réduit de 68 % les vulnérabilités liées à la mémoire sur cinq ans. Microsoft a estimé que 70 % des CVE critiques dans ses produits trouvent leur origine dans des erreurs de gestion mémoire.

Les frameworks RAG Python s’appuient sur des bibliothèques C et C++ pour leurs opérations intensives — PyTorch, NumPy, les parseurs natifs, les bibliothèques de compression. Ces dépendances héritent de toutes les classes de vulnérabilités des langages non memory-safe. Une vulnérabilité dans une dépendance transitive — invisible dans le code Python de surface — peut compromettre l’ensemble du système.

Ce que le compilateur Rust garantit

Rust élimine par construction, au niveau du compilateur, les catégories entières de bugs mémoire évoquées ci-dessus :

• Absence de pointeurs nuls déréférencés — les valeurs optionnelles sont exprimées via Option<T>, dont le traitement exhaustif est exigé par le compilateur.
• Absence de use-after-free — le système de propriété de Rust garantit qu’une ressource libérée ne peut plus être accédée. Cette propriété est vérifiée statiquement, sans analyse dynamique.
• Absence de data races — le système de types de Rust garantit l’exclusion mutuelle entre accès concurrents mutables. Une data race est une erreur de compilation, pas une condition de course découverte en production.
• Absence d’overflow arithmétique non contrôlé — en mode debug, les overflows sont détectés et paniquent. En mode release, le comportement est défini et configurable — jamais un comportement indéfini exploitable.

#![forbid(unsafe_code)] sur le périmètre certifié

Rust permet d’écrire du code “unsafe” — des blocs où les garanties du compilateur sont suspendues, nécessaires pour interagir avec des interfaces C ou le système. Cette fonctionnalité est une trappe : dans un code base sans discipline, elle peut réintroduire les vulnérabilités que Rust est censé éliminer.

Le noyau certifié de Lexiane (vectrant-core) porte la directive #![forbid(unsafe_code)]. Cette directive n’est pas une convention — elle est appliquée par le compilateur. Aucun développeur ne peut introduire un bloc unsafe dans le périmètre certifié, même par inadvertance, même sous pression de délai. Le compilateur rejette le code avant que le binaire n’existe.

En décembre 2023, la CISA (Cybersecurity and Infrastructure Security Agency) a publié “The Case for Memory Safe Roadmaps”, recommandant explicitement l’adoption de langages memory-safe — dont Rust — pour les systèmes critiques. Le Département de la Défense américain et la Maison-Blanche ont émis des recommandations convergentes. Lexiane satisfait à ces préconisations par architecture.

---

Réduction de la surface d’attaque

Un binaire, pas un écosystème

Chaque dépendance externe est un vecteur d’attaque potentiel. Un système Python en production expose une surface d’attaque étendue : l’interpréteur Python, les packages installés via pip, les bibliothèques système partagées chargées dynamiquement, les processus secondaires (serveur Ollama, API Redis, worker Celery). Un attaquant qui compromet une dépendance — par une vulnérabilité zero-day ou une attaque de chaîne d’approvisionnement — peut compromettre l’ensemble du système.

Lexiane se compile en un binaire statique autonome. Il ne charge pas de bibliothèques partagées à l’exécution. Il ne résout pas de dépendances au démarrage. Il ne télécharge pas de code externe pendant son exécution. La surface d’attaque est délimitée par le binaire lui-même — un périmètre fixe, auditable, reproductible.

Sécurité de la chaîne d’approvisionnement

Les attaques de chaîne d’approvisionnement logicielle — compromission d’un package open-source pour injecter du code malveillant dans les applications qui en dépendent — sont en augmentation constante. L’index PyPI a subi de nombreux incidents de ce type ces dernières années.

Lexiane adresse ce risque par deux mécanismes complémentaires :

Zéro dépendance vendor dans le noyau certifié. Le module vectrant-core — le cœur du système — ne contient aucune dépendance vers un éditeur tiers. Cette contrainte est vérifiée par un test automatisé qui échoue à la compilation si une dépendance externe est introduite. La régression est impossible sans être immédiatement détectée.

Compilation avec Ferrocene. Ferrocene est la version qualifiée du compilateur Rust développée par Ferrous Systems — qualifiée ISO 26262 ASIL D et IEC 61508 SIL 4. Compiler Lexiane avec Ferrocene permet d’établir une chaîne de confiance complète pour la certification : du code source, au compilateur, jusqu’au binaire déployé. Un attaquant qui voudrait introduire du code malveillant devrait compromettre le compilateur lui-même — dont la qualification impose une traçabilité rigoureuse.

Absence de processus secondaires

Les frameworks RAG Rust alternatifs — Swiftide, Rig — nécessitent un serveur d’inférence externe pour la génération de texte : un processus Ollama, un endpoint OpenAI, ou un serveur vLLM. Ce serveur secondaire est un composant réseau indépendant : sa surface d’attaque s’ajoute à celle du framework RAG, et les communications entre les deux composants créent un canal potentiellement interceptable.

Lexiane embarque l’inférence LLM (Mistral.rs) et les embeddings (Candle) dans le même binaire. En configuration locale, il n’y a pas de processus secondaire, pas de communication réseau interne, pas de canal inter-processus à sécuriser.

---

Sécurité spécifique aux systèmes IA

Défense contre l’injection de prompt

Le port InputGuardrail de Lexiane implémente une couche de validation des requêtes entrantes avant qu’elles n’atteignent le pipeline de récupération ou le modèle de langage. Les patterns d’injection de prompt — instructions cachées dans la requête, tentatives de contournement des politiques du système, escalade de privilèges par manipulation du prompt — sont détectés et bloqués à ce stade.

Ce mécanisme opère en amont du pipeline : une requête bloquée par l’InputGuardrail ne génère aucun embedding, ne déclenche aucune récupération, et ne sollicite aucun LLM. Il n’y a pas de coût computationnel associé aux requêtes malveillantes bloquées, et pas de risque que leur contenu influence le comportement du modèle.

Contrôle des sorties du modèle

Le port OutputGuardrail valide la réponse produite avant transmission à l’utilisateur. Trois catégories de risques sont adressées :

Fuite de données sensibles. Le LLM peut incorporer dans sa réponse des données présentes dans le contexte récupéré — y compris des données personnelles que l’utilisateur n’aurait pas dû voir, ou des informations confidentielles issues de documents accessibles via le mécanisme de récupération. L’OutputGuardrail détecte ces fuites et les bloque avant transmission.

Contenu toxique ou non conforme. Les réponses qui violent les politiques de contenu définies par l’organisation — contenu discriminatoire, instructions dangereuses, contenu hors périmètre — sont interceptées avant d’atteindre l’utilisateur.

Réponses non ancrées. Le FaithfulnessChecker vérifie que la réponse produite est effectivement soutenue par les sources récupérées. Une réponse qui extrapole au-delà du contexte fourni — c’est-à-dire une hallucination — est détectée et peut déclencher une abstention ou un signalement.

Contrôle d’accès au niveau documentaire

Le port AccessControl implémente un filtrage des résultats de récupération basé sur les droits de l’utilisateur requérant. Ce filtrage opère avant la génération : les documents auxquels l’utilisateur n’a pas accès ne sont pas transmis au LLM comme contexte.

Cette position dans le pipeline est critique. Un contrôle d’accès qui s’applique uniquement sur l’interface — en masquant certaines réponses dans l’UI — laisse des données sensibles traverser le modèle de langage. Un LLM ayant reçu un document confidentiel dans son contexte peut en révéler le contenu de façon indirecte, même si la réponse finale semble ne pas y faire référence. Lexiane coupe ce vecteur à la source.

Deux modèles de contrôle d’accès sont supportés :

• RBAC (Role-Based Access Control) — les droits d’accès sont définis par le rôle de l’utilisateur dans l’organisation.
• ABAC (Attribute-Based Access Control) — les droits d’accès sont définis par des attributs contextuels : classification du document, département propriétaire, niveau de sensibilité, date de publication.

La porte de pertinence comme défense contre la désinformation opérationnelle

La RelevanceGateStage évalue le score de confiance global du contexte récupéré avant génération. En dessous du seuil configuré, le système s’abstient de générer une réponse et le signale explicitement.

Ce comportement d’abstention est une mesure de sécurité opérationnelle : dans un environnement de décision — médical, juridique, industriel, de renseignement —, une réponse mal fondée présentée avec la même apparence qu’une réponse fiable est plus dangereuse que l’absence de réponse. Lexiane préfère la transparence sur l’insuffisance à la production d’une réponse non étayée.

---

Protection des données

Le filtre PII comme barrière de première ligne

Le filtre PII opère en amont de l’intégralité du pipeline de traitement documentaire — avant tout embedding, avant toute indexation, avant tout appel au LLM. Les données personnelles détectées dans les documents ingérés sont traitées selon des politiques configurables : masquage typé, suppression, hachage cryptographique.

L’audit trail enregistre, pour chaque document, les catégories de données personnelles détectées et les politiques appliquées. Ce registre constitue la preuve technique du traitement conforme — exploitable dans le cadre d’un contrôle RGPD.

La résidence des données comme garantie physique

En configuration air-gapped, les données ne quittent pas le périmètre parce que l’architecture le rend physiquement impossible — pas parce qu’un contrat l’interdit. Le binaire ne dispose d’aucune interface réseau active vers l’extérieur. Il n’y a pas de flux à surveiller, pas d’engagement contractuel à auditer : la propriété est mécanique.

Cette distinction — garantie architecturale versus garantie contractuelle — est fondamentale pour les organisations dont les données sont soumises à une exigence de localisation stricte : défense, renseignement, santé, secteur public soumis à des référentiels de cloud souverain.

---

Audit et forensique

Une chaîne SHA-256 inviolable

Chaque action du pipeline est enregistrée dans une chaîne d’audit cryptographique : chaque entrée est signée par le hash SHA-256 de la précédente. Toute modification rétrospective d’un enregistrement — suppression d’un accès, altération d’un horodatage, modification d’une politique appliquée — brise la chaîne et est mathématiquement détectable.

En cas d’incident de sécurité, cette chaîne permet une reconstruction forensique complète : qui a accédé à quoi, à quel moment, avec quel résultat, selon quelle politique de filtrage. L’investigation ne dépend pas de la disponibilité de logs applicatifs qui pourraient avoir été altérés ou supprimés. La chaîne est la preuve.

Événements enregistrés :

Événement	Données enregistrées
Document ingéré	Identifiant, hash du contenu, horodatage, collection
Données personnelles détectées	Catégories, politique appliquée, position dans le document
Requête utilisateur	Identifiant utilisateur, texte de la requête, horodatage
Documents récupérés	Identifiants, scores de pertinence, accès accordé ou refusé
Réponse produite	Hash de la réponse, sources citées, score de fidélité
Guardrail déclenché	Type de guardrail, motif de blocage, identifiant utilisateur

Absence de canaux de fuite par les journaux

Un vecteur de fuite de données couramment négligé dans les systèmes IA est la journalisation applicative : des données sensibles présentes dans les requêtes ou les réponses qui se retrouvent en clair dans les logs système. Lexiane interdit par convention de développement l’utilisation de println!() dans l’ensemble du code de production. Toute émission de logs passe par le framework tracing, avec des niveaux de verbosité contrôlables et des filtres de structuration. Cette propriété est vérifiée en intégration continue.

---

Ce que votre équipe sécurité peut vérifier

La sécurité de Lexiane ne repose pas sur des affirmations. Chaque propriété est soit vérifiable dans le code source, soit vérifiable dans les artefacts de build, soit démonstrable par inspection du binaire.

Propriété de sécurité	Mécanisme de vérification
Absence de code unsafe dans le noyau	#![forbid(unsafe_code)] — inspection du code source
Absence de unwrap() / panic!() en production	Test automatisé en CI — résultat vérifiable dans la suite de tests
Zéro dépendance vendor dans le noyau	Test automatisé à la compilation — vectrant-core/Cargo.toml inspectable
Intégrité de l’audit trail	Propriété cryptographique SHA-256 — vérifiable algorithmiquement
Filtrage PII avant indexation	Position dans le pipeline — inspectable dans l’ordre des stages d’ingestion
Contrôle d’accès avant génération	Position du port AccessControl dans le pipeline — inspectable dans l’assemblage
Absence de println!()	Vérifiable par grep sur l’ensemble du code source
Validation statique de la configuration	Propriété de l’assembleur — inspectable dans les tests d’assemblage
Aucun appel réseau en mode air-gapped	Inspectable dans la configuration des adaptateurs actifs

---

Questions fréquentes des équipes sécurité et RSSI

Avez-vous réalisé un pentest sur Lexiane ? Les résultats d’un audit de sécurité externe sont disponibles à la demande dans le cadre d’une discussion qualifiée. Les propriétés mécaniques décrites dans ce document — absence de code unsafe, surface d’attaque réduite au binaire, chaîne d’audit inviolable — sont vérifiables indépendamment par votre équipe sécurité ou par un prestataire de votre choix.

Lexiane est-il conforme au référentiel OWASP LLM Top 10 ? L’architecture de Lexiane adresse directement les catégories LLM01 (injection de prompt via InputGuardrail), LLM02 (validation des sorties via OutputGuardrail et FaithfulnessChecker), LLM06 (filtrage PII et AccessControl avant génération), et LLM09 (porte de pertinence et abstention). L’évaluation complète de conformité OWASP pour votre déploiement spécifique reste à réaliser selon votre contexte.

Comment gérer les secrets — clés API, tokens — dans la configuration ? Lexiane suit la convention api_key_env : les champs de configuration référencent le nom de la variable d’environnement contenant la clé, jamais la clé elle-même. Les secrets ne transitent pas dans les fichiers de configuration TOML. Ils sont injectés via les variables d’environnement au démarrage — compatibles avec les gestionnaires de secrets standard (Vault, Kubernetes Secrets, AWS Secrets Manager).

Quelle est la politique de gestion des dépendances et des CVE ? Les dépendances du projet font l’objet d’un audit de sécurité automatisé (cargo audit) en intégration continue. Les CVE détectées dans les dépendances déclenchent une alerte immédiate. Le nombre de dépendances actives est maintenu aussi bas que possible — chaque dépendance ajoutée est une décision délibérée, pas un effet de bord.

Peut-on déployer Lexiane dans un environnement avec un pare-feu applicatif (WAF) ? Oui. L’API REST de Lexiane est une API HTTP standard, compatible avec tous les WAF du marché. En configuration air-gapped, la question du WAF s’applique uniquement aux flux internes — Lexiane lui-même n’initie aucun flux réseau sortant.

Comment isoler les droits d’accès entre plusieurs équipes utilisant le même déploiement Lexiane ? Le port AccessControl permet une segmentation des droits au niveau documentaire. Les documents ingérés peuvent être étiquetés avec des attributs de classification (RBAC ou ABAC), et les droits d’accès sont vérifiés à la récupération — avant que le contexte ne soit transmis au modèle. Plusieurs équipes peuvent partager une même infrastructure sans que leurs corpus documentaires ne se mélangent dans les réponses.

---

Engager la conversation sur votre modèle de menace.

La sécurité d’un système IA se construit sur une analyse de menace propre à votre contexte : votre secteur, votre modèle d’accès utilisateur, votre infrastructure de déploiement, et vos exigences réglementaires. Nous ne proposons pas d’évaluation générique.

Nous proposons un échange structuré avec une équipe qui connaît les vecteurs d’attaque spécifiques aux systèmes RAG, les contraintes des environnements régulés, et les preuves que l’architecture de Lexiane permet de fournir à vos équipes sécurité.

Ce que vous pouvez attendre :

• Une réponse sous 48h ouvrées
• Un interlocuteur technique qui connaît l’OWASP LLM Top 10, les contraintes des environnements classifiés, et les exigences de certification
• Une cartographie honnête de ce que l’architecture de Lexiane couvre — et de ce qu’il reste à votre responsabilité

→ Prendre contact

Aucun engagement commercial. Une discussion de sécurité.

---

Références citées dans ce document : — OWASP LLM Top 10, version 1.1 (2023), mise à jour 2025 — owasp.org/www-project-top-10-for-large-language-model-applications — CISA, “The Case for Memory Safe Roadmaps”, décembre 2023 — Google, “Memory Safe Languages in Android 13”, Android Security Blog — NIST AI Risk Management Framework 1.0, janvier 2023 — Règlement (UE) 2016/679 (RGPD)