Security and privacy
How your documents are protected
Lawyers ask us two questions before anything else. How private is it, really? And is there a back door on the server? This page answers both in plain terms, including the parts we are still building.
- Encrypted where
- In your browser, before upload
- Server stores
- Sealed file and its fingerprint
- Public record holds
- Fingerprint, time, author. Never content
- Who can open a document
- People with access to its matter
- Does our staff read documents
- No. There is no tool for it
- Could we, in principle
- Yes, today. A no-access tier is on the roadmap
What leaves your device
Only a sealed file and its fingerprint. Never the text you wrote.
When you commit a version, your browser encrypts the document before it uploads anything. The encryption is AES-256-GCM, the same standard banks and governments use. Each document gets its own random key. Even two identical documents produce different sealed files.
The server receives two things: the sealed file (ciphertext) and its fingerprint (a hash). The fingerprint is computed from the sealed file, not from your text. So it cannot be used to guess what the document says, even for a common template.
Your drafts stay on your device while you write. They are not sent to the server until you commit.
Who can decrypt, and how
Only people with access to the matter. The key is released one document at a time.
The key for each document is protected in two ways. One copy is locked to the browser that created it. A second copy is locked under a hardware-backed key that we operate in AWS Key Management Service (KMS). This second copy is what lets you open the same document on your phone, or lets a colleague open it on their laptop.
To get a key released, a signed-in user asks our API for it. The API checks the matter access list first: Owner, Editor, or Viewer on that matter. No access, no key. Walled matters are visible only to the people named on them. Decryption then happens in that person's browser. The server never assembles the readable document.
In other words, the system is built so that reading a document requires passing the same access checks your colleagues do.
What is public
The fingerprint and the timestamp. Never the content.
Each committed version is recorded on a public ledger that no single company controls. The record holds the fingerprint of the sealed file, the time it was recorded, and a signature made as the authenticated author. That is what makes the proof independent of us.
The sealed file itself is stored on a permanent public storage network. It is ciphertext. Without the key, it is random bytes to anyone who finds it.
A proof-only share link shows the record and the fingerprint, and nothing else. The text of the document is never posted anywhere public.
What we, as a company, can and cannot do
We are honest about where trust still sits with us.
What we can do
- We operate the KMS key that protects the cross-device copy of each document key. This is a custodial model, the same one e-signature providers use.
- We can see who has access to which matter, when versions were committed, and the fingerprints. This is the metadata the product needs to work.
- Every use of the KMS key is recorded by the cloud provider. Key release is gated by the matter access check in code, and only for one document version at a time.
- We sign the on-chain record on your behalf, as the authenticated user, from keys we hold. Nobody at Legal Anchor sees a wallet, and neither do you.
What we do not and cannot do
- Nobody at Legal Anchor reads your documents. There is no admin screen, no support tool, and no export that shows document text.
- We do not hold your drafts. They live on your device until you commit.
- We cannot edit, backdate, or delete a committed version. The public record and the permanent storage make that impossible for us too.
- We cannot make a leaked fingerprint reveal content. It is a hash of the sealed file.
What we do not yet offer: a tier where we are technically unable to release a key, even under compulsion. That is on the roadmap: keys released by a decentralized key network, or by a KMS your own firm holds, with our server only answering the access question. Until it ships, the honest claim is "we do not", not "we cannot".
One more piece of candor. The signing keys that attribute versions to you are held by us, with the master secret protected by KMS and loaded into server memory while the service runs. Moving to per-user keys that never leave the hardware module is a planned hardening step.
Offline and on your device
Anything you have touched stays readable offline. That means it lives on the device.
Drafts save to your browser's local storage as you type. When you open a committed version, a readable copy is kept on the device so it opens instantly and works offline. This is what makes the app usable on a flaky connection.
The trade-off is plain: those local copies are only as safe as the device. If a laptop is stolen, what you wrote and what you read on it could be exposed.
Our recommendation
Turn on full-disk encryption on every device you use for client work. FileVault on Mac, BitLocker or Device Encryption on Windows, and the default lock on iPhone and Android. Use a strong device passcode. This is the single most effective step you can take.
Share links
Two kinds of link. One proves. One also reveals.
A proof-only link shows the record: title, version, time, author, fingerprint, and a button to verify on the public ledger. Nothing more. It is safe to forward.
A content link also lets the recipient read that one version. Our server releases the document key to whoever holds the link, and the recipient's browser fetches the sealed file and decrypts it locally. The readable document never passes through our server.
Treat a content link like the document itself. Only an Owner or Editor can create one. It covers a single version, never the history and never the matter. Links expire, and you can revoke any link at once from the Shared externally page.
Verify it yourself
You do not have to take our word for any of this.
- 1
Open the proof page
Every committed version has a public proof page. It shows the document fingerprint and a "Verify on-chain" link to the public ledger record.
- 2
Compare the fingerprint
The fingerprint on the proof page, the fingerprint in the ledger record, and the fingerprint in the footer of a printed court copy must all match. If any differ, the version was altered.
- 3
Watch the network
Open your browser's developer tools during a commit. The upload contains the sealed file and the fingerprint. You will not find the text of your document in it.
- 4
Read the decisions
Our architecture is written down as decision records, with the trade-offs we accepted. Ask us for them. We share them with pilot firms.