Aller au contenu
monsys.ai

AI Explain — comment ça marche, ce que ce n'est pas

Le bouton Verklaar dit / Explain this / Expliquer sur chaque alerte, ligne de log et événement de détection appelle un modèle Llama 3.1 8B hébergé localement — aucun fournisseur d’IA externe ne se trouve sur le chemin. Cette page documente comment cela fonctionne, ce qu’il fait bien, où il peut se tromper, et ce que nous avons fait pour réduire ce risque.

Architecture

opérateur clique "Expliquer"
    ↓
dashboard POST /api/v1/ai/explain   (cookie-authed, tenant pin)
    ↓
hub construit un prompt STRUCTURÉ :
    ├─ métadonnées host  (dernière inventory snapshot : OS, noyau, hostname)
    ├─ ligne de grounding (cherchée dans ai_explain_grounding selon alert
    │                     category / detection rule_kind / integrity kind
    │                     / log keyword)
    ├─ la ligne elle-même
    └─ règle stricte :   "si incertain, réponds 'inconnu' au lieu
                         d'inventer"
    ↓
POST http://127.0.0.1:11434/api/generate  (container ollama, llama3.1:8b)
    ↓
le dashboard rend :
    ├─ sortie du modèle (gauche)
    ├─ bandeau d'honnêteté ("Généré par IA, vérifiez")
    ├─ lien vers la doc source si grounding trouvé
    └─ panneau Vérifier (droite) — VRAIE télémétrie récente, sans IA

Souveraineté : Ollama tourne sur le même VPS que le hub. Aucune connexion sortante vers OpenAI/Anthropic/Google/etc. sur le chemin explain. Le container s’appelle monsys-ollama et écoute uniquement sur 127.0.0.1:11434.

Ce que le modèle fait bien (~80% des logs typiques)

  • Patterns syslog standard vus dans son entraînement : sshd: Failed password, kernel: Out of memory, systemd: Failed to start, segfault, EAGAIN/EPIPE/etc.
  • Concepts : signaux, syscalls, comportement de l’OOM-killer, règles firewall courantes, ce que fait un handshake TLS.
  • Tâches admin Linux/Windows génériques où la commande pertinente est dans la toolset standard (systemctl, journalctl, lsof, …).

Ce que le modèle fait mal — et comment on l’atténue

PiègeCe qui peut foirerAtténuation
Commandes distro-spécifiquesSuggère apt install sur un Rocky 9 parce qu’il pattern-matche “Linux”.Le bloc host metadata du prompt injecte l’OS+version exact depuis la dernière inventory snapshot, donc le modèle choisit le bon package manager.
Termes monsys-spécifiquesAucune idée de ce que veulent dire dep.maintainer_changed, mtls_cn_mismatch, kernel_module_suspicious — ce n’est pas dans son training.RAG : ai_explain_grounding stocke du contenu autoritaire par alert category / rule_kind / integrity kind. Le modèle paraphrase plutôt que de deviner.
CVEs post-cutoffHallucine sur des advisories publiés après l’entraînement de Llama 3.1 (ex. PinTheft / PSA-2026-00022-1).La ligne de grounding pour la detection rule inclut l’ID d’advisory et un pointeur de remédiation.
SurconfianceLe modèle 8B formule tout avec la même autorité, même quand il invente à 100%.Règle prompt stricte : “si tu n’es pas 100% sûr d’un paquet, chemin ou commande spécifique, réponds ‘inconnu’ au lieu d’inventer”. + Bandeau d’honnêteté dans l’UI.
Single point of failure sur mauvais conseilL’opérateur suit l’avis IA aveuglément.Le panneau Vérifier rend les vraies dernières-24h alertes, détections et anomalies du même agent à côté de la sortie du modèle. Lien vers la doc source quand le grounding s’est déclenché.

Comment vérifier sur votre propre hôte

Après le prochain cycle d’inventaire de l’agent :

Fenêtre de terminal
# 1. Regardez la table de grounding — qu'est-ce que le hub seed ?
sudo docker exec monsys-postgres psql -U monsys -d monsys -c \
  "SELECT match_kind, match_key, source_url FROM ai_explain_grounding ORDER BY match_kind, match_key;"


# 2. Confirmez que le hub n'appelle qu'ollama local sur les explain :
sudo journalctl -u monsys-hub --since "10 min ago" | grep -i ollama


# 3. Confirmez l'absence de trafic vers un fournisseur IA externe :
sudo ss -tnp | grep -E "(openai|anthropic|google|cohere)"   # devrait être vide

Quand vous NE devez PAS faire confiance à la réponse

  • Tout ce qui mentionne un numéro de version patchée spécifique (“upgrade vers X.Y.Z”). Le modèle 8B devine souvent ces chiffres. Cross-checkez avec le lien de doc source ou l’onglet pipeline CVE.
  • Tout ce qui mentionne un chemin que le modèle n’a pas pu voir (“la config est à /etc/foo/bar.conf”). Il a pattern-matché une appli similaire — validez localement d’abord.
  • Claims de confiance sur un exploit one-shot. Le modèle ne peut pas distinguer exploitation active de bruit de log. Regardez toujours le reste de l’event de détection (src_ip, count, window_secs) avant d’appuyer sur le bouton EAT de mitigation.

Configuration

Pour ajouter une ligne de grounding (par ex. pour une nouvelle alert category que votre tenant produit) :

INSERT INTO ai_explain_grounding
  (match_kind, match_key, content_nl, content_fr, content_en, source_url, priority)
VALUES (
  'alert_category', 'votre.category',
  'Texte NL que le modèle doit paraphraser…',
  'Texte FR…',
  'Texte EN…',
  'https://docs.votre-tenant.com/article',
  100
);

Valeurs match-kind : alert_category, detection_rule, log_keyword, integrity_kind. Priorité plus élevée = priorité gagne quand plusieurs lignes matchent.

Roadmap (pas encore livrée)

  • Option modèle plus gros : 70B / mixtral 8x7B pour tenants avec la RAM-VPS. Même API Ollama ; juste OLLAMA_MODEL=....
  • Confidence-sampling : re-prompter avec une température différente et flagger les réponses inconsistantes comme “low confidence”.
  • Overrides de grounding par tenant : permet à un tenant d’injecter son propre contenu de runbook pour une alert category dont il se soucie.