# Can you prove who read what?

*Published on 2026-10-13T00:00:00.000Z*

*By CipherStash Team*

Yes, for every value that was decrypted through us. ZeroKMS has to take part in every decryption, and it records the operation before it returns the material the application needs. The record names the identity, the operation, the keyset, the application and the time, from a system the application cannot edit.

## Content

Database audit logging has a known weakness. Whoever has enough privilege to read the data usually has enough privilege to switch the log off, and a `pg_dump` never shows up in it at all. The question underneath "can you prove who read what" is whether the record lives somewhere the reader cannot reach.

## Why the record is trustworthy

Every value has its own data key, and deriving that key needs a key seed from ZeroKMS. Authorization happens while ZeroKMS produces the seed, so the decision and the cryptographic operation are one event. If the request is not authorized, the application never receives the material to derive the key. If it is, ZeroKMS records the operation before returning it.

That record is written by a service outside your application. An attacker who has taken over the application can alter application logs. They cannot edit or suppress the record at ZeroKMS, because ZeroKMS had to participate for the decryption to happen at all.

## What each event contains

Identity, meaning the authenticated service or, with an identity provider federated, the end user. The operation, encrypt or decrypt. The keyset. The application that performed it. The timestamp. Lock contexts add the identity claim that was bound to the value. The SDK also lets you attach arbitrary metadata to an operation, such as a request ID or a ticket number, so the event can be tied back to the reason.

Proxy adds a statement layer on top for teams that need it. It fingerprints query patterns against encrypted data, redacts sensitive values from logged SQL, injects primary keys so the event names the rows touched, and reconciles access events back to records.

## What it does not prove

Anything that happened to plaintext after the SDK returned it. If your application decrypted a value and then wrote it to a log file, the ZeroKMS record shows the decryption and nothing after. A dump of the database shows up as nothing at all, which is the point. The ciphertext in a dump is unreadable without a decryption, and a decryption is an event.

## Getting the logs out

Retention, review, alerting and SIEM ingestion are configured per deployment, and the compliance page puts that responsibility with you. The docs point to support for assurance reports and delivery setup rather than documenting a self-serve export, so ask for it during onboarding.

## Technical evidence

- [Provable access control: audit logging](/docs/solutions/provable-access)
- [Key management: authorization and audit are part of derivation](/docs/concepts/key-management)
- [Access analytics: Proxy statement audit](/docs/concepts/access-analytics)
- [Compliance: the capability map and customer responsibilities](/docs/security/compliance)

## Related notes

- [Can you see our data?](https://cipherstash.com/notes/can-you-see-our-data.md) — No. A data key needs an authority key held in ZeroKMS and a client key held by you. We have one of them, and plaintext never leaves your process.
- [Our agent already has a database user with the right grants. Why isn't that enough?](https://cipherstash.com/notes/our-agent-already-has-a-database-user.md) — Because the database user identifies the agent's workload, not the person it is acting for. Make requests as the signed-in user and lock values to them, and the agent can decrypt those values only on that user's behalf.