An auditor asks: "Show me what the contractor did on the production database on March 3rd."
You have a screen recording. The auditor's next question is the hard one: "How do I know this file is the one that was recorded, and that nobody trimmed it afterwards?"
If your answer is "it's in a locked folder", you have a recording but not evidence. This post covers how ZenxPAM links a recording to the request that allowed it, and how it makes later tampering detectable.
The problem with a recording on its own
A video file says what happened. It says nothing about:
- who asked for the access, and who approved it;
- which policy decision allowed the session;
- whether the file was changed after capture;
- whether it was deleted, and why.
Each gap is a place where an investigation stalls. So we treat the recording as one link in a chain, not as the artefact.
1. Capture happens at the gateway
Operators connect through a browser, and the gateway streams the session to the target through Apache Guacamole. Because all traffic passes the gateway, the recording is made there, in real time. There is no agent on the target to uninstall and no endpoint driver to disable.
Each recording gets a unique storage path of the form /{tenantId}/{sessionId}/{recording-id}, and UTC start and end timestamps are stored on the session. When the recording is uploaded, a SHA-256 hash is computed and stored with its metadata.
2. The recording is linked back to the request
Every recording points to its session, and every session points back to how it was allowed:
Access request -> Approval -> Policy evaluation -> Session -> Recording -> Audit log entries -> Immutable chain
The links are foreign keys in both directions, so an investigator can start from a recording and reach the original request, or start from a request and find every recording it produced. "Who approved this?" and "what did they do?" are answered from the same place.
3. The audit trail is a hash chain
Alongside the normal audit log, every event is anchored in an append-only chain in PostgreSQL:
- each entry stores a SHA-256 hash over its id, action, entity type, timestamp, block index and the previous entry's hash;
- block indexes run in sequence per tenant, so a missing entry leaves a visible gap;
- the data layer rejects updates and deletes of chain entries, and the API only exposes append and read.
A verification endpoint walks the chain for a tenant and checks three things: each hash matches its recomputed value, each entry points at the real hash of the one before it, and the sequence has no gaps. A separate tamper-detection call reports any broken link.
One honest limit: this is tamper-evident, not tamper-proof. Someone with raw database access can still rewrite rows. What the chain gives you is that the rewrite is detectable the next time anyone runs verification.
4. Deleting a recording leaves a record of the deletion
Retention policies eventually remove old recordings, and that is where evidence usually disappears quietly. ZenxPAM writes audit entries for every step, and they are anchored in the same chain:
| Event | What the audit trail records |
|---|---|
| Recording archived | Source path, archive target, archive path and time |
| Recording deleted | A tombstone with the original path and, if archived, where the copy went |
| Legal hold placed or released | Who did it and the stated reason |
| Delete attempted on a held recording | The refused attempt |
| Hold release attempted without authority | The attempt and the caller's roles |
Legal holds also separate duties: an auditor can place a hold but cannot release it. Release needs an admin role. A held recording is skipped by the retention sweep and refused by the delete path.
Audit ingest is all-or-nothing too. If an entry cannot be anchored in the chain, the whole write is rolled back and the caller gets an error, so an unanchored audit row is never accepted silently.
5. The evidence pack
When an auditor asks for a period, the platform builds an evidence pack: counts and references for audit logs, recordings, compliance reports and policy evaluations, in a JSON manifest. A SHA-256 hash is computed over the manifest and stored with the pack, so anyone who downloads it can check it independently.
This gives your auditors something to verify, not only something to read. It is evidence for your auditors; it does not by itself make an organisation compliant with any framework.
What to take from this
If you run privileged access today, three questions are worth asking about your own setup:
- Can you go from a recording to the approval that allowed it in one query?
- If a recording were trimmed tomorrow, would anything notice?
- If one were deleted, could you prove who deleted it and why?
If any answer is "no", the recording is a video, not evidence.
ZenxPAM docs and a demo are at zenxsys.com.
Top comments (0)