AUDITOR · EVIDENCE

Reviewing a tenant without production access

The client gives you no shell, no admin dashboard. But: cryptographically signed evidence that you verify offline. Five concrete checks an auditor runs every quarter.

Full docs
01

Verify the monthly Audit Pack offline

Client emails you a .jsonl.gz + .pdf + .sig. How do you know the PDF comes from the monsys runtime, not from the client's editor?

  1. Sidebar → Audit Packs
  2. Download .jsonl.gz + .sig for the month
  3. Click 'Download verify-CLI'
  4. Run CLI locally — green checkmarks

manifest_hash, hash chain root, and Ed25519 signature all live in the same .sig file. Independently validatable.

Same via API (bash) — for automation
wget https://get.monsys.ai/monsys-verify-eat-linux-x64
chmod +x monsys-verify-eat-linux-x64

./monsys-verify-eat-linux-x64 verify-pack \
  --pack 2026-04.jsonl.gz \
  --sig  2026-04.sig \
  --pubkey  https://transparency.monsys.ai/pubkeys/hub.pub
# ✓ manifest_hash matches signature
# ✓ hash chain root matches manifest
# ✓ Ed25519 signature valid against pubkey 7c34a9e2b1f0…
# ✓ 1247 entries in pack, 0 tampered
02

Prove CVE-2026-XXXX was patched within 7 days

Auditor wants per host: when first detected, when patched, who executed the action, and how much time in between.

  1. Sidebar → Kernel CVEs → search CVE-2026-XXXX
  2. 'Timeline' tab → per host: detected, patched, operator
  3. Filter 'Time to patch > 7 days'
  4. 'Export for audit' button → CSV

Every EAT-triggered reboot sits in kernel_reboot_history with expected=true + link to eat_id for the operator trail.

Same via API (sql) — for automation
WITH first_detected AS (
  SELECT agent_id, MIN(detected_at) AS first_seen
    FROM kernel_cve_findings
   WHERE tenant_id = $1::UUID AND cve_id = 'CVE-2026-XXXX'
   GROUP BY agent_id
),
patched AS (
  SELECT r.agent_id, MIN(r.boot_time) AS rebooted_at, r.eat_id
    FROM kernel_reboot_history r
    JOIN first_detected fd ON fd.agent_id = r.agent_id
   WHERE r.tenant_id = $1::UUID
     AND r.expected = true AND r.boot_time > fd.first_seen
   GROUP BY r.agent_id, r.eat_id
)
SELECT a.hostname, fd.first_seen, p.rebooted_at,
       p.rebooted_at - fd.first_seen AS time_to_patch,
       u.email AS operator
  FROM first_detected fd
  LEFT JOIN patched p ON p.agent_id = fd.agent_id
  LEFT JOIN agents  a ON a.id = fd.agent_id
  LEFT JOIN emergency_tokens et ON et.id = p.eat_id
  LEFT JOIN users u ON u.id = et.user_id
 ORDER BY time_to_patch NULLS FIRST;
03

List every privileged action last quarter

Compliance question: which human actions were executed on production between X and Y, and who was the actor.

  1. Sidebar → Audit log (under MANAGE)
  2. Filter: event_type='emergency_token_issued' + Q1 range
  3. Per row: operator, agent, actions, exit_code
  4. 'Verify in transparency log' button opens external verifier

Every nonce in this list is also in the public transparency_log. Re-verifiable offline via the verify-eat CLI.

Same via API (sql) — for automation
SELECT et.issued_at, u.email AS operator,
       a.hostname AS target, et.level,
       et.actions::TEXT AS actions, et.reason,
       (et.result->>'exit_code')::INT AS exit_code
  FROM emergency_tokens et
  LEFT JOIN users  u ON u.id = et.user_id
  LEFT JOIN agents a ON a.id = et.agent_id
 WHERE et.tenant_id = $1::UUID
   AND et.issued_at >= '2026-01-01' AND et.issued_at < '2026-04-01'
 ORDER BY et.issued_at DESC;
04

Verify cryptographic integrity of one specific row

Client could modify a single row in the JSONL.gz after the fact before sending it to you. How do you detect that?

  1. Open Audit Pack download view
  2. Click 'Tamper check tool' (client-side verifier)
  3. Paste the suspect JSONL line
  4. UI shows expected vs computed hash + verdict

Hash chain root is in the manifest. Manifest hash is in the .sig. Tampering propagates all the way to the Ed25519 signature.

Same via API (bash) — for automation
zcat 2026-04.jsonl.gz | sed -n '847p' > suspicious-line.json
sha256sum suspicious-line.json
# 7c34a9e2b1f0…

zcat 2026-04.jsonl.gz | \
  ./monsys-verify-eat-linux-x64 chain-position --line 847
# expected_position: 7c34a9e2b1f0…
# computed_position: 7c34a9e2b1f0…
# ✓ line 847 matches the chain
05

How long do we keep evidence — NIS2 minimum 12 months

Belgian NIS2 transposition requires minimum 12 months of audit evidence. The Trust Score evidence_continuity component penalises tenants below that.

  1. Sidebar → Trust Score → Evidence continuity component
  2. Table shows oldest/newest row per evidence table
  3. Green >12m, red <12m visible at a glance
  4. Click red row → remediation suggestions

The Trust Score v1.2 / tenant view shows the evidence_continuity score live — the auditor sees this dashboard directly.

Same via API (sql) — for automation
SELECT 'audit_log' AS table_name,
       MIN(created_at) AS oldest,
       MAX(created_at) AS newest, COUNT(*) AS rows
  FROM audit_log WHERE tenant_id=$1::UUID
UNION ALL
SELECT 'emergency_tokens',
       MIN(issued_at), MAX(issued_at), COUNT(*)
  FROM emergency_tokens WHERE tenant_id=$1::UUID
UNION ALL
SELECT 'transparency_log',
       MIN(appended_at), MAX(appended_at), COUNT(*)
  FROM transparency_log WHERE tenant_id=$1::UUID;

Other roles

Read the extended practical docs