White paperGoverning AI agents in production: policies, human approvals and an emergency stop.Read the white paper

Article · Traceability

A tamper-evident audit trail for every AI call

Every call that crosses a Navin Enterprise AI gateway carries a W3C traceparent and produces OpenTelemetry spans, a Usage Event and an audit event chained by hash. Here is how the chain is built, sealed, archived in WORM storage and replayed.

Published on 3 min read

An auditor asks two questions: what happened, and can you prove that nobody changed the record afterwards? Navin Enterprise AI answers both with unified telemetry. Every call through a gateway carries a W3C traceparent, emits OpenTelemetry spans, produces a Usage Event and writes an audit event chained by hash to the previous one.

One hash chain per tenant

Each audit event is linked by its hash to the event before it in the same chain, so changing, inserting or deleting an event breaks every link that follows. The chain is stored in PostgreSQL under row level security and can be verified at any time by the verification service of the audit API. Security events are written to the audit chain of the tenant, in their own transaction.

Sealing follows a strict rule: a seal is never earlier than the events it covers. If the wall clock moves backwards between ingestion and sealing, after an NTP correction for instance, the seal takes the time of the latest sealed ingestion, and verification keeps the strict check that every event was ingested before its seal.

Evidence that cannot be rewritten

Audit evidence is archived in object storage with Object Lock in WORM mode: once archived, it can be neither modified nor deleted before its retention ends. In an installation run by the Navin Manager, SeaweedFS is the object storage that holds this WORM audit archive, next to documents, media, exports and backups.

  • W3C traceparent on every call, propagated across gateways and runtimes.
  • OpenTelemetry spans collected by the OTel Collector, AI traces in Opik.
  • Usage Events for tokens, seconds and GPU time, the basis of FinOps.
  • OpenLineage events for data lineage, for example on every RAG query.

Replaying an execution

Agent runs write a checkpoint at every step. Execution replay (brick C15) relies on them to reconstruct what an agent did, step by step, and the execution contract of the run, available at GET /v1/runs/{id}, describes how it went. Audit correlation (brick G14) then brings together the records of the different services.

  • DatasheetAgents

    Isolated MCP runtimes per user and project

    The MCP registry and gateway decide who may use which server; the MCP runtime creates isolated instances on demand on the ToolHive Kubernetes Operator and destroys them after use. Every tool call still goes through policy, DLP and approval.

    2 min read
  • DatasheetSecurity

    Mandatory file scanning with ClamAV and YARA-X

    Every file sent to the AI is quarantined, scanned by ClamAV and YARA-X and then validated before Docling, OCR or RAG can read it. Fully local, fail closed, logged and highly available.

    2 min read
  • White paperGovernance

    Governing AI agents in production

    How Navin Enterprise AI keeps autonomous agents under control: OPA policies stacked from platform to tenant to project, approvals with a human in the loop, a kill switch available at any time and a governance registry as the single source of truth.

    25 min read

See these principles applied to your use cases

An architect presents the platform against your own constraints.