Security architecture
Security decisions follow OWASP ASVS 5.0, OWASP Top 10:2025, NIST SP 800-63B-4 and the OWASP cheat sheets. Here is what that means in practice.
In short: HealthIntelligence reaches HealthVault only through four independent locks, requires two-step sign-in, stores no health records, encrypts every secret, and runs as a sandboxed service with strict browser security policies.
Last updated
Only HealthIntelligence can call the HealthVault integration API, and only with all four: a client certificate from a private authority over TLS 1.3, an Ed25519 signature on every request with single-use nonces and a 60 second clock window, your own scoped and revocable connection code, and responses encrypted to our key with X25519, HKDF-SHA256 and AES-256-GCM and signed by HealthVault. A response that fails any check is discarded.
Passphrases of at least 15 characters (any language and symbols), checked against common and breached passwords using k-anonymity, stored with Argon2id and a separate server secret. Two-step sign-in with an authenticator app is mandatory, codes are single use, recovery codes are one-time, and repeated failures lock the account.
HealthIntelligence does not keep your health records. They are read when you run an analysis, processed in memory and dropped after at most 10 minutes or when you sign out. The connection code, the authenticator secret and your optional profile are encrypted with AES-256-GCM, bound to your account.
Strict Content Security Policy with no inline code, HSTS, frame blocking, cross-origin isolation, SameSite=Strict host-only cookies, CSRF checks on every write, request size limits, generic error messages and no third-party scripts, fonts or trackers.
The service runs as its own unprivileged user under systemd sandboxing (read-only system, private temp, no new privileges, restricted system calls and address families), listens only on the local interface behind the TLS proxy, and receives keys as systemd credentials.
More than 270 automated tests, including 100 synthetic European personas and dedicated security tests for sessions, CSRF, throttling, enumeration, encryption, tampered HealthVault responses and replay. Static analysis and dependency audits run before every release.
| Locks to HealthVault | 4 independent (mTLS 1.3, Ed25519 signature, your grant, sealed response) |
|---|---|
| Passphrase | 15 to 128 characters, breach-checked |
| Password hashing | Argon2id, 19 MiB, 2 passes, plus server pepper |
| Two-step sign-in | Mandatory, 30 second codes, 10 recovery codes |
| Session | 15 minutes idle, 8 hours maximum |
| Health data stored | None (in memory for at most 10 minutes) |
| Automated tests | 377, including 46 security tests and 100 personas |
| Sandbox exposure score | 1.2 (systemd, "OK") |
| Price | 0 EUR during the pilot |
No.
Records are parsed by deterministic, auditable code. Content inside your documents is treated as untrusted data: it is pattern-matched, never followed. Nothing is sent to analytics, advertising or AI services.
Found a vulnerability? See security.txt and write to me@karllillrud.com. Please do not access other people's data.
No health records are stored, so there is nothing to browse. Records are read from HealthVault only while you run an analysis and are dropped within 10 minutes.
They still need your authenticator code. After 10 failed attempts the account locks for 15 minutes, and every sign-in appears in your security events.
No. The code only works together with the HealthIntelligence client certificate and signing key, and you can revoke it in HealthVault at any time.
No. No health content is sent to any AI language model, analytics or advertising service.
