Every value entered during signing
- Signatures and initials
- Names, dates, and text entered into fields
- Banking, tax, or identification information
- Any other value entered during signing
Security & Trust Center
Security you can examine, not just take on trust.
A complete signed agreement combines its original PDF with protected signing inputs. Inklok encrypts those inputs separately and does not hold the private keys needed to independently reconstruct them. Here is what we protect, what we can access, and where the boundaries are.
Client-side encryption
Signing data is encrypted before upload.
The encryption boundary begins in the participant's browser. Values are encrypted before they are transmitted to Inklok.
What reaches Inklok
Inklok receives encrypted signing values rather than readable plaintext.
Those encrypted values can be stored and moved through the agreement workflow without giving Inklok an independent key that can decrypt them.
The security boundary
What Inklok can see.
Zero-knowledge encryption does not prevent Inklok from operating the agreement itself. We still need normal workflow information to run the service.
Inklok can access
- The original agreement PDF
- Templates and workflow configuration
- Participant names and email addresses
- Signing order and agreement status
- Permissions
- Audit and workflow events
We use that information to
- Route agreements between participants
- Manage signing order and permissions
- Send notifications
- Track agreement status
- Maintain audit and workflow history
This is what lets Inklok behave like a normal e-signature platform while keeping the values participants enter behind a separate cryptographic boundary.
Zero-knowledge
What we don't have is a spare key.
Values entered during signing are stored in encrypted form. Inklok does not hold an independent private key that lets us decrypt them.
Decryption requires authorization
Reading a completed signing value requires cryptographic identity material belonging to a participant who is authorized to access it.
Inklok cannot substitute itself
The application server cannot simply retrieve a master key and decrypt signing values on its own.
The people involved in the agreement keep cryptographic control of what they enter.
Why it matters
Encryption at rest is not the same thing.
Traditional server-side encryption can protect stored data while still leaving the application in control of the keys needed to decrypt it.
Server-side encryption
Encryption at rest is useful protection for stored data. But when the application also controls the decryption key, the application may still be capable of reading that data during normal operation.
Inklok's approach
Signing values are encrypted before they reach the server, and Inklok does not receive an independent private key that can decrypt them.
A database-only compromise can expose encrypted signing values, but not the participant-held cryptographic identity required to read them.
Account access
Use Inklok across your devices.
Zero-knowledge encryption should not turn ordinary account access into a special workflow.
New device
Sign in normally to access your agreements from another device.
Recovery Key
Keep your Recovery Key somewhere safe. You may need it to restore encryption access during certain account recovery flows, such as if you forget your password.
How a signed agreement is protected
Two layers, two different key boundaries.
A complete signed agreement combines the original PDF with the values entered during signing. These components are deliberately protected differently.
Original PDF
Inklok can access the original PDF as part of operating the service. The source document is encrypted with AES-256-GCM and a server-managed, AWS KMS-protected document key. Authorized clients can retrieve the document decryption key after the appropriate access checks.
Protected signing inputs
For interactive signing, protected field values use AES-256-GCM encryption and authenticated agreement, field, and key-scope binding. Scope keys are wrapped to authorized recipient identities using RSA-OAEP. Inklok does not keep an independent private key to decrypt these strict zero-knowledge values.
Inklok cannot independently decrypt protected signing inputs and therefore cannot reconstruct or view your complete signed agreements.
Who gets access
Authorization is necessary. A key is necessary too.
Signing permissions, organization roles, and cryptographic access are separate checks.
Signers and guests
Signing links are scoped to a specific agreement and participant. Guest access uses participant-bound cryptographic envelopes; registered signers use account envelopes bound to their participant identity.
Organization access
Eligible organization members can decrypt agreements for which they received key access. Adding someone to an organization does not automatically unlock historical protected values.
Revocation and completion
Role downgrade or removal immediately blocks organization-derived access checks, even for previously issued envelopes. Account downloads of agreement documents require completion and a matching cryptographic grant. Independent signer access is separate.
Recovery and signing evidence
Designed for continuity, with meaningful limits.
Recovery Key and Recovery Kit
Account encryption identity can be restored with a Recovery Key. The downloadable Recovery Kit helps you retain it safely. Your Recovery Key is not a login-password reset; losing every usable recovery method may mean permanent loss of access to historical protected values.
Signing history and evidence
Inklok records signing workflow and completion events and stores submitted signing fields as encrypted values. Audit history can support review, but legal enforceability depends on circumstances and applicable law. We do not claim a blanket ESIGN/UETA certification or legal guarantee.
Limits and transparency
What our security claims do not mean.
A credible trust model should explain its exceptions, not hide them.
Operational and batch processing
Inklok processes participant contact details, status, audit events, and other workflow metadata. Background batch operations can temporarily process source data in server memory before sealing protected signing fields. The browser-encryption statement applies to interactive signing, not every background workflow.
Authentication and independent assurance
Account multi-factor authentication is not currently available. We do not claim SOC 2 certification, an independent penetration-test attestation, or verified identity for every signer. Do not interpret cryptographic access as proof of a person's real-world identity.
Storage and retention
Encrypted documents are stored in access-restricted, versioned object storage. Versioning is not a promise of a specific deletion or backup retention period. Refer to our privacy policy for published handling commitments.
Security questions or concerns
Have a question about our trust boundaries or want to report a security concern? Use our contact page. Please avoid including passwords, Recovery Keys, or private agreement content in your message.
Technical reference
See the architecture behind the claims.
Visit our public documentation for more information about Inklok.
Security FAQ
Security questions worth asking.
Can Inklok reconstruct my complete signed agreement?
A complete signed agreement combines the source PDF and protected signing inputs. Where those protected inputs are part of the completed agreement, Inklok does not hold the private keys needed to independently decrypt them and reconstruct the complete result. We can access the original PDF under its separate server-managed security boundary.
Does Inklok support multi-factor authentication?
Not currently. MFA is on our roadmap; we do not describe it as an available account security control.
Can a newly added organization member decrypt old agreements?
Not automatically. Organization access is forward-only by default: the member needs a previously issued or separately authorized cryptographic grant for historical protected values, as well as an eligible current role.
Can Inklok read what I enter during signing?
No. Every value entered during signing is encrypted in the browser before it is sent to Inklok. We store those completed values in encrypted form and do not hold the private key needed to independently decrypt them.
Can Inklok see the original agreement PDF?
Yes. Inklok can access the original agreement PDF so we can operate the agreement workflow. Signing values are handled separately and encrypted in the browser before transmission.
Is Inklok zero-knowledge?
Yes. Signing data uses a zero-knowledge encryption model. Inklok can run the agreement workflow, but we do not hold the private key needed to independently decrypt the values participants enter during signing.
What happens if Inklok's database is compromised?
Completed signing values stored in the database remain encrypted. Reading them requires the cryptographic identity of an authorized participant.
Other information needed to operate the service, such as the original agreement PDF and workflow metadata, remains within Inklok's normal server-side security boundary.
Who can decrypt signing data?
Decryption requires cryptographic identity material belonging to someone authorized to access that value. Depending on the agreement and its permissions, that could include the sender, a signer, an assigned reviewer, or someone the sender has authorized to view it. Inklok does not keep an independent private key that can be used instead.
What happens if I use a new device?
Just sign in. You can access your agreements from your other devices without changing how you use Inklok. We recommend keeping your Recovery Key somewhere safe. You may need it to restore encryption access during certain account recovery flows, such as if you forget your password.
What is my Recovery Key for?
Your Recovery Key helps restore access to your encryption identity during certain account recovery situations. Keep it somewhere safe because it protects access to signing data encrypted for your account.
Sign agreements without handing us the keys.
Zero-knowledge protection is part of every Inklok plan.
Learn
Questions worth asking before you sign.
Straight answers about agreement privacy, signing workflows and predictable pricing. Explore the trade-offs and see where Inklok fits.
Can electronic signature providers read your documents?
Learn when an e-signature provider can access contract contents, how encryption keys affect privacy, and how Inklok approaches private signing.
Read the answer →What is a zero-knowledge electronic signature?
Understand zero-knowledge e-signatures, how they differ from ordinary encrypted signing services, and how Inklok combines privacy with usability.
Read the answer →What should you look for in a privacy-focused DocuSign alternative?
Compare the privacy questions that matter when evaluating electronic signature alternatives, including key control, usability, pricing and recovery.
Read the answer →