Transparency log

Een transparency log is een publieke append-only register van elke hub-key-rotatie + elke uitgegeven EAT + elke audit-pack signatuur. Geïnspireerd op Sigstore Rekor.

Waarom

Stel: de hub wordt gecompromitteerd. Een aanvaller met DB-toegang kan een rogue EAT signeren met de bestaande hub-key, en die EAT is cryptografisch geldig — de agent voert hem uit zonder klagen.

Met een transparency log moet de aanvaller dat EAT ook in een publieke, append-only log zien te krijgen, anders fail de client-side verify. Defense-in-depth: aanvalpath gaat van “kraak één private key” naar “kraak de key + dwing publieke append”.

Defensie- en overheidsklanten met clearance vragen dit expliciet.

Wat wordt geregistreerd

kind	wanneer
`hub_signing_key`	bij elke key-rotatie (handmatig of geplande)
`eat_issued`	bij elke `POST /api/v1/agents/:id/emergency`
`audit_pack_signed`	bij elke monthly Audit Pack signing

Elk entry bevat:

payload_hash — sha256 van het ondertekende object
signature — base64 Ed25519 sig over de payload
prev_entry_hash — sha256 van de vorige entry
this_entry_hash — sha256(prev || payload || timestamp_ns)
public_key_id — fingerprint van de signing key

this_entry_hash chain garandeert dat geen enkele oudere entry kan worden gewijzigd zonder de hele keten daarna te invalidate.

Publieke endpoints

Geen auth. Klanten mogen mirroren naar hun eigen infra (paranoid deployments).

GET /api/v1/transparency/log[?after=N&limit=100]   # paginated list
GET /api/v1/transparency/log/:id                    # single entry
GET /api/v1/transparency/keys                       # all hub pubkeys + first/last_seen

Cache: 10s op de list (snel-bewegend), 1h op single-entry (immutable).

Verifieren met de CLI

curl -fsSL https://get.monsys.ai/monsys-verify-eat-linux-x64 -o monsys-verify-eat
chmod +x monsys-verify-eat

# Auditor of incident-responder ontvangt een EAT (uit agent audit log,
# email-attachment, dashboard export) en wil het buiten monsys verifiëren:
./monsys-verify-eat \
  --log https://api.monsys.ai \
  --pubkey <hub-pubkey-hex-from-out-of-band-source> \
  some-eat.json
# verify: OK
#   log entry id      : 4823
#   kind              : eat_issued
#   subject (nonce)   : 7b3f4...
#   payload_hash      : 9a8b...
#   public_key_id     : 4f2e3a1c
#   signed over       : raw bytes

Exit 0 = OK, 1 = FAIL (signature of chain breekt), 2 = lookup/network error.

Hosten van een eigen mirror

Een klant kan periodiek de log pollen + lokaal opslaan, dan eigen verificaties draaien zonder afhankelijkheid van onze runtime:

# Poll vanaf cursor, append-to-local-file
while :; do
  next=$(cat last_id 2>/dev/null || echo 0)
  curl -fsS "https://api.monsys.ai/api/v1/transparency/log?after=$next&limit=1000" \
    | jq -c '.entries[]' >> monsys-transparency.jsonl
  jq -s 'last | .id' monsys-transparency.jsonl > last_id
  sleep 60
done

Eigen verify script kan dan de hele chain herrekenen + ed25519 verify per entry doen.

Wat het NIET doet

Geen Merkle inclusion proofs (v1): voor v1 gebruiken we een simpele hash chain. Merkle tree + inclusion proofs komen in v2. Praktisch verschil: v1 vereist de hele log voor verify; Merkle staat partial-log verify toe.
Geen 3rd-party witness signatures: ook v2. Voor nu vertrouw je dat monsys.ai’s transparency-server de chain niet retroactief herschrijft. Tegenmaatregel: klant runt eigen mirror (zie boven).
Geen automatische browser-extensie verify: CLI dekt v1; extensie komt later voor enterprise klanten.

Genesis

Entry #1 is altijd {kind: 'hub_signing_key', subject_ref: 'genesis', prev_entry_hash: '0x00...'}. Het hash van deze entry is hardcoded verifieerbaar: aeebad4a796fcc2e15dc4c6061b45ed9b373f26adfc798ca7d2d8cc58182718e (= sha256(‘genesis’)).