A monitoring tool
is a target.
Evidarch holds the most sensitive text in your organization: what people typed when they thought only a chatbot was reading. That makes it worth attacking, and it makes vague assurances worse than useless. So this page sets out what it holds, what never reaches it, what an attacker would get, and where the guarantees stop.
The redaction happens before the network, not after.
Most tools capture everything, ship it, then filter server-side. Which means the secret existed on the wire, and in their logs. Evidarch runs detection on the device and replaces what it finds before the event is transmitted at all.
The hash proves what the original said without storing it. If somebody later disputes the record, the hash of the true original still matches. The server never needed a copy to prove that.
Plainly, what is in the database.
| Held | Where | Retention |
|---|---|---|
| Event record | The hash chain. Who, when, which tool, which action, the content hash. | Kept for the ledger's life — this is the proof. |
| Redacted prompt / reply text | A separate content table, referenced by the event, never on the chain row. | Your policy. Swept automatically when it expires. |
| Uploaded file bytes | A separate blob store with its own lifecycle. | Original, preview-only, or metadata-only — you choose per org. |
| Screen captures | The blob store, as an attachment on the exchange. Off unless enabled. | Same policy as any other attachment. |
| Identity | Work email and the identifiers collectors observed, resolved to one person. | Erasable on a subject request without breaking the chain. |
What an attacker gets, honestly.
Stated as outcomes rather than adjectives. Where a control does not hold against a given attacker, it says so.
Someone on your network
Gets nothing. Every console route and every API except ingest requires a signed session. Ingest requires a collector token, stored only as a SHA-256 hash and scoped to the sources it may submit. Authentication endpoints are rate-limited.
A stolen collector token
Can write events for its own tenant and its own permitted sources. Nothing else. It cannot read a single prompt, and it cannot rewrite history, because ingest only ever appends. Revoke it and the row stays as a record of when it was withdrawn.
A member of your own org
Sees the console, and nothing destructive. Bulk export, subject packets and erasure are admin-only, and every one of those acts is written to an administrative audit trail attributed to the person who performed it.
Another tenant
Cannot reach your data by any route. The tenant is resolved from the session server-side, never from a URL parameter, and every read and write is scoped by it — including the blob store and credential revocation.
Someone with database write access
Can alter rows. This is exactly the attacker the hash chain exists for. Any edit, deletion or reordering breaks verification at that record, and they cannot rewrite a head that was already published externally.
Someone who compromises the whole server
Gets the retained content. There is no honest claim to make here beyond keeping less of it. That is why retention is a policy you set, why blobs are separable from the chain, and why redaction happens before transmission rather than after.
The specifics.
Sessions
HMAC-signed, HTTP-only cookies bound to one tenant and one user. A revoked membership ends access on the next request, not at expiry.
Credentials
Collector tokens are stored as SHA-256 hashes, so a database read yields nothing usable. Lookup is an indexed hash probe, not a comparison.
Single sign-on
Google or email via Firebase. Identity tokens are verified server-side and exchanged for a tenant-bound session; the browser never holds a long-lived credential.
Roles
Admin and member. Erasure, exports, subject packets, policy, credentials and team management are admin-only, enforced server-side on every request.
Attachment handling
Files are served only to a signed session, from a strict inline allowlist. Anything scriptable is forced to download and sandboxed, so a captured file cannot execute in the console.
Browser hardening
Content-Security-Policy, frame denial, nosniff, referrer and permissions policy on every response. HSTS once served over TLS.
What this does not do.
A security page that only lists strengths is marketing. These are the real edges. Weigh them before you deploy.
An unanchored chain is weaker evidence
Until chain heads are published externally, the ledger is only self-consistent. An attacker with database access could rewrite the entire history and it would still verify. The console reports that state as exactly that.
Screen captures cannot be redacted
On-device redaction works on text. A screenshot is pixels, so whatever is visible in the chat window is stored as captured. It is off by default, limited to supported AI sites, and subject to your retention policy. But if you switch it on, it records what is on screen.
Coverage depends on deployed collectors
Evidarch records what its collectors see. An AI tool nobody installed a collector for produces no events, and silence is not proof of absence. That is why a collector which stops reporting is raised as a finding.
Detection is not perfect
On-device redaction catches known shapes: keys, tokens, emails, card and identity numbers. Novel or deliberately obfuscated secrets can get through. It reduces exposure a great deal. It does not eliminate it.
It is not a compliance certificate
Evidarch produces evidence. Whether that evidence satisfies your obligations is a judgement for your counsel and your auditor, and monitoring staff carries duties that vary by jurisdiction.
Found something?
Report it to [email protected]. Tell us what you did and what you saw; you will get a human reply. We will not threaten you, and we will credit you unless you would rather we didn't.