Security
Last updated 14 September 2026. Only measures that exist are listed. What is missing is listed as missing.
Why this page is blunt. A lonely person tells a companion things they tell nobody else: what hurts, what they are afraid of, who has stopped calling. If that leaked it would not be an inconvenience, it would be a humiliation. So this page states what is actually in place and, at the end, what is not yet.
Where things stand
A dedicated machine in the EU, not shared hosting. Provider: Hetzner Online GmbH.
Speech is processed live. No recording exists to leak, subpoena or lose.
Certificates from Let's Encrypt, renewed automatically.
A long random token per person. No shared accounts, no passwords to reuse or lose.
Password login to the server is disabled entirely.
How one person's memory stays theirs
This is the risk that matters most in a service like this: someone opening a conversation and hearing about a stranger's life, or worse, their own life being read by someone else.
Every request carries the person's own token. Every memory lookup is scoped to that token at the database level, so there is no query that can return another person's episodes. Tokens are long and random, not sequential, so they cannot be guessed or walked through by incrementing a number.
We test this on every code change. Two companions are created, one is given a memory, and the test then tries to reach it through the other's token. If it ever succeeds, the change does not ship. It is not a policy on a page, it is a test that has to pass.
What leaves our server, and what does not
Stored on our machine only: conversation text, memory, profiles, names of family members, dates, health and mood notes.
Leaves our machine: the live speech and text of the conversation, to the speech model vendor named in the privacy policy, for recognition and reply. Under their API terms that content is not used to train models. This is the only part of a conversation that goes anywhere else, and we would rather say it plainly than let you discover it.
Sent nowhere: nothing is sold, nothing goes to advertisers, and there are no analytics or tracking scripts on this site at all. There is no cookie banner because there is nothing to consent to.
Looking things up without leaking
When James finds a clinic, a book or a recipe, he queries open public services: OpenStreetMap, Open Library, Wikisource, TheMealDB. They receive the search term and an approximate area, never a name and never anything else from the conversation.
We use real sources deliberately rather than letting a language model answer from memory. A confidently invented clinic address, given to someone who needs a doctor, is a safety failure and not a cosmetic one.
Emergency messages
Only the message itself and the recipient's identifier go to the messaging provider. The conversation does not. Every attempt is logged with its result, and a failure is reported out loud to the person rather than silently swallowed. Believing help is coming when it is not is the worst outcome this system can produce, so it is treated as a security property, not a nicety.
Keeping the software honest
- Automated tests run before every deployment, covering memory isolation, refusal to invent a past conversation, honest reporting of failed messages, and the crisis rules.
- Every file changed on the live server is backed up first, with a timestamp, so a bad change can be reverted immediately.
- Secrets are kept in files readable only by the service account, never in the page, never in the repository.
- The system prompt forbids inventing memories. The test suite checks the behaviour, because a rule in a prompt is a request and a test is proof.
What is not in place yet
Listing these is the point of the page. Anyone can claim the good parts.
- No independent security audit. No external firm has reviewed this system. We will say so on this page when one has, with the date.
- No ISO 27001 or SOC 2 certification. We have neither and do not imply otherwise.
- Disk is not encrypted at rest. The server has full-disk encryption disabled, which is normal for a machine that must reboot unattended, but it means physical access to the host is a real risk boundary. We rely on the provider's data centre controls for that.
- No two-factor authentication on accounts, because there are no passwords: access is the private link. That is simpler for an 80-year-old and it also means a leaked link is a leaked account. Tell us and we reissue it immediately.
- No formal bug bounty. But see below, and we answer.
If you find a problem
Write to security@hellojames.io or legal@hellojames.io. Tell us what you found and how to reproduce it. We reply within 72 hours, we will not threaten you, and we will credit you if you want that.
If you believe data has been exposed, say so in the subject line and we treat it as an incident immediately: authority notified within 72 hours where required, and affected people told directly in plain words.