Skip to content
Governance guide

AI audit trail with a verifiable ledger

An AI audit trail has to answer who asked, what policy said, where the request went and what it cost, for every request and every administrative change, in a form someone outside the system can verify. Skyfix records all of it in a hash-chained ledger with signed checkpoints that verify offline.

  • Hash-chained ledger
  • Offline verification
  • Evidence-required mode
The Governance › Audit page of the Skyfix console: a list of administrative actions described in plain language, each with the actor, category, scope and time, with filters and an export control.The Governance › Audit page of the Skyfix console: a list of administrative actions described in plain language, each with the actor, category, scope and time, with filters and an export control.
Audit trail. Administrative actions recorded in plain language with actor, category and scope, ready to export.Illustrative synthetic data

01

What each record holds

A request record carries the caller and end user, the workspace and key, the alias asked for and the model or tool used, the policy result, the AI Firewall outcome, the budget status, the route reason and any fallback, the provider or server, tokens and cost, latency and status, and the trace ID that links it to the request trace and to your own telemetry. Related records group by trace, session and workflow, so an agent run reads as one chain of decisions.

  • LLM, MCP and A2A decisions in one ledger, with the same fields.
  • Every trace ID resolves to a record or to a declared gap, never to silence.

02

Hash chain and signed checkpoints

  • Root fingerprint

Records are chained by hash, and the chain is checkpointed with a signature under your installation's evidence key. A signed export, taken for any retained window, can be verified offline by an auditor who holds only the export and your installation's root fingerprint: no access to the platform, no trust in the vendor, no network.

03

Evidence-required mode

For workspaces where an unrecorded request is worse than a refused one, evidence-required mode writes and syncs the evidence before the request is acknowledged. If that write fails, the request is refused rather than served unrecorded, and the refusal itself is recorded once the ledger is reachable.

04

Administrative audit

Every administrative action, from a sign-in and a key issue to a policy publication, a prompt promotion, an approval, a posture dismissal or an audit export, is written in plain language with the actor, category, scope and time, in the same database transaction as the action it describes. Exporting audit records requires a recent sign-in, and the export is itself an audited action.

05

Retention and legal hold

Retention windows are set per workspace for traces, captured content and audit records. A legal hold suspends deletion for the records it names, including the backups that contain them, until it is lifted, and placing or lifting a hold is audited.

06

Export to SIEM and OTLP

Security and audit events forward continuously to your SIEM over syslog with TLS or HTTPS; traces export over OTLP with the OpenTelemetry GenAI conventions; the cost view exports in FOCUS format. The ledger export is the signed, verifiable record; the others are the operational feeds derived from the same evidence.

07

Framework evidence

Assessments mapped to frameworks such as the NIST AI RMF, ISO/IEC 42001 and the EU AI Act cite ledger checkpoints, audit exports and inventory entries as their evidence. That is what the audit trail is for: it is the thing an assessment points at. It is not itself a certification, and neither is the assessment.

Framework assessments support evidence for frameworks such as the NIST AI RMF, ISO/IEC 42001 and the EU AI Act. They are not certifications, attestations or compliance scores.

FAQ

Questions this page answers

What should an AI audit trail include?

The caller and end user, the key, the alias and model or tool used, the policy result, the firewall outcome, the budget status, the route reason and fallback, the provider, tokens and cost, latency, status and a trace ID, for model, tool and agent calls alike, plus every administrative change.

How can an auditor verify the ledger?

With a signed export and your installation's root fingerprint. The hash chain and signed checkpoints verify offline, without access to the platform or trust in the vendor.

What happens if evidence cannot be written?

In evidence-required mode the request is refused rather than served unrecorded. In other workspaces the gap is declared, so a trace ID never resolves to silence.

Why not rely on provider logs?

Provider logs are fragmented by vendor and do not know your policy, budgets, routing or tool calls. A gateway-level ledger keeps the whole decision in one place, under your keys.

How long are records retained?

As long as the per-workspace retention window you set for traces, content and audit records, extended by any legal hold that names them.