The short version
- No external AI provider. Model, speech and OCR all run on our own hardware inside the Kingdom — nothing to justify at a border.
- Authenticated encryption at rest, TLS 1.3 in transit, and full-disk encryption at rest.
- A hard 24-hour ceiling on message content, enforced hourly by a backstop that runs even when everything else fails.
- Encrypted nightly backups, round-trip verified, replicated to a second host in Riyadh — never outside the Kingdom.
- Consent is enforced by the server, not just shown in the browser.
- We publish what we do not have — no ISO 27001, no SOC 2, no third-party pen test yet. Section 10.
1. Where your data actually is
Elbi is not a wrapper around someone else's API. The language model, speech-to-text, text-to-speech and document OCR are all self-hosted on hardware we control inside the Kingdom. A customer message is answered without any part of it leaving that environment.
| Component | Where it runs | Third party involved |
|---|---|---|
| Language model (answers) | Our own GPU, in-Kingdom | None |
| Speech-to-text | Our own GPU, in-Kingdom | None |
| Text-to-speech | Our own GPU, in-Kingdom | None |
| Document OCR | Our own GPU, in-Kingdom | None |
| Retrieval index and database | Our own server, in-Kingdom | None |
| Ingress / TLS edge | the edge network | Transit only — DPA on file |
This is the difference that matters in a PDPL review: there is no OpenAI, Anthropic, Google or Azure key in the system, so there is no cross-border AI processing to justify, and no vendor whose retention policy overrides ours.
2. Encryption
| Layer | What we use | Verified |
|---|---|---|
| In transit | TLS 1.3, TLS_AES_256_GCM_SHA384. HSTS enabled | Negotiated live |
| Message content at rest | authenticated encryption, encrypted in the application before it reaches the database; key held outside it | Crypto self-test runs and logs on every scheduled job |
| Disk | Full-disk encryption on the data volume | Verified at provisioning |
| Backups | Encrypted with a separate key, and the encryption is round-trip verified before the backup is accepted | Logged on every run |
Only encrypted artefacts ever leave the host. The backup routine exits before replication if encryption fails, so plaintext cannot be shipped by accident.
3. Data lifecycle
Retention is a fixed number here, not a judgement call. See the Privacy Policy for the full table; the mechanism is:
- An hourly purge destroys the raw content of closed, analysed conversations.
- A backstop sweep in the same job destroys anything older than 24 hours whether or not the normal path ran. This is the control that matters: an earlier version of this system promised 24 hours and quietly kept messages for ten days when an analysis job failed silently. The backstop exists so a failure elsewhere cannot extend retention.
- A second hourly job does the same for live-agent conversations, which close on their own terms.
- Voice audio is never stored — the temporary file is deleted in a
finallyblock, whether transcription succeeded or failed. - Uploaded files are never written to disk — they are parsed in memory and discarded at the end of the request.
- Destroyed means overwritten in the database, not flagged hidden.
4. Access control
| Control | Detail |
|---|---|
| Authentication | bcrypt password hashing; email one-time code; optional TOTP second factor |
| Roles | Owner, Admin, Developer, Live Agent — least privilege, with a single-Owner invariant |
| Sessions | Secure, HttpOnly cookies; server-side session records; expiry and explicit logout |
| Brute force | Account lockout after repeated failures, plus network-level rate limiting |
| Audit log | Privileged actions are recorded with actor, action and timestamp |
| Dashboard scope | The analytics dashboard reads counts and quality scores. It cannot read message content. |
| Agent scope | A live agent sees a conversation only after the visitor asks for a human, and only while it is open |
5. Application security
- Server-enforced consent gate. Chat, menu selections and file uploads are refused unless a consent record exists. The gate is in the API, not only in the browser.
- Identifier redaction runs before storage and before the model sees the text — card numbers, national IDs, emails and phone numbers are stripped at capture.
- Prompt-injection resistance is a deterministic output guard, not an instruction in the prompt. Text telling the assistant to ignore its rules is described, not obeyed, and the system prompt is not disclosed. We learned this the hard way: a politely-worded rule in the prompt loses to the rules already there.
- Fabricated-claim guard. A reply that asserts a commitment on Elbetron's behalf which is not in the approved knowledge base is blocked and logged, and the guard checks against the knowledge base only — an uploaded document cannot launder a false claim into an answer.
- Upload safety. Extension allowlist, size cap, path-traversal sanitisation, page limits on OCR, and malware scanning.
- Rate limiting and abuse blocking at the edge, with automatic banning of repeat offenders.
- Answers are grounded in content you approve, and a relevance check runs before generation so out-of-scope questions are declined rather than guessed at.
6. Infrastructure and network
| Control | State | Verified |
|---|---|---|
| Host firewall | Active, default deny inbound | Current |
| Intrusion banning | Active | Current |
| Malware scanning | Active | Current |
| Reverse proxy | Route allowlist — an endpoint not explicitly published is not reachable from the internet | Live |
| Database | PostgreSQL, not exposed to the internet | Live |
Strict-Transport-Security | enabled | Live header |
Content-Security-Policy | frame-ancestors restricted to approved hosts | Live header |
Permissions-Policy | microphone=(self), camera=(), geolocation=() | Live header |
X-Content-Type-Options | nosniff | Live header |
Referrer-Policy | strict-origin-when-cross-origin | Live header |
7. Backup and recovery
Nightly: a database dump, a cache snapshot and the uploads directory, encrypted with a dedicated key, decrypted again and compared before the run is accepted — an unverifiable backup is treated as a failed one.
| Off-site replication | Yes — to a second host in in-Kingdom cloud , inside Saudi Arabia. Only encrypted files are transmitted. |
| Retention | 7 days local, 30 days off-site |
| Most recent verified run | Verified, replication confirmed |
| Failure handling | The job exits non-zero and reports. A previous version printed a tick and exited 0 while failing at every step; it was replaced for exactly that reason. |
8. Governance and documentation
The paperwork a Saudi procurement or SDAIA review will ask for already exists and is maintained, not drafted on request:
- Records of Processing Activities (RoPA) — PDPL Article 31, seven processing activities documented with purpose, lawful basis, recipients, transfers, retention and security measures.
- Data Protection Impact Assessment (DPIA) — risks and mitigations, including residual ones we have not solved.
- Breach Notification Runbook — who does what, in what order, within what deadline.
- DPO Decision Memo — the Article 30 assessment and its conclusion, with reasoning.
- Backup / Restore / Key Runbook — including key custody.
- Processor agreements on file — the edge network and the transactional mail relay.
These are internal records. We share them under NDA during procurement.
9. Testing and assurance
Security and behaviour are tested against the running system, repeatably, not asserted:
- A 643-case behavioural catalogue covering prompt injection, prompt disclosure, consent bypass, role escalation, upload abuse and PDPL rights.
- A hallucination and grounding suite scored by an independent judging pass.
- An 828-case retrieval benchmark across real phrasings in both languages, plus a 10,000-case mis-typed-input run.
- Concurrency and capacity runs to establish where the system degrades and confirm it degrades cleanly.
- Automated monitoring including an end-to-end reachability probe every 15 minutes that checks a real visitor can actually get the assistant — not just that the server is up.
10. What we do not claim
Every vendor page lists what it has. This is the part that is usually missing, and it is the part a security reviewer should read first.
| Claim | Status | Honest detail |
|---|---|---|
| ISO 27001 certification | Not held | Controls are implemented; no certificate has been issued. We will not imply otherwise. |
| SOC 2 report | Not held | No audit has been performed. |
| Independent penetration test | Not yet | Testing to date is our own, and is documented. A third-party test is the obvious next step. |
| Appointed Data Protection Officer | Not appointed | Assessed under Article 30 and found not mandatory at our scale. A named contact handles all data matters. |
| Consent gate on every endpoint | Partial | Enforced on chat, menu selection and file upload. The two voice endpoints do not check it — they store nothing, and the widget blocks access before consent, but the server-side check is not there yet. |
| Public client references | Not yet | We will not publish a client's name or logo without written permission. |
| Formal uptime SLA | Not published | We monitor availability but have not yet measured over a window long enough to commit to a number. |
If any of the above changes, this page changes with it and the date at the top moves.
11. Reporting a vulnerability
If you believe you have found a security issue in Elbi, tell us before you tell anyone else and we will work with you.
| global.business@elbetron.com — subject line SECURITY | |
| What to include | What you found, how to reproduce it, and what you think the impact is |
| Our commitment | Acknowledgement within 2 business days, and an assessment within 10 |
| Please do not | Run automated scanners against production, access data that is not yours, or degrade the service for others |
We do not currently run a paid bug bounty. We will credit you if you would like to be credited.