Audit Webhooks

Signed event streams

Webhook consumers receive signed events. The signature lets your consumer verify the event originated from the mesh and was not tampered with in transit — treat unsigned or mismatched events as suspicious input and drop them. Configure a dedicated, HTTPS-only receiver per environment, and rotate the signing key on the same schedule as other credentials.

  POST https://sink.example.com/rizoma/events
  Content-Type: application/json
  X-Rizoma-Signature: <signature>

  {
    "id": "evt_...",
    "type": "mesh.enrollment.created",
    "actor": { "kind": "setup-key", "id": "first-wave" },
    "target": { "kind": "node", "id": "node-03" },
    "timestamp": "2026-08-18T10:02:11Z"
  }

What the events cover

The event catalog spans the surfaces that matter for review and compliance:

• Enrollment changes — nodes joining, leaving, or re-keying the mesh.
• Access policy updates — ACL, team, group, and firewall rule changes.
• Product provisioning — workloads, storage, and services being created or removed.
• Git activity — code changes, CI runs, package publishes, and access events.
• Router configuration changes — gateway, NAT, and zone policy edits.
• Backup and restore operations — snapshot creation, restore attempts, and outcomes.

Consumer guidance

Event streams are exactly that — streams, not transactions. Build consumers accordingly:

• Idempotency — events can be redelivered; deduplicate by event ID.
• Retries — treat delivery failures as alerting conditions, not silent losses.
• Ordering — don't assume global ordering across event types; correlate by actor, target, and timestamp.
• Verification — reject unsigned events and rotate receiver secrets like any credential.