Intégrer les logs de l'IA dans votre SIEM (Splunk/ArcSight)

Le trou noir de la supervision : vos LLM ne sont pas monitorés

Après plus de 10 ans passés à construire des architectures SIEM pour des OIV (RATP, Orange, Generali), je constate un angle mort récurrent dans toutes les entreprises qui déploient de l'IA : les logs d'inférence des LLM ne remontent pas dans le SOC. C'est le constat que je fais systématiquement en mission, confirmé par les retours du terrain de la communauté SOC.

C'est comme si vous aviez un pare-feu nouvelle génération sans jamais regarder ses logs. Les équipes Data Science déploient des modèles, les équipes IT fournissent l'infrastructure, mais personne ne supervise ce qui se passe entre les deux.

Quels logs collecter et comment

La première étape consiste à identifier les sources de données pertinentes :

• Logs d'inférence : chaque requête envoyée au LLM (prompt utilisateur, tokens consommés, temps de réponse)
• Logs de retrieval : quels documents le RAG a récupérés, avec quels scores de similarité
• Logs d'orchestration : actions exécutées par les agents autonomes (appels d'API, accès fichiers, exécution de code)
• Métriques de coût : consommation de tokens par utilisateur/session pour détecter les abus

Règle #1 — Détection d'injection de prompt (Splunk SPL)

Cette règle analyse les requêtes utilisateur pour détecter les tentatives d'injection de prompt en cherchant des patterns caractéristiques :

Seuil recommandé : alerte si plus de 3 tentatives par utilisateur sur une fenêtre de 15 minutes. La plage earliest=-15m@m latest=now définit cette fenêtre directement dans la recherche. Cela filtre les faux positifs tout en détectant les attaques persistantes. Pour une règle de corrélation en temps réel dans Splunk ES, encapsulez cette recherche dans un Adaptive Response Action ou une Correlation Search avec un scheduler toutes les 5 minutes.

Règle #2 — Exfiltration de données via réponses anormalement longues

Une exfiltration réussie se traduit souvent par des réponses du LLM anormalement volumineuses, contenant des données structurées (JSON, CSV, listes) alors que l'interaction normale produit du texte conversationnel :

Règle #3 — Comportement anormal d'agent autonome (ArcSight)

Les agents IA autonomes (LangChain Agents, AutoGPT) peuvent effectuer des actions sur le SI. Cette règle détecte les séquences d'actions inhabituelles :

Intégration pratique : architecture recommandée

Pour intégrer efficacement ces logs dans votre SIEM existant, je recommande une architecture en 3 couches :

• Couche collecte : middleware de logging entre votre application et l'API LLM (intercepteur Python ou proxy dédié)
• Couche transport : Syslog-NG ou Kafka pour le transport vers le SIEM (même pipeline que vos logs existants)
• Couche analyse : dashboards dédiés "AI Security" dans votre SIEM, avec les 3 règles ci-dessus en alertes temps réel

Cette approche s'intègre dans votre SOC existant sans créer de silo — les analystes N1/N2 traitent les alertes IA comme n'importe quelle autre alerte sécurité.

Pour aller plus loin

• OWASP Top 10 for LLM Applications 2025 (v2.0) — référentiel de vulnérabilités LLM, dont LLM01 (Prompt Injection) couvre les vecteurs détectés par ces règles
• MITRE ATLAS — équivalent ATT&CK pour les systèmes IA, utile pour aligner vos use cases de détection sur les TTP IA recensées
• Splunk SPL Reference — documentation officielle du langage de recherche Splunk