In this model:
- Users enter agreement data in the browser
- Data is transmitted to servers
- Servers store and process readable content
- Encryption is typically applied at rest (server-side encryption)
Security
🔐 Security for agreement workflows
Inklok combines a hybrid encryption model with role-based access controls, audit trails, and structured workflow permissions.
Inklok reduces exposure of sensitive agreement inputs by ensuring they are encrypted in the browser before reaching server infrastructure.
1. Most SaaS agreement systems
Most SaaS agreement platforms
Most agreement SaaS platforms are built around server-side data processing.
This enables powerful features like:
- Search and indexing
- Workflow automation
- Template rendering
- Support tooling and recovery systems
But it also means:
The service infrastructure may process plaintext agreement data as part of normal system operation.
This includes highly sensitive fields such as:
- SSNs
- Tax IDs
- Banking information
- Personal contract terms
2. Zero-knowledge systems
The opposite end of the spectrum
Zero-knowledge systems are designed so the provider cannot access plaintext user data by design. A common example is password managers.
In these systems:
- Encryption happens on the client device
- The server stores only encrypted data
- Decryption keys are controlled by the user
- The service provider never sees plaintext data
Examples include:
- Password managers
- End-to-end encrypted messaging systems
- Encrypted storage tools
This model provides strong privacy guarantees because:
Even if the service infrastructure is compromised, stored data remains unreadable without client-held keys.
However, this model comes with tradeoffs:
- Limited server-side search and indexing
- Reduced workflow flexibility
- Constraints on collaboration features
- Less server-side data processing capability
3. Where Inklok fits
A hybrid encryption model for agreement workflows
Inklok applies client-side encryption to sensitive agreement inputs entered by participants. These values are encrypted in the browser before reaching Inklok servers.
This includes:
- SSNs
- Tax identifiers
- Banking information
- Sensitive form fields inside agreements
These values are not received in plaintext by Inklok systems.
At the same time, Inklok operates as a workflow platform that requires server-side handling of system data:
- PDFs and document structure
- Workflow routing and permissions
- Template definitions
- Audit logs and lifecycle state
This enables full agreement functionality:
- Signing workflows
- Collaboration between parties
- Document generation and routing
- Auditability and compliance tracking
4. Why Inklok is a hybrid system
The hybrid model is intentional.
Agreement workflows require dynamic coordination between multiple parties, which depends on server-side systems.
Server-side systems are needed for:
- Routing and approvals
- Document rendering
- Conditional workflow logic
- Audit trails and legal traceability
At the same time, the most sensitive risk in agreement systems comes from user-entered data such as financial and identity information.
Inklok separates these concerns: sensitive agreement inputs are encrypted client-side, while workflow and document systems operate server-side.
Why not fully zero-knowledge?
Fully zero-knowledge systems are well-suited for static data storage, but agreement workflows are inherently interactive and stateful.
Removing server-side visibility entirely would significantly limit:
- Collaboration
- Workflow automation
- Document generation
- Auditability
Why not traditional SaaS?
Traditional SaaS agreement platforms rely on server-side processing of all agreement data, including sensitive user inputs, even if encrypted at rest.
This increases operational flexibility, but expands the surface area where plaintext data may exist within system boundaries.
5. The Inklok model
Inklok's security model
Inklok is a hybrid agreement platform.
- It applies a client-side encryption boundary to sensitive agreement inputs
- It uses server-side systems for workflow and document orchestration
- It enforces strict role-based and participation-based access controls
The result is:
Agreement workflows remain fully functional, while the most sensitive user-entered data never needs to exist in plaintext on Inklok servers.
Security FAQ
Security questions worth asking.
Does client-side encryption remove all risk?
No. It reduces exposure of sensitive inputs, but workflow and document systems still operate server-side.
What data is encrypted client-side?
Sensitive agreement inputs entered by participants.
Does Inklok store agreement data?
Yes. Encrypted sensitive fields and workflow/document data required for system operation.
Can admins access all agreement data?
No. Access depends on roles, participation, and encryption boundaries.
Is Inklok zero-knowledge?
No. Inklok is not a fully zero-knowledge system.
It implements a client-side encryption boundary for sensitive agreement inputs, ensuring these values are encrypted before reaching Inklok servers.
To support workflows, the system still processes:
- PDF and document structure
- Workflow routing and permissions
- Template definitions
- Audit events and lifecycle metadata
Why not encrypt everything?
Because agreement workflows require structured server-side access to documents, routing, and lifecycle state in order to function.
Inklok is an agreement platform where:
Workflow systems remain fully functional, while sensitive agreement inputs remain encrypted before they reach server infrastructure.