Skip to content
← Resources

Privacy by design

Why your e-signature provider shouldn't have your keys

You can have a familiar agreement workflow without giving the provider a way to read every sensitive value. The bank vault analogy explains how.

· 4 min read · Inklok

You send a contract for signature. Someone types a name, an address, maybe a tax ID, and signs. The service stores the result and keeps the process moving. That is how an e-signature product should feel.

But here is a question we think people should ask more often: does the service itself need a way to read the sensitive information a signer entered?

We built Inklok around the idea that, for protected signing values, the answer can be no. And we wanted the product to feel normal anyway.

A bank that cannot open your boxes

Picture a bank vault full of safety deposit boxes. The bank knows who can enter and which boxes belong to whom. It safely stores the boxes. You hold the keys that open the ones you are allowed to access.

Now imagine the bank also stores a locked backup of your personal keyring. You can open that backup with your password. If you lose the password, you have a separate Recovery Key. The bank can help you get the backup, but it cannot independently open your keyring and look through your boxes.

This is the part people often miss about zero-knowledge systems. Authentication, the ability to enter the vault, is not the same as having the cryptographic keys to open protected information.

The browser is the private viewing room

A real safety deposit box can be taken to a private viewing room. You open it away from the bank counter and lock it before returning it.

For Inklok's protected signing values, that private room is your browser. The browser locks sensitive values before they are stored by Inklok and opens them locally when an authorized person needs to read them.

Inklok handles the locked boxes. Your browser handles what is inside.

The arrangement can be repeated across agreements. Each agreement gets its own protected scopes and authorized people. Having access to one does not automatically give you the keys to another.

Privacy should not become another job

Most people do not want to manage cryptographic keys. They want to send an agreement, invite the right participants, sign it, and find it later. We think that is a reasonable expectation.

Inklok coordinates the permissions, storage, signing workflow, and account recovery paths. If you sign in from a new device, your normal password can help restore the same private cryptographic identity. Your Recovery Key remains the emergency fallback. You do not need to run your own key-management service to get this protection.

There is a boundary worth being clear about. The source PDF and workflow metadata have different processing requirements. Our zero-knowledge promise applies specifically to protected signing values, not every part of an agreement workflow. Our Security overview explains that distinction.

We wrote a fuller, plain-English walkthrough of the vault, keyring, and viewing room, including how multiple signers get access and what happens when a password is lost.

Read the complete bank vault analogy in Inklok Learn.

We want zero-knowledge protection to feel as straightforward as any other modern agreement platform. Because your agreements are yours. Not ours.

Sign agreements. Don't hand us the keys.

Get familiar signing workflows with zero-knowledge protection for sensitive values entered during signing.

Why your e-signature provider shouldn't have your keys | Inklok