Why you would trust this

Not because we say we are careful. Because of how the thing is built, described precisely enough that you could disagree with it.

Consent comes before the operation, not after it

Every route that touches evidence sits behind a middleware that refuses the request outright — 403, before any handler runs — unless the account has explicitly enabled evidence upload. Consent is a precondition in the code, not a checkbox recorded somewhere and then ignored.

The gate covers the routes that reach evidence sideways, too. Loading an incident eager-loads the evidence attached to it, and attaching evidence to an incident is an evidence operation wearing an incident URL — so both sit behind the same middleware as /evidence itself. One rule in one place, rather than a second rule to forget.

A record cannot be rewritten, and cannot be deleted

The evidence model refuses its own updates. Anything other than a verification flag and a metadata field raises an error rather than saving, and deletion is refused outright — including by us. There is no admin screen that quietly empties a vault.

This matters for the case it was built for: a record of harassment or fraud is worth having precisely because the person who caused it cannot make it go away, and neither can a company under pressure to make it go away.

Fingerprinted on arrival, re-checked on demand

Every file is fingerprinted with SHA-256 as it arrives, by the server, from the bytes it actually received — not from a hash the client supplied. A verification re-reads the stored file and fingerprints it again.

So a file altered after the fact is reported as altered rather than passing quietly. The verification writes its result either way: a failed check is recorded as a failed check, not swallowed.

Encrypted per file, and tamper-evident by construction

Each file gets its own encryption key, which is itself wrapped under a master key held only in server configuration — so a stolen file is not a readable file, and one compromised file key does not open the next one.

The encryption is authenticated (AES-256-GCM), which is a stronger property than secrecy alone: altered data does not decrypt into slightly different data, it refuses to decrypt at all. Verified against the live key on 28 September 2026 — a single flipped byte, a truncated file and another file's key are each rejected.

Where all of that stops

Four things we are careful not to claim, because each of them is the kind of assumption a buyer would make on their own.

We do not claim court-admissibility

Whether a record is admitted is a matter for a court and for the law of evidence, not for a vendor. What we can say is that the record is fingerprinted, that alterations are detectable, and that it cannot be edited or removed. Anyone telling you their app produces court-ready evidence is selling you a decision that is not theirs to make.

Encryption protects a stolen file, not a compromised server

Per-file keys are wrapped under a master key that the application must be able to read in order to work. Someone who holds that key can read what it protects. This design defends against a stolen disk, a leaked backup or a misconfigured bucket; it is not a claim that we cannot see your data.

Known-malware detection is one layer, not a guarantee

The desktop product recognises files it has seen before. A hash we do not hold is unknown, which is not the same as safe. We publish where the signatures come from and what they cover so the size of that layer is visible rather than implied.

Nothing here is released yet

These are properties of a system that is built and running, not of a product you can buy today. Each product line says exactly where it stands, with the evidence, on its own page. If you are being targeted right now, the national helpline is what will help — not us.

Found something wrong with any of this?

Tell us. A security company that is difficult to report problems to is a security company whose problems stay unreported — and everything on this page is a claim that could turn out to be wrong.

Write to support@cyberrakshak.ai. We will not threaten you for it.