How ClinikChat protects your clinic's conversation.

End-to-end encryption

Most team chat is encrypted in transit — the server can still read every message. ClinikChat encrypts each message on the sender's device for the intended recipients before it touches the network, and only your team's devices hold the keys to open it.

The cryptography is not homegrown. It is the standard NaCl "box" construction provided by TweetNaCl, an audited, widely used open-source library:

What this means concretely

• Each member's device generates its own X25519 keypair. The private key never leaves the device unencrypted — it is sealed with a key derived from the member's own credentials before it is ever stored.
• Every message is sealed on the sender's device for the recipients' public keys. The server routes and stores only the resulting ciphertext.
• There is nothing readable on the server to leak, subpoena, or browse. Even we — Praxentis — cannot decrypt your team's chat.

A technical evaluator can verify the primitive independently: nacl.box is X25519 + XSalsa20-Poly1305 as specified by NaCl, and TweetNaCl is public and reviewable. We are happy to walk a prospective clinic's security contact through the client-side encryption path on request.

Security assessment posture

We hold ourselves to a published standard and are candid about the stage we are at.

ClinikChat has completed an internal security self-assessment against the OWASP ASVS v4.0.3 at Level 2 (the level intended for applications handling sensitive personal data), most recently on 23/04/2026. The assessment maps to publicly documented methodologies — PTES, OWASP WSTG v4.2, and NIST SP 800-115 — and uses standard open-source tooling: Semgrep (SAST), Trivy and Grype (dependency and container scanning), Gitleaks (secret scanning), and Syft (SBOM).

Summarised result

• Authentication, session management, access control, and input validation: assessed as meeting ASVS L2.
• Stored cryptography: partial — end-to-end encryption is in place; at-rest database encryption is a deployment configuration.

Be clear about what this is. This is a self-assessment by our own engineering team, not an independent third-party audit. It demonstrates methodology and posture — it is not a certification. We have committed that on entering alpha testing with more than 15 users, or on first revenue (whichever comes first), we will commission an independent external penetration test from a CREST-certified firm, and that engagement's findings will supersede this self-assessment as our primary security evidence.

Where your data lives

ClinikChat is built to keep clinic data in Australia as a matter of architecture, not just policy.

• The API and realtime service run in Fly.io's Sydney region (syd).
• Encrypted attachments and backups are stored in AWS Sydney (ap-southeast-2).
• Built and operated in alignment with the Privacy Act 1988 (Cth) and the Australian Privacy Principles.

One honest exception. Mobile push notifications rely on Apple and Google's notification networks (and Expo's push service), which operate internationally. Delivering a push to a phone unavoidably shares a device push token and minimal metadata with those services — never message content, which stays end-to-end encrypted. This is disclosed in our privacy policy.

Reporting a vulnerability

If you believe you have found a security issue in ClinikChat, we want to hear from you. Please email privacy@praxentisai.com.au with enough detail to reproduce the issue, and give us a reasonable window to respond before any public disclosure. We do not currently run a paid bug-bounty programme, but we will acknowledge your report and keep you updated.