Agent payload signing

Sinds de hardening-ronde van mei 2026 ondertekent elke agent zijn ingest-payloads met een eigen Ed25519 keypair. Het hub-side bearer-token alleen is niet voldoende om data namens een agent te pushen — de aanvaller heeft ook de private signing key van de host nodig.

Hoe het werkt

Agent (eerste start)
  ├─ genereert Ed25519 keypair
  ├─ schrijft secret naar /var/lib/monsys/agent-signing.key  (mode 0600)
  └─ stuurt public key naar hub via /api/v1/agents/register
                                          │
                                          ▼
                              Hub pint de key in
                              agents.signing_pubkey
                              (trust-on-first-use)

Agent (elke ingest)
  body = "[{...metrics...}]"
  sig  = base64(Ed25519(SHA256(body)))
  HTTP POST /api/v1/ingest
    Authorization: Bearer ms_...
    X-Monsys-Signature: <sig>

Hub
  pubkey = SELECT signing_pubkey FROM agents WHERE token_hash = …
  als pubkey NULL    → accepteer + log "unsigned_payload" (medium)
  als sig ontbreekt  → 403 + log "unsigned_payload" (high)
  als sig fout       → 403 + log "signature_invalid" (critical)
  anders             → ✓ verwerk

Bestandslocatie

Platform	Pad
Linux	/var/lib/monsys/agent-signing.key
Windows	C:\ProgramData\monsys\agent-signing.key

Permissies op Linux: mode 0600, eigenaar = de user die de agent draait (user/monsys afhankelijk van je install). Windows: ACL beperkt tot SYSTEM + Administrators.

Inhoud is 32 bytes (raw Ed25519 secret seed). Geen header, geen PEM — houd het bestand exact op die grootte.

Trust-on-first-use semantiek

De eerste keer dat een agent een pubkey meestuurt in register, pint de hub hem en zet signing_set_at = NOW(). Daarna is de pin immutable vanuit de agent — een nieuwe pubkey wordt geweigerd én genereert een signature_invalid integrity-anomaly.

Om legitiem te roteren moet een admin de pin expliciet wegzetten via:

POST /api/v1/agents/<id>/rotate-signing-key

(zie Token rotation)

Wat een aanvaller met alleen de bearer token niet kan

Aanval	Geblokkeerd door
Fake metrics pushen onder dezelfde agent	signature mismatch → 403
Honeypot trip vervalsen	signature mismatch → 403
Process DNA hash vervangen	signature mismatch → 403
Versie downgraden in rapportage	signature mismatch → 403, plus version_downgrade integrity check

Wat een aanvaller met token + key file wel kan

Als beide gestolen zijn, kan de aanvaller volledig namens de agent rapporteren. De key file zit echter buiten /etc/ (waar backups van system-config typisch heen gaan), en is mode 0600. Concrete maatregelen om beide niet samen te laten lekken:

• Houd de key file uit backups (backup_exclude in restic / borg)
• Roteer de signing-key na een geconstateerd security event
• Monitor wijzigingen op /var/lib/monsys/agent-signing.key met de host’s eigen FIM (auditd, auditctl -w /var/lib/monsys/agent-signing.key -p wa)

Migratie van bestaande installaties

Een oudere agent zonder signing module blijft werken: de hub accepteert de unsigned payload maar maakt elk uur een unsigned_payload-anomaly aan zodat het niet onopgemerkt blijft.

Upgrade-pad:

# Op de host
sudo apt update && sudo apt upgrade monsys-agent
# Of via install script:
curl -fsSL https://get.monsys.ai/install.sh | sudo bash
sudo systemctl restart monsys-agent

De agent genereert dan zelf een keypair, registreert de pubkey, en de unsigned_payload-anomalies worden vanzelf gesloten in de eerstvolgende integrity-cyclus (10 min).