Record what your AI did, and verify the record. Evidence you can check, not a log you have to trust.
Calls routed through DVARA leave a typed event carrying the caller, the model or tool, the policy decision and the outcome. Each is HMAC-signed over the previous event's hash, so an altered or missing record is detectable rather than invisible. That is evidence for an audit — it is not compliance, and this page is careful about the difference.
A local unsigned log runs keyless; the signed chain, SIEM export and reports are licensed.
What does an auditor actually ask for?
Who called what, under which policy, and what came back — plus some reason to believe the record has not been edited since. Application logs carry none of that: no policy decision, no integrity property, and no shape an assessor recognises. Closing that gap is a narrower job than becoming compliant, and it is the job DVARA does — the evidence, not the attestation.
What ends up in the trail, and what stays out of it?
Typed events for calls and for the decisions taken on them — with the identifiers and outcomes an assessor asks about, and deliberately without the content that would make the log itself a liability.
Every request through the data plane writes a response event with the model, provider, HTTP status, latency, token counts, a masked API key, the tenant, the policy decision, and any error code. Each event carries its own ID, timestamp, tenant, and type.
Policy denials, PII detections and redactions, guardrail blocks and flags, MCP injection findings, agent loop detections, approval decisions, budget breaches, and administrative changes each have their own event type rather than being folded into one record.
The data-plane event is written on the way out, after the response. That makes it a record of what happened rather than what was attempted — enforcement decisions that stopped a call earlier write their own events at the point they fired.
Guardrail events carry the category, label, risk score and rule ID rather than the text that matched. PII events carry entity types and counts, never the values. Cost records carry token counts, not content.
Agent-to-agent hops are recorded on their own chain in their own store, so they do not appear in the shared audit query or viewer — they have their own. They do reach the SIEM exporters and the compliance reports alongside everything else.
Query by tenant, event type, and date range through the console or the admin API, and export the result as CSV or JSON.
What does the chain actually prove?
Something narrower than “the log is true” and stronger than the page used to claim. Worth reading in full if you are the person who will be asked to explain it.
A canonical string built from the event ID, its timestamp, the tenant, the event type, the payload with its keys sorted, and the previous hash — signed with HMAC-SHA256. Sorting the payload is what makes the same event produce the same signature twice.
You do. The signing secret is configuration you supply to the deployment. DVARA does not hold it, and that also means protecting and rotating it is yours.
Each gateway pod maintains its own chain, and each run of that pod is its own segment. Position within a segment starts at one, so a missing number is positive evidence that an event a pod signed never arrived — a single global counter cannot say that, because nothing was in transit to be lost.
The store also assigns a monotonic arrival number, which is what "newest first" listings and exports order by. It is not the chain position, and treating it as one is the mistake this page previously made.
An altered event, because its signature no longer matches. A removed event, because the chain no longer links. A missing event from a known writer, because its position is absent. Verification is a scheduled job over the chain, and comparison is constant-time.
It does not prove the event was true when written, does not stop someone with database access from deleting rows — it makes the deletion detectable — and does not by itself make a record legally admissible. Append-only is enforced through the API, which is a statement about the API.
How does a call become a record?
Six steps, and two things worth noticing: enforcement decisions write their own events even when the call never reached a provider, and the data-plane event is written on the way out.
- 1
A governed call reaches an enforcement point
A model call at the LLM Gateway, a tool call at the MCP Gateway, or a hop at the A2A Gateway. Only traffic that routes through one of them is in the record at all.
- 2
Enforcement decisions write their own events
A policy denial, a PII detection, a guardrail block, a loop detection or an approval decision each writes an event when it fires — including for calls that never reached a provider.
- 3
The response event is written on the way out
The data-plane event records what actually happened: the model and provider used, the status, latency, tokens, the tenant, and the policy decision.
- 4
The event is signed onto its pod’s chain
The canonical form is HMAC-signed with the previous hash included, and given its position in that pod’s current segment. It is persisted, and it is also written to stdout for whatever log pipeline you already run.
- 5
Exporters forward it as it is written
Any enabled SIEM exporter picks the event up and ships it. Failure on one exporter never blocks the others or the persistence — the store is the record of truth, and an export is a copy.
- 6
You query, export, or assemble a report
Filter by tenant, type and date range and export as CSV or JSON, or generate a framework report over a period as a signed PDF.
How do records reach the systems you already run?
Three exporters, forwarding as events are written, plus filtered exports you can hand to a GRC workflow. The design choice worth knowing is what happens when a destination is unavailable.
Splunk over its HTTP event collector, AWS CloudWatch Logs, and Kafka. Any combination can run at once and each is dispatched independently.
Exporters subscribe to the event stream and forward as events are written. A failing exporter never blocks the others or the primary persistence — which keeps the data plane serving, and also means the store is the record you can rely on rather than the SIEM copy.
A2A events go to the same exporters with the same source and index settings and no extra configuration, so one SIEM pipeline sees model calls, tool calls and agent hops together — even though their stores are separate.
Audit events export as CSV or JSON filtered by tenant, type and date range. Framework reports export as PDF, signed so a recipient can check the export itself has not been altered.
What can you generate for an assessment?
Five framework reports assembled from the records for a period you choose, as a signed PDF. Read the last card before putting one in front of an auditor.
SOC 2 Type II, HIPAA, GDPR, and the India RBI and SEBI reports, scoped to a tenant or across all of them, over a date range you choose.
Named sections rather than a generic dump: chain integrity, access control, policy enforcement, residency and token usage for SOC 2; access and authorization logs, policy violations and access patterns for HIPAA; processing activities, residency, consent and policy status, retention and integrity for GDPR.
All five generate on demand. Scheduled generation is configured for the RBI and SEBI reports; treat the other three as something you run for a period rather than something that arrives.
It is evidence assembled from records DVARA holds, for the window you asked for. It is not an attestation, it does not make an organisation compliant with anything, and it does not replace an auditor, a privacy adviser, or a security programme.
Where do you read the trail?
In DVARA Flightdeck, filtered by tenant, event type and date range, with CSV and JSON export from the same view. Agent-to-agent hops have their own viewer, since they are on their own chain.
Which traffic leaves a record?
What routes through a DVARA gateway. The three planes differ in where their records live, and the last card is the one worth reading before an audit rather than during one.
Response events, policy decisions, PII and guardrail findings, budget breaches.
Tool-call records with their policy decision, plus injection findings and approval outcomes, on the shared chain.
On its own chain in its own store, with its own viewer. Present in SIEM and the compliance reports; absent from the shared audit query.
Anything that did not route through one of those three. A call your application makes straight to a provider leaves no event here, which is worth saying before an audit rather than during one.
How does DVARA compare on audit and compliance?
Against the three alternatives that score strongest on audit and compliance in the matrix behind how DVARA compares — chosen by score, not by how weak they are. Each row is checkable against that product's own public documentation.
| Capability | DVARA | AWS Bedrock | Databricks | Portkey |
|---|---|---|---|---|
| Immutable HMAC-signed audit log | ✓ | ∼ | ∼ | — |
| SOC2 / HIPAA / GDPR evidence packages | ✓ | ∼ | ∼ | ∼ |
| SIEM export (Splunk, CloudWatch, Kafka) | ✓ | ✓ | ✓ | ∼ |
| Scheduled compliance reports (PDF + JSON) | ✓ | — | — | — |
| Pricing model | Licensed, sized by request volume — no hard stop on overage | Token-metered on-demand, or provisioned throughput (source) | See their pricing | Subscription from $49/mo + per-request overage (source) |
Capabilities last verified June 2026; pricing models August 2026. A stale mark is worse than no claim — every row is checkable against each product's own public documentation. For the full matrix across ten alternatives, see how DVARA compares.
What do you need for a verifiable trail?
A licence. The keyless tier logs; it does not sign, chain, export or report — which is the difference between having records and having evidence. See what a licence covers.
A local, unsigned audit log with roughly a week of retention. Enough to see what happened recently; not a chain, and not evidence you can verify.
The signed, hash-linked chain and its verification, the SIEM exporters, and the framework reports. This page is largely about the licensed half.
Retention past the keyless default is a deployment question — the store is your PostgreSQL, so how long records live and how they are backed up follows your own operational policy rather than a setting here.
Common questions about AI audit evidence
What does DVARA audit?
Governed calls and the decisions taken on them: every data-plane request writes a response event with the model, provider, status, latency, tokens, tenant and policy decision, and each enforcement action — a policy denial, a PII detection, a guardrail block, a loop detection, an approval, a budget breach, an admin change — writes its own typed event. Traffic that does not route through a DVARA gateway leaves no record here.
When is an event written?
The data-plane event is written on the way out, after the response, so it records what happened rather than what was attempted. Enforcement events are written when the control fires, which is why a call that was refused before reaching a provider still leaves a trail.
What makes the log tamper-evident, exactly?
Each event is HMAC-SHA256 signed over a canonical form — the event ID, timestamp, tenant, type, the payload with keys sorted, and the previous hash — so altering an event breaks its signature and removing one breaks the link. A scheduled job re-verifies the chain. The signing secret is configuration you supply; DVARA does not hold it.
Are sequence numbers global?
No, and the distinction matters. The store assigns a monotonic arrival number that orders listings and exports. The chain position is separate: each pod maintains its own chain and each run of that pod is its own segment, with positions starting at one. A gap there is positive evidence that an event a pod signed never arrived — something a single global counter cannot express.
Is the log immutable?
No, and we would rather say so. It is append-only through the API — events cannot be updated or deleted that way — and it is tamper-evident, meaning alteration and removal are detectable. Someone with direct database access can still delete a row; what the chain guarantees is that you will know. Immutability would be a claim about storage and permissions, which is your deployment rather than ours.
Is one tenant’s audit data separated from another’s?
Queries are tenant-scoped at the application layer, and the A2A viewer in the tenant portal shows only that tenant’s hops. That is the mechanism, stated as what it is — enforcement in the application, over a shared store, rather than isolation proven at every layer down to storage.
How does SIEM export behave when a destination is down?
Splunk, CloudWatch and Kafka can run at once, each dispatched independently, and a failure on one never blocks the others or the primary persistence. That keeps the data plane serving and means the store — not the SIEM copy — is the record to rely on. Treat forwarding as best-effort and reconcile against the store if a destination has been unavailable.
Do agent-to-agent hops appear in the same place?
Not in the shared audit query or viewer — the A2A plane keeps its own chain in its own store, with its own viewer in the console and portal. They do reach the same SIEM exporters with no extra configuration, and they appear in the compliance reports. Worth knowing before someone searches the shared viewer for a hop and concludes it was never recorded.
What compliance reports can DVARA generate?
SOC 2 Type II, HIPAA, GDPR, and the India RBI and SEBI reports, over a date range and scoped to one tenant or all of them, as a signed PDF. Each has named sections — chain integrity, access control, policy enforcement, residency, token usage, and framework-specific ones. All five generate on demand; scheduled generation is configured for the RBI and SEBI reports.
Does this make us compliant?
No. It produces evidence about the AI traffic that routed through DVARA — who called what, under which policy, with what outcome, and whether those records have been altered. Compliance with a framework covers far more than AI traffic and is assessed by an auditor against your whole organisation. This is one input to that work, not a substitute for it.
How long are records kept?
Without a licence key, roughly a week. Beyond that, the store is your own PostgreSQL — so retention, backup and deletion follow your operational policy rather than a setting in the product. Plan retention with whoever owns that database.
Which edition includes which capability?
Without a licence key you get a local, unsigned audit log with about a week of retention. The signed, hash-linked chain and its verification, the SIEM exporters, and the compliance reports are licensed — which is most of what this page describes.
Decide what you would need to show, then check you have it.
The useful test is not whether a log exists. It is whether you can answer who called what, under which policy, with what outcome — for a period someone else picks, and prove the answer has not been edited.