Audit trail
Gate keeps a tamper-evident audit trail for gateway activity and important workspace changes. Use it to investigate what happened, export evidence for review, and verify that an audit record has not changed since it was checkpointed.
The audit trail is separate from readable message storage. It records metadata, hashes, proof data, and fingerprint references so evidence can remain verifiable even when retained prompt or response text is later removed.
What gets recorded
Gate records terminal gateway outcomes and important control-plane events, including:
- Model requests that succeeded, failed, were blocked, or were served from cache.
- Response-side policy outcomes, such as flagged or blocked responses.
- Security and policy decisions, including broad decision details and the action Gate took.
- API key, member, policy, plan, entitlement, export, deletion, and data-access events.
Audit records can include the event time, event type, source, request ID, model, provider, status, latency, token counts, estimated cost, API key or member context when available, and proof fields such as content hashes, checkpoint IDs, fingerprint status, and inclusion proofs.
Prompt and response text are not part of the permanent audit proof. When readable content is still within your retention window, exports can include it. After retention or erasure removes that content, exports keep the audit metadata and proof fields but leave the removed prompt or response text blank.
How verification works
Gate groups audit events into checkpoints for your organization. Each checkpoint commits to the included events and is fingerprinted to Constellation Digital Evidence.
An individual audit record is verified through its proof bundle:
- The record has a content-derived hash.
- The proof shows that the record was included in a checkpoint.
- The checkpoint fingerprint shows that checkpoint was submitted to Digital Evidence.
This means a verifier does not need to trust the dashboard alone. They can recompute the proof and compare it with the checkpoint and fingerprint data.
Browse the audit trail
Open Audit trail in the dashboard to review recent events. The page includes:
- Search across audit events, users, and hashes.
- Filters for event time, member, and event type.
- An event table with time, event ID, event type, description, member, and fingerprint status.
- Overview cards for recent audit volume and the most recent fingerprint.
Select any row to open the audit record detail view.
Verify a record
The audit record detail view shows the event metadata and fingerprint status. From there you can:
- Copy the proof JSON for independent review or storage.
- Open the fingerprint in Constellation Digital Evidence Explorer.
Proof status can be:
| Status | Meaning |
|---|---|
| Not ready | The event has not been included in a checkpoint yet. Refresh later. |
| Pending | The local inclusion proof verifies, but Digital Evidence finalization is still pending. |
| Verified | The inclusion proof verifies and the Digital Evidence fingerprint is finalized. |
| Invalid | The proof does not match the expected checkpoint. Treat this as an integrity issue. |
New records may spend a short period in a pending or not-ready state while checkpointing and Digital Evidence finalization complete. Request handling does not wait for public fingerprint finalization.
Open Digital Evidence Explorer
When a record has a fingerprint, Open Explorer opens the matching fingerprint page in Constellation Digital Evidence Explorer.
Depending on the fingerprint, Explorer can show the hash, status, confirmation timestamp, fingerprint timestamp, event ID, organization or tenant references, document references, signer and signature information, and proof batch details. When proof data is available, Explorer can also show or download the proof JSON and run a verification check.
For example, a Digital Evidence fingerprint page looks like:
Export audit evidence
Use Export CSV from the Audit trail page to export the current filtered result set. Exports are intended for investigation, customer review, and compliance evidence collection.
An export can include request metadata, usage fields, policy outcome fields, retained prompt and response text when available, hashes, checkpoint IDs, Digital Evidence status, anchor timestamps, and inclusion proof data.
Because readable content follows your retention settings, older or erased requests may still have verifiable audit rows even when the prompt or response text columns are empty.
Retention and erasure
Gate separates permanent proof from readable content:
- The audit trail stores hashes, metadata, checkpoints, and proof references.
- Readable prompt and response content is stored separately under your retention settings.
- Removing readable content does not remove the proof that a request or event occurred.
This helps teams preserve an evidence trail without making prompt and response text permanent. It also means an audit export is most complete while the relevant readable content is still retained.
What the audit trail can and cannot prove
The audit trail can help prove that a recorded Gate event existed, was included in a checkpoint, and has not changed since that checkpoint was fingerprinted.
It does not prove what a third-party model provider did internally, guarantee that retained readable content is still available after your retention window, or replace your own compliance review. Treat it as verifiable evidence that supports investigations, customer reporting, and compliance programs.
Related
- Security: how security checks, redaction, and blocking work.
- Prompt-injection defense: prompt-injection policy behavior.
- Connect your apps: route apps through Gate so their requests appear in the audit trail.