AkinaAll posts

Privacy· 5 min read

Who can read your conversations with an AI companion

A specific answer for our own product, including the parts that aren't reassuring: what leaves our servers, what staff can see, and three things we haven't built.

People tell an AI companion things they haven't told anyone. That's most of the point. It also means the honest version of “is this private?” is longer than yes.

Here is the answer for our product, in the order the answers actually matter.

It is not end-to-end encrypted, and it can't be

This is the first thing to get straight, because “encrypted” appears on a lot of marketing pages in this category and it doesn't mean what it means in a messaging app.

In an end-to-end encrypted chat, the server holds ciphertext it can't read. That's possible because the server's job is only to pass the message along. Here, something has to read your message in order to reply to it. A language model cannot respond to text it cannot see. Any companion product claiming end-to-end encryption in the Signal sense is either misusing the term or has a very unusual architecture they should be explaining in detail.

What is true: the connection is encrypted in transit, and the database is encrypted at rest by the host. Those are real and worth having. They are not the same promise.

Your messages go to a third party

We don't run our own language model. Your messages — plus the parts of your profile and stored memories that go into the prompt — are sent to a model provider to generate each reply. Right now that provider is DeepSeek, whose API servers are in China.

That's a real thing to know before you type something you'd mind travelling. It's a deliberate trade: it's what makes a conversation cost a fraction of a cent, which is what lets the free tier be as generous as it is. We've built the model layer so that switching providers is a configuration change rather than a rewrite, which matters both for cost and for jurisdiction — but today, that's where it goes.

Who at Akina can see a conversation

In principle, an administrator can. That's true of essentially every product that stores messages, and anyone telling you otherwise is describing an architecture they'd have to prove.

What we can describe is how narrow the doors are:

  • The admin console needs two independent things — being signed in as one of a short list of accounts, *and* a separate password entered on that visit. Being logged in on someone's unlocked laptop is not enough.
  • To everyone else it doesn't exist. Requests from anyone not on that list get a 404, not a “forbidden”. A permission error is a confirmation that there's something there.
  • The safety review queue stores fragments, not conversations. When a message trips a content rule, what gets kept for review is the text immediately around the match. Deciding whether a rule is misfiring does not require a copy of somebody's evening.
  • Data exports contain counts, not content. The CSVs an operator can download hold message *volumes*, spend, levels — no message bodies.

The exception, and it deserves to be named rather than buried: a database backup contains everything. Every conversation, in full. There is no way to make an operable product without the ability to take one, so instead the button that produces it sits behind a warning saying it's the single most dangerous artefact this product can create. That's not a control. It's a label on a sharp object.

What we deliberately don't do

  • No ads, so no ad tech. There's no third-party tracking script on the site, because the moment there is one, “who can see this” stops being a question we can answer.
  • Conversations and results are excluded from search engines at the crawler level, not just with a meta tag. Your results page has a shareable link because *you* might want to share it — that's different from it being indexed under your name.
  • We don't sell or share data with anyone, and the only third party in the path is the model provider named above.

Three things we hadn't built

This is the part most privacy pages leave out, which is what makes them useless. When this post first went up, all three of these were missing. They aren't any more, and the original wording is kept below so you can see what was promised against what shipped.

  1. You can't see what's been remembered about you. Built. Our memory system extracts facts from conversations, and every companion now has a memory page listing them — which ones are currently in play, which have faded, and a way to correct, delete, or add one. It's linked from the top of any conversation.
  2. There's no self-serve export or delete yet. Built. Your account page produces one JSON file with both sides of every conversation, every memory, every entry she wrote while you were away, and your quiz answers — and deletes all of it on request, without emailing anyone.
  3. There's no published privacy policy yet. Built. The privacy policy is up, and it names the third-country transfer in the body rather than leaving it in a blog post. There's a terms of service too.

How to interrogate any companion app

Four questions, and the useful signal is often whether you can find an answer at all:

  1. Whose model generates the replies, and in which country does that run?
  2. Can staff read conversations, and under what circumstances?
  3. Can you export everything, and can you delete everything?
  4. If they say “encrypted”, encrypted from whom?

None of these has a shameful answer. Storing messages is not a scandal; needing a model to read them is unavoidable. The tell is vagueness — a product that says “your privacy is important to us” and can't tell you whose servers the text lands on has decided the question is a branding exercise.

We put the same four questions to the rest of the category in our comparison of companion apps, including the ones where we couldn't get an answer.

Find out where you sit.

13 questions, about 60 seconds. No account to see your result, and 5 messages with whoever we match you to before anyone asks you to sign up.

Take the test

Keep reading