Audit Log

The Audit Log is Scrydon's organization-facing source of record for compliance, incident response, and forensic review. It combines three kinds of evidence in one ordered timeline:

See the Audit Log catalogue for every accepted action and resource type.

Common event envelope

Every list row, export line, and Log Receiver delivery has the same versioned shape:

The envelope has two schema versions, told apart by schemaVersion:

A version 3 anonymous actor carries identifierHash: null: the telemetry store does not keep the identifier hash. A decoder that accepts only version 2 must skip version 3 lines rather than fail on them.

Authorization decisions

Scrydon records every authorization outcome—allowed, denied, or indeterminate—for read, write, delete, execute, administration, and retirement operations. An indeterminate result means Scrydon could not obtain a trustworthy policy answer; protected operations fail closed and return the stable AUTHZ_UNAVAILABLE error where the API exposes an error code.

Authorization evidence distinguishes the evaluated subject from the producer. The subject is the user, service account, workload, execution grant, or system identity whose access was checked. The producer is the authenticated Scrydon workload that submitted the evidence. Organization decisions join that organization's integrity chain; decisions without an organization use an explicit platform-global scope.

API Platform atomically commits each decision and its idempotency ledger before returning. If evidence cannot be persisted, the request returns 503 and the protected operation does not run. Retrying with the same stable decision key deduplicates an identical request; conflicting reuse returns 409. The general event backbone used for workflow synchronization is separate from this evidence path.

Example

{
  "id": "9ecb19b1-...",
  "schemaVersion": 2,
  "type": "audit",
  "dataVersion": 1,
  "scope": { "kind": "organization", "id": "org_001" },
  "action": "SECRET_ACCESS",
  "resource": { "type": "secret", "id": "sec_xyz789" },
  "actor": { "kind": "user", "id": "usr_456" },
  "producer": { "appId": "agentic", "spiffeId": "spiffe://..." },
  "sourceEventId": "secret-access:req_123",
  "occurredAt": "2026-07-16T10:30:00Z",
  "recordedAt": "2026-07-16T10:30:00.120Z",
  "correlation": { "requestId": "req_123", "sessionId": null, "traceId": null, "workflowInstanceId": null },
  "classification": null,
  "data": { "metadata": { "strategy": "LOCAL" } },
  "proof": { "hashVersion": 2, "chainScopeKey": "org:org_001", "chainSequence": 42, "previousRowHash": "...", "rowHash": "..." },
  "redacted": false
}

Reading and verifying evidence

Organisation owners and admins open Settings → Platform → Audit Log. The Events tab filters by event type, action, and resource, and selecting any row opens its full evidence view. The shield column shows the row's proof state; the shield action in the toolbar verifies a time window without leaving the event list. The page URL preserves the current tab or integrity drawer in its fragment, for example #receivers, #policy, or #integrity.

Chain verification covers governance events only. A telemetry event shows Verify attestation window in its evidence view instead: Scrydon checks the window's ML-DSA-65 signature, its row count and Merkle root, and recomputes a sample of the stored rows. Every event in that window then shows the verdict:

Classified rows are evaluated against the viewer's effective clearance. If the rank is insufficient or classification schemes differ, Scrydon preserves the action, actor, timestamps, and integrity evidence while removing the protected resource context and marking the envelope redacted: true.

Log Receivers and export

The Log Receivers tab sends all event types to a SIEM, data lake, or webhook destination using an HMAC-signed, at-least-once delivery pipeline. A receiver can narrow its filter, but new receivers include audit, workflow, and integrity events by default. The same filters are available for NDJSON export, so a customer can export the complete evidence timeline without joining separate systems. An export includes telemetry events too, merged with governance events oldest first.

A receiver forwards governance events only unless Also forward telemetry is switched on, when it is created or later from its row. Telemetry is the high-volume tier, so the receiver then gets one extra signed request per attested 10-second window: Content-Type: application/x-ndjson, one version 3 envelope per line, with the receiver's filter applied to each line. The same HMAC signature, retries and dead-letter handling apply. Recording every authorization result increases Audit Log and receiver volume in proportion to protected-request traffic; size retention and receiver throughput from observed decision rates rather than denial rates alone.

Retention and integrity

The retention period applies to every copy of the Audit Log, including the high-volume telemetry store when your installation uses one; a change takes effect within a day.

A recent valid tail may temporarily show “awaiting a checkpoint”; that is not an inconsistency. Rows created before the versioned-chain cutover are labelled as legacy and are never presented as cryptographically verified. Dapr 1.18 workflow-history signing is an independent proof system: when enabled by an operator after the required drain and CA-lifecycle preparation, the Audit Log records bounded verification receipts and failures, not raw signature bundles.

Retention is configured per organisation under Audit Log → Policy.

Data that is never recorded

• Secret values
• Knowledge-base document content
• Workflow inputs or outputs
• LLM prompt or response content
• Dapr workflow-history signature bundles

The Audit Log records identifiers, decisions, outcomes, and bounded proof status—enough to establish what happened without duplicating protected payloads.