Security and trust
Updated: August 2026 · This document is meant to let an information-security manager answer most of the questionnaire on their own
This English text is a convenience translation. If it differs from the Hebrew version, the Hebrew prevails.
Makor runs in one of two modes, at the firm's choice. By default it is installed on the firm's infrastructure, and case material does not reach us at all, so most of the standard questionnaire does not apply. A firm that does not want to run infrastructure itself gets a dedicated private server that we operate for it. In this mode the infrastructure is managed by us in an environment isolated to the firm alone, and our operational access is defined and controlled per the hosting addendum. The detail below distinguishes the two modes wherever they differ.
The deployment structure
Makor is deployed with Docker. In the first option it runs inside the firm's own infrastructure, and the matter material, the database and the outputs stay there. In the second it runs in a private, isolated environment we manage for that one firm, not in a shared service. In both, the installation makes no call back to us: licence enforcement is a digitally signed file checked locally. Providers and locations for each option are listed under Subprocessors.
The management channel: what an installation reports to us
An installation can open an outbound channel to our management server, so we can answer operational questions without asking you to log into your own server: which version you are running, whether the backup actually ran, whether the disk is filling up. The channel is outbound only: we open no port on your side, and there is no path by which we reach you. The installation calls us on a fixed interval, and if our server is unavailable it carries on using the last state it received. A failure on our side never stops work on a matter.
The channel is switched on by configuration. An installation that has not been configured for it makes no outbound call at all.
These are all the fields the channel carries. The payload is built in code from this very list, so a field that is not here cannot leave: install_id, product_version, licence_status,
uptime_s, disk_free_pct, job_queue_depth,
last_successful_backup_at, error_event_counts_by_category,
worker_cpu_ram_ceiling, configured, credential_health.
What never leaves over this channel: matter names, people's names, file names, documents, messages, facts, quotations, model prompts, generated text, search queries. Nor passwords, keys or access tokens: for a connection you have configured we know whether it is set up and whether it is healthy, never the secret itself.
Every action we take remotely, such as offering an update or switching a capability off, is recorded in your own audit log as well. You do not have to take our word for it: it is written down on your side.
What leaves the system
Ingestion, triage, local scan OCR, metadata extraction, local image descriptions, Hebrew search, quote verification, the fact ledger and output generation all run with no external call. In an analysis run, only the relevant passages are sent to the model provider. The run is initiated by a user, recorded in the audit log and stopped by the budget the firm set. The machine carries ordinary additional network traffic (operating system updates, clock, libraries), with no case material in it.
What is implemented today
| Control | Status |
|---|---|
| Encryption in transit | TLS 1.2 and above. The database is not exposed outside the machine |
| Multi-factor authentication | Support for physical security keys (WebAuthn / FIDO2) and TOTP, per the firm's security policy. A physical key cannot be copied, so it is the stronger of the two. We do not determine the firm's regulatory requirements for it, and the capability can be presented against your questionnaire |
| Matter-level permissions | Every matter functions as an ethics wall: the default is blocked, and access is granted on a need-to-know basis |
| Administrator access to content | Administrator access to content is not silent: taking access creates a logged, visible event in the firm's audit log |
| Audit log | Every login, access denial, permission change, setting change and model call. Retained at least 24 months |
| Idle timeout and lockout after failed attempts | Implemented |
| Backup | Nightly backup of the database and the document store, with an off-machine copy and an integrity check |
| Restore test | Performed and documented on an ongoing basis |
| Encryption at rest | Full disk encryption. It protects against disk theft and physical seizure; it does not protect against an attacker who already holds privileges on a running machine |
| Retention and deletion of material | The retention period is enforced in the database itself, not in a policy. Deletion inside an open matter is refused, and any override requires a reason that is written to the audit log |
| Local processing | Scan OCR, metadata extraction and image descriptions run on the machine itself, with no external call and no model cost |
| Our support access | Installed with you: no standing access; it is opened for a specific incident with prior approval and recorded in your audit log. Hosted by us: our team holds operational access to the infrastructure, in the scope and under the controls set in the hosting addendum |
The model: what leaves, where to and under what authorization
- The key is the firm's. The firm contracts directly with the model provider, and we do not mediate the call, do not see the account and do not become your data exporter.
- The content terms belong to the engagement between the firm and the provider. Since the firm contracts directly with the provider, what is done with the content, including not using it to train models, is set in the agreement between them and not in ours. We can point to the relevant clauses and go through them with the firm.
- Zero data retention (ZDR) is set in the firm's account with the provider. Content flagged by the provider's safety classifiers may be retained by it for a period even under ZDR.
- Models that do not meet zero data retention cannot be selected: they do not appear in the model list in the system settings, so they cannot be chosen.
- The AI components can be turned off. Ingestion, Hebrew search, quote verification, the fact map and building the case run with no external call. A firm that turns off the AI components in a given matter still gets a system that does a substantial part of the work.
Business continuity and exit
When installed on the firm's infrastructure, the system keeps working even if the engagement ends or Makor ceases to operate. It runs on the firm's hardware and does not depend on our continued existence. Licence expiry does not lock the matters: at the end of the grace period the system moves to read-only, where viewing material and exporting it always keep working, while opening a new matter, uploading material and running an analysis are blocked. Source-code escrow is also offered.
In the hosted mode the dependence is greater and is therefore governed: the hosting agreement sets an orderly exit, a full export of the material and the database, and the option to move that same installation to the firm's infrastructure. It is the same software.
Reporting a security vulnerability
Makor accepts vulnerability reports. We will not take action over a good-faith report that avoided harming data and left reasonable time to fix it.
- Write to security@makor-ai.com with the subject SECURITY
- Acknowledgement within one business day
- Status update within five business days
- A fix for a critical vulnerability within seven days of acknowledgement