1 · Threat model
Sanad is built for organisations that treat their internal documents as sensitive: government bodies, banks, audit and legal firms, healthcare providers, and any team handling personally identifiable information. Our threat model is shaped around three adversaries:
- External attackers intercepting cloud traffic. Mitigation: Sanad does not send your prompts or documents to any cloud service.
- The vendor (us) reading customer data. Mitigation: we have no infrastructure that receives prompts or documents. There is no possibility of accidental disclosure because there is no data path.
- Compromised dependencies exfiltrating data. Mitigation: every release dependency is pinned and reviewed, the LLM and embedding services run on localhost, and the licensing client is the only network-facing component.
2 · What crosses the wire
Sanad's desktop process initiates outbound connections in only these situations:
| Event | Destination | Payload |
|---|---|---|
| License activation / refresh | license.sanadhq.app | License key, admin email, hostname, device label. |
| Initial model download | huggingface.co | Anonymous HTTPS GET. No identifying data. |
| Optional organisation server | Your server | Only if your IT team configured one. Stays on your LAN. |
No analytics SDK is bundled. No crash-reporting SDK is bundled. The application binary contains no third-party telemetry pixel or beacon. We do not have a path for emitting product-usage events even if we wanted to. This is verifiable by inspecting the bundled node_modules manifest in the installer — happy to walk an IT auditor through it.
3 · Licensing & signatures
Every Sanad install holds a signed license file at %APPDATA%/Sanad/license.json. The file is signed with Ed25519. The public verification key is embedded in the desktop binary at build time; the private key lives only on our licensing server in Muscat, never on a developer machine.
Signed license files are valid for 30 days. The desktop client attempts to refresh ~24 hours before expiry and falls into a 30-day grace period if the server is unreachable. Past that grace, the application blocks until it can reach the server again.
Revocation is vendor-controlled — we cannot remotely "kill" a running install, but we can refuse to refresh its license, which causes the install to block within 60 days at most. Each device has a human-readable identifier (e.g. ROHM-007) so administrators can revoke specific machines without ambiguity.
4 · Dependencies & supply chain
The desktop app uses Electron, React, and llama.cpp; the licensing server uses Express, better-sqlite3, and Node's built-in crypto module. Every direct dependency is pinned in the source tree; we run automated security audits before each release and publish the full dependency tree on request.
Pre-trained model weights are downloaded once at first run, then pinned by SHA-256. Subsequent launches verify the hash before loading. Upgrades require a deliberate user action.
5 · Deployment topology
A typical Sanad deployment looks like this:
- Each user runs the desktop app locally. The LLM and embedding services bind to localhost on the user's machine.
- Optional: an Organisation Server runs a larger model on shared hardware. Clients on the LAN connect over HTTPS with mutual auth; they fall back to their local model if the server is unreachable.
- The licensing server lives at license.sanadhq.app. Clients connect once a month for activation and refresh.
There is no other Sanad-operated service that customer endpoints contact during normal operation.
6 · Compliance roadmap
- Oman PDPL (Royal Decree 6 / 2022) — our Data Processing Addendum is framed around it. Available on request alongside the standard contracts.
- Oman NCSC self-attestation — in progress, targeted Q3 2026.
- ISO 27001 statement of applicability — in progress, targeted Q1 2027. Full certification audit deferred until first 10 customers are live.
- Independent penetration test of the licensing server — commissioned for late 2026; attestation letter will be published here.
7 · Reporting a vulnerability
We commit to acknowledging vulnerability reports within 72 hours and providing an initial assessment within 14 days. Critical issues are patched within 30 days. Reporters are credited in the release notes unless they request anonymity.
Reach security at security@sanadhq.app. PGP key on request.