Phase de production

Audit agents IA en production — Risques runtime

Semantic drift silencieux, model poisoning documenté trop tard, supply chain compromise, monitoring absent. Après déploiement : instruments IA pour détecter les anomalies comportementales et répondre aux incidents.

Un agent déployé n'est pas un agent gelé. Le modèle se dégrade, les données en production divergent du training set, les dépendances externes (APIs, modèles tiers) changent sans notification. Le monitoring du LLM n'est pas le monitoring classique : on regarde la sémantique des réponses, pas juste les latences.

OWASP LLM liste les risques spécifiques à la production (Training Data Poisoning, Supply Chain, Model Theft). Cet audit en couvre quatre critiques.

OWASP LLM03 · MITRE ATLAS

Semantic Drift

Élevé
Définition

Le modèle fine-tuné dérive graduellement de son comportement initial. Cause : données de production divergent du training set. Exemple : agent d'assistance client entraîné sur tickets mai 2024 → en décembre 2024, voit patterns radicalement nouveaux (produit lancé en août) → réponses deviennent incohérentes.

Manifestations
  • Taux erreurs augmente graduellement
  • Réponses déraisonnables spécifiques
  • Factualité en baisse (hallucinations)
  • Comportement imprévisible sur edge cases
Détection difficile

Contrairement à un crash applicatif, semantic drift est graduel et invisible aux métriques standard (latence, uptime). Seule une évaluation sémantique continue le détecte.

Remédiations
  • Evaluation suite LLM-as-judge continu
  • Factcheck outputs contre KB
  • Monitoring de la distribution d'outputs
  • Re-entraînement sur nouvelles données
Monitoring sémantique : exemple
from datetime import datetime import metrics # Chaque jour : re-évalue sample d'anciens outputs test_set = load_benchmark_test_set() results = evaluate_model(test_set) if results.factuality_score < 0.92: # Threshold alert("Semantic drift detected", severity="P1") trigger_human_review() metrics.log_daily({ "date": datetime.now(), "factuality": results.factuality_score, "hallucinations": results.hallucination_count })
OWASP LLM03 · MITRE ATT&CK

Training Data Poisoning

Élevé
Mécanisme

Attaquant injecte des données malveillantes dans le corpus d'entraînement : exemples annotés incorrectement, fausses étiquettes, instructions cachées. Au re-training, le modèle apprend le poison et l'amplifie.

Vecteurs d'injection
  • Data labeling crowdsourced compromis
  • Dépôt GitHub public (données synthétiques)
  • Logs utilisateur upstream (contamination)
  • Fine-tuning sur données non validées
Difficile à détecter

Le poison est souvent imperceptible (quelques exemples contaminés dans un gros corpus). Les métriques de précision peuvent rester élevées. L'attaque révèle ses intentions graduellement après déploiement.

Remédiations
  • Validation corpus avant training
  • Data lineage tracking complet
  • Anomaly detection sur distributions
  • Sandbox testing avant prod
Data validation pipeline
def validate_training_data(corpus): # Détecte anomalies et contenu suspect anomalies = detect_outliers(corpus) if anomalies.count > corpus.size * 0.001: # >0.1% raise DataQualityException( f"Potential poisoning: {anomalies.count} outliers" ) # Vérifier distribution labels label_dist = corpus.label_distribution() if label_dist.entropy < ENTROPY_THRESHOLD: alert("Suspicious label imbalance")
OWASP LLM05 · MITRE ATLAS

Supply Chain Vulnerabilities

Élevé
Définition

Dépendances externes (modèles open-source, APIs, packages Python) contiennent des vulnérabilités. Exemple : vous fine-tunez sur Llama 2 compromis, ou utilisez une API de modération qui change unilatéralement sans notification.

Vecteurs
  • Modèle open-source mal-vérifié
  • API tiers down ou comprise
  • Package Python + dépendances malveillantes
  • Weights non authentifiés (model theft)
  • Absence de versionning ou pinning
Complexité croissante

Chaque agent IA moderne dépend de 50+ packages externes. Pas de vérification exhaustive possible — il faut une stratégie : pinning strict, audit périodique, fallbacks.

Remédiations
  • Pinning exact versions dépendances
  • Checksums/signatures modèles
  • Audit dépendances (Snyk, pip-audit)
  • Fallback models en cas compromission
Supply chain : gestion sécurisée
requirements.txt: torch==2.1.2 # Exact version, pinned transformers==4.36.0 safetensors==0.4.1 # Checksums verified # CI/CD: pip install -r requirements.txt --no-deps pip audit # Detecte CVEs check_model_checksum(llama2_weights, expected_hash)
OWASP LLM10 · Observabilité

Monitoring insuffisant

Critique
Le problème

Zéro visibilité sur l'agent en production. Pas de logging des requêtes/réponses, pas d'alertes sur comportement anormal, pas de mécanisme d'incident response. On découvre l'attaque 3 semaines après.

Cas réels
  • Agent divulgue PII, non détecté
  • Hallucinations massives silencieuses
  • Appels outils non autorisés passent inaperçus
  • Coûts API explosent (pas d'alerting)
Monitoring LLM ≠ Monitoring applicatif

Pas assez de regarder les logs serveur. Il faut analyser la sémantique de chaque réponse, détecter les patterns dangereux, alerter sur déviation. C'est actif, pas passif.

Remédiations
  • Logging exhaustif input/output
  • LLM-as-judge: score sécurité chaque réponse
  • Alertes seuils : hallucination, PII, toxicité
  • Analyse de tendance (drift détecté)
Observabilité production : minimum
class LLMMonitoring: def log_request(self, user_id, messages, timestamp): self.logger.info({ "user": user_id, "messages": messages, "timestamp": timestamp }) def score_safety(self, response): scores = { "contains_pii": pii_detector(response), "factuality": factcheck_score(response), "toxicity": toxicity_score(response), "hallucination": hallucination_score(response) } for metric, score in scores.items(): if score > THRESHOLD[metric]: alert(f"Safety issue: {metric}", severity="P1") return scores

Observabilité LLM : Implémentez au minimum : logging exhaustif, PII detection, factcheck scoring. Les outils : Giskard (hallucinations), DeepEval (LLM-as-judge), CloudWatch/Datadog (logs centralisés).

Incident response : Ayez un playbook : comment réagir si semantic drift détecté ? Comment rollback modèle ? Comment communiquer ? Testez-le en chaos engineering.

Audit complet : Consultez les deux autres piliers (création d'agents, sécurité LLM) sur l'accueil pour une stratégie end-to-end.

← Retour accueil