Who really holds the key to your documents?
Zero-Knowledge does not mean that the system must be installed on a server at the law firm's office.
Protection depends primarily on who holds the key needed to read the documents.
In Bezpieczna Kancelaria, the operator does not store a permanent key to the original files.
The AI agent gains access within an active user session or through one-time authorization for a specific task.
Is a system for law firms secure only if it runs on a server located in the firm's own office? No. The location of the server room does not determine document security. What matters far more is who holds the key needed to read the files.
This is exactly how Zero-Knowledge architecture works. A provider can store encrypted documents, create backups and provide access to the system without holding a permanent key that would allow it to open a client's files independently.
Zero-Knowledge does not describe where the server is located. It answers a far more important question: who holds the key to the documents?
What does Zero-Knowledge really mean?
Zero-Knowledge has a precise meaning in cryptography. It means that a specific fact can be verified without revealing the secret itself. This is how it is defined by organizations including the US institute NIST.
In data storage services, the term is used somewhat more broadly. It usually means that the service provider stores encrypted information but does not hold the key needed to read it. This model is also used by cloud services including 1Password and Proton.
The easiest way to explain this is with a filing cabinet. In a conventional system, the provider supplies a sturdy cabinet, locks it and assures the law firm that it will use the spare key only when justified. In a Zero-Knowledge architecture, the provider supplies the cabinet and guards the room but does not hold a permanent key.
The provider protects the documents but keeps a key that allows it to decrypt them. The law firm must trust that the key will not be used unnecessarily.
The provider stores encrypted files but does not hold a permanent key that would allow it to open the law firm's files independently.
A server at the law firm does not automatically mean greater security
A locally installed system is sometimes presented as the only secure option. However, the physical location of the device says nothing about how the documents are protected. A local server may store files that an administrator can read or use a shared key stored on the same drive as the encrypted data.
In that case, anyone who takes control of the server gets both the safe and the key to it. A local installation also makes the law firm responsible for continuously maintaining the security of the entire environment.
- updating the system and its components
- securing the network and employees' computers
- controlling administrator accounts
- properly creating and protecting backups
- detecting intrusion attempts
- responding to failures, ransomware and other incidents
With several or a dozen users, laptops, phones and remote access, this is not a one-time setup. It is an ongoing process that requires expertise, time and oversight. A well-managed law firm can create a secure local environment, but simply placing a server in the office provides no such guarantee.
The opposite is also possible: the system runs in a professional data center, but the documents are encrypted with a key that the operator does not hold. Stealing a drive, a database backup or a file repository is then not enough to access the contents of the files.
How are documents protected in Bezpieczna Kancelaria?
In Bezpieczna Kancelaria, each version of a document receives its own randomly generated key. The file is encrypted using the AES-256-GCM standard. We do not create our own encryption algorithm. We use established cryptographic mechanisms and the Google Tink library.
Each law firm has a separate set of keys. One organization's key cannot open documents belonging to another. Obtaining a single file or the entire repository of encrypted data is therefore not enough to read it.
The law firm's private key is not stored by the operator in a form that can be used. In persistent form, it exists only in encrypted copies intended for authorized users and in the recovery mechanism based on a 24-word recovery phrase, also known as a seed phrase. The phrase itself is not stored in Bezpieczna Kancelaria.
Bezpieczna Kancelaria stores encrypted documents but does not store its own key that would allow it to open them independently.
What happens after a user logs in?
An authorized user unlocks their key when logging in. Only then can the system open a document the user is authorized to access, at their request.
The unlocked key is not saved to disk or cache. It exists temporarily in the memory of the process handling the active session. Logging out, ending the session or restarting the process removes this capability. To read the documents again, an authorized user must unlock the key again.
The most precise description of this model is: Zero-Knowledge for original documents at rest, with session-based access initiated by an authorized user. We do not claim that the system never processes unencrypted content. It must do so when a logged-in lawyer opens a document or instructs the agent to perform a task.
Recovering an account does not mean recovering documents
In many services, the “forgot password” button allows the provider to restore access to all account content. This is convenient, but it also means that the service provider has retained a technical means of accessing the data.
In Bezpieczna Kancelaria, we can help a user recover their account, but this does not allow us to decrypt their files. Recovering the documents requires the seed phrase provided when the security measures were set up. If all authorized users lose their passwords and the law firm has not kept the seed phrase, the system operator will also be unable to recover the encrypted documents.
This is the simplest test of whether a claim about not holding the key is genuine. If the provider can recover all documents without the client's involvement, it means that it has retained a technical means of decrypting them.
The AI agent knows the way to the files but does not have its own key
It is easy to imagine that AI agents can freely read all of a law firm's documents around the clock. In Bezpieczna Kancelaria, the agent is not granted such permanent access.
The search index works like a catalog in an archive. It stores pointers that identify which document to search for an answer. It does not replace the original files or provide an independent means of opening an encrypted file.
The agent can access a document only when an authorized user is logged in, has unlocked the key and has requested a specific action. When the session ends, the agent loses its regular access to the documents along with the user.
If specific processing is to be performed after a file has been saved, it requires separate, one-time permission. The permission specifies its purpose and validity period and may only be issued during the session of a person with access to the document. It is not a permanent backdoor that allows the agent to return to the case files at any time.
Every time the system unlocks a document key, it leaves a record of who gained access, which version of the file they accessed, and when. Auditing does not replace encryption, but it allows the law firm to monitor how granted access is used.
An integration can deliver a document without being able to read it
Some tools need to upload new materials to the system without an active lawyer session. Examples include a voice recorder agent or an integration retrieving a document from an external source.
Such a tool receives only the law firm's public key. It can use it to encrypt and save a new file, but not to decrypt documents already in the system. It works like a deposit slot in a safe: you can put in another envelope, but you cannot remove or read any of the previous ones.
This upload-only mode is enforced by cryptography, not merely by a role assigned in the admin panel. Even if the integration tool is compromised, it does not gain access to the law firm's archive.
Can an entire SaaS system with an AI agent be Zero-Knowledge?
Yes, but this would require much more than encrypting the database. In the strictest model, a document should be encrypted on the user's device before it is sent to the provider. The private key should never leave that device. The AI agent would have to run on the user's computer or phone, or perform computations without receiving the document in plaintext.
If an agent running on the provider's regular server receives decrypted text, it cannot honestly be claimed that all processing is Zero-Knowledge. It can, however, be stated precisely that Zero-Knowledge or zero-access applies to the storage of original documents, while access to their content is temporary and controlled by the user's session.
There are also specialized, isolated computing environments that can verify which code was executed within them. They reduce the need to trust the operator, but they are still different from a setup in which decrypted content never leaves the user's device.
Claims about Zero-Knowledge AI should be read very carefully. The key questions are where the document is decrypted, who holds the key, and whether the agent can operate without the user's active consent.
A Zero-Knowledge certificate does not solve the problem
There is no single, widely accepted certificate that can confirm once and for all that any system is Zero-Knowledge. The architecture, code, and key management practices can be independently audited. However, the results always have a defined scope and apply to the system as tested.
A reliable report should identify the version of the code reviewed, the audit date, the scope of the audit, the identifier of the final build, and the assumptions and exceptions adopted by the auditors.
A digital signature can confirm that a specific build came from a particular source and was not subsequently modified. However, it cannot confirm on its own that this exact build is still running on the provider's server.
This can be compared to a technical assessment of a safe. The assessment remains valid as long as the lock model tested remains unchanged. If the manufacturer adds a second key or changes the locking mechanism after the test, the previous assessment no longer describes the new design.
In software, such a change could be a single line of code that stores an unlocked key in logs or sends decrypted content to an additional service. Not every change invalidates the entire assessment, but every change affecting keys, decryption, and data flows should be reviewed again.
- reviewing code changes
- controlled creation of new versions
- signing final builds
- logging deployments
- reassessing changes that affect access to documents
What should you ask a law firm software provider?
Instead of asking only whether the system is Zero-Knowledge, it is worth getting answers to more specific questions.
- Who holds the key needed to decrypt documents?
- Can an employee of the provider open a file without the law firm's involvement?
- Does password recovery automatically restore access to documents?
- Where is the key stored during an active session, and what happens to it after logout?
- Is a database copy, backup, or server image enough to read the case files?
- What exactly does the index used by the AI agent store?
- Can the agent read documents when no authorized user is logged in?
- What information is sent to external AI models?
- Is every document unlock logged?
- Which version of the system was covered by the latest independent audit?
Zero-Knowledge does not mean 100% security
No architecture eliminates every threat. If an attacker takes control of a logged-in user's computer, they may attempt to act with that user's permissions. If a lawyer shares a document with the wrong person, encryption cannot undo that decision either.
Key protection must be supported by session security, two-factor authentication, device controls, limiting access to people who are actually working on a given matter, and logging operations performed on documents.
However, Zero-Knowledge solves a very important problem: it reduces the trust the law firm must place in the system operator. The provider does not receive a backup key to all case files simply because it maintains the application and stores the encrypted files.
Whoever holds the key truly controls the documents
The debate between an on-premises system and a cloud service often focuses on the wrong question. A server located at the law firm may be poorly secured and accessible to many administrators. A server in a data center, however, may store files that the operator cannot read.
That is why we do not ask only where the data is stored. We ask first and foremost who holds the key, when it can be used, and what record each decryption leaves behind.
In Bezpieczna Kancelaria, original documents are stored using a Zero-Knowledge model while at rest. The operator does not hold a permanent key that can be used to read them. Access is available during an active session of an authorized user, within the scope of that user's permissions. An exception may be a specific task initiated by the user under one-time permission with a defined purpose and validity period.
This is not a promise that we will not look at your case files. It is an architecture designed so that, outside the law firm's controlled session, we have no key with which to open them.