Ga naar inhoud
monsys.ai

AI Explain — hoe het werkt, wat het niet is

De Verklaar dit / Explain this knop op elke alert, log lijn en detection event draait een lokaal gehoste Llama 3.1 8B model — er gaat geen enkele externe AI provider over het pad. Deze pagina documenteert hoe het werkt, waar het goed in is, waar het fout kan gaan, en wat we hebben gedaan om dat risico te verminderen.

Architectuur

operator klikt "Verklaar"
    ↓
dashboard POSTs /api/v1/ai/explain   (cookie-authed, tenant-pinned)
    ↓
hub bouwt een GESTRUCTUREERDE prompt:
    ├─ host metadata    (laatste inventory snapshot: OS, kernel, hostname)
    ├─ grounding row    (opgezocht in ai_explain_grounding op alert
    │                    category / detection rule_kind / integrity kind
    │                    / log keyword — wat dan ook matcht)
    ├─ de lijn zelf
    └─ strikte regel:   "als je twijfelt, antwoord 'onbekend' in plaats
                         van te raden"
    ↓
POST http://127.0.0.1:11434/api/generate  (ollama container, llama3.1:8b)
    ↓
dashboard rendert:
    ├─ model output (links)
    ├─ eerlijkheid-banner ("AI-gegenereerd, verifieer")
    ├─ bron-link wanneer grounding gevonden
    └─ Verifieer paneel (rechts) — ECHTE recente telemetrie, geen AI

Sovereignty: Ollama draait op dezelfde VPS als de hub. Geen uitgaande connectie naar OpenAI/Anthropic/Google/etc. op het explain-pad. Container heet monsys-ollama en bindt alleen op 127.0.0.1:11434.

Waar het model goed in is (~80% van gangbare logs)

  • Standaard syslog patterns die het in training heeft gezien: sshd: Failed password, kernel: Out of memory, systemd: Failed to start, segfault, EAGAIN/EPIPE/etc.
  • Concepten: signals, syscalls, OOM-killer gedrag, gangbare firewall regels, wat een TLS handshake doet.
  • Generieke Linux/Windows admin taken waar het juiste commando in de standaard toolset zit (systemctl, journalctl, lsof, …).

Waar het model slecht in is — en hoe we het mitigeren

ValkuilWat kan misgaanMitigatie
Distro-specifieke commando’sStelt apt install voor op een Rocky 9 host omdat hij pattern-matcht op “Linux”.Host metadata block in de prompt injecteert exact OS+versie uit de laatste inventory snapshot, zodat het model de juiste package manager kiest.
Monsys-specifieke termenGeen idee wat dep.maintainer_changed, mtls_cn_mismatch, kernel_module_suspicious betekenen — die zitten niet in zijn training data.RAG: ai_explain_grounding bewaart authoritatieve content per alert category / rule_kind / integrity kind. Het model parafraseert die content in plaats van te raden.
Post-cutoff CVEsHallucineert over advisories gepubliceerd na de training (bv. PinTheft / PSA-2026-00022-1).Grounding-rij voor de detection rule bevat het advisory-ID en remediation pointer.
Vals vertrouwenHet 8B model formuleert alles met dezelfde autoriteit, ook wanneer het 100% raadt.Strikte prompt-regel: “als je niet 100% zeker bent over een specifiek pakket, pad of commando, antwoord ‘onbekend’ in plaats van uit te vinden”. + Eerlijkheid-banner in de UI.
Single point of failure op slecht adviesOperator volgt het AI-advies blind in tijdsdruk.Verifieer paneel toont de echte laatste-24u alerts, detections en anomalies op dezelfde agent naast de model-output. Bron-link wanneer grounding vuurde.

Hoe verifiëren op je eigen host

Na de volgende agent inventory cyclus:

Terminal window
# 1. Bekijk de grounding tabel — wat seedt de hub?
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. Bevestig dat de hub alleen lokaal ollama aanroept op explain calls:
sudo journalctl -u monsys-hub --since "10 min ago" | grep -i ollama


# 3. Bevestig geen uitgaand AI-provider verkeer:
sudo ss -tnp | grep -E "(openai|anthropic|google|cohere)"   # zou leeg moeten zijn

Wanneer je het antwoord NIET moet vertrouwen

  • Alles met een specifiek patched versie nummer (“upgrade naar X.Y.Z”). Het 8B model gokt deze vaak. Cross-check met de bron-doc-link of de CVE pipeline tab.
  • Alles dat een pad noemt dat het model niet kon zien (“de config staat in /etc/foo/bar.conf”). Het heeft gepatterned op een soortgelijke app — valideer eerst lokaal.
  • Vertrouwens-claims over een one-shot exploit. Het model kan actieve exploitatie niet onderscheiden van log-ruis. Kijk altijd eerst naar de rest van het detection event (src_ip, count, window_secs) voordat je de EAT mitigatie-knop drukt.

Configuratie

Een grounding rij toevoegen (bv. voor een nieuwe alert category die jouw tenant shipt):

INSERT INTO ai_explain_grounding
  (match_kind, match_key, content_nl, content_fr, content_en, source_url, priority)
VALUES (
  'alert_category', 'jouw.category',
  'NL-tekst die het model moet parafraseren…',
  'FR-tekst…',
  'EN-tekst…',
  'https://docs.jouw-tenant.com/artikel',
  100
);

Match-kind waarden: alert_category, detection_rule, log_keyword, integrity_kind. Hogere priority wint bij meerdere matches.

Roadmap (nog niet geshipt)

  • Grotere model optie: 70B / mixtral 8x7B voor tenants met de VPS-RAM. Zelfde Ollama API; alleen OLLAMA_MODEL=....
  • Confidence-sampling: re-prompt met andere temperature en flag inconsistente antwoorden als “low confidence”.
  • Per-tenant grounding overrides: laat een tenant hun eigen runbook content injecteren voor een alert category die ze belangrijk vinden.