Last updated: October 2026
You give us your birth details and your most personal questions, so you are owed a straight account of what happens to them. This page says how that data is stored, what we deliberately leave readable and why, and what stops this description from drifting away from the code.
Your birth details and your conversations are encrypted and locked under a key before they are written to our database. Your birth date, your birth time and your birthplace are encrypted. So is everything written for you or by you: your natal reading, the interpretations behind it, your daily insights, your monthly forecasts, your family readings, the questions you ask along with the answers we give back, and the answers people gave to the optional "how did you hear about us?" box at sign-up.
The cipher is AES-256-GCM. Every value gets a fresh key of its own, made at the moment it is written and used for nothing else. That key is then sealed by our main key and stored beside the value it belongs to.
Each value is also bound to its field, the exact place it lives. If a stored value were moved or swapped into a different field, it would refuse to open rather than quietly read as something it is not. Tampering fails loudly instead of passing unnoticed.
Our search index and our logs carry identifiers only: which row an answer came from, never the text of it. The text lives in one place, encrypted.
The key is held by us: our servers hold the main key. So this protects against a stolen copy of the database, not against us. Anyone who ends up with a copy of the database and not the key, such as a stolen backup, an old disk or a leaked replica, sees only locked data.
We do not read your birth details or your conversations. No astrologer and no support agent opens your chart, and no member of our team takes part when an answer is produced: every reading is generated automatically. That is an operational promise, kept by how we build and run the service and backed by technical controls. It is a promise, not a mathematical impossibility, and we would rather you knew which of the two you are being offered.
One thing is read by a person on purpose: the optional "how did you hear about us?" answers from sign-up. If someone wrote in that box, we read it, because that is the whole reason it was there. A recommendation from a friend is invisible to every other way we have of knowing how people find us. Those answers are stored encrypted like everything else, are never sent to an advertising or analytics provider, and are deleted with the account.
One further limit, stated plainly: to write a reading or answer a question, the text involved is decrypted in memory and sent to the AI model provider that writes it. Encryption describes how your data is stored. It is not a claim that your words are never handled in readable form.
A few things are stored in plain form on purpose, because encrypting them would break the one job they exist to do. Each is a written, reviewed decision rather than an oversight, and here they are in full.
Your email address. It is what we look you up by when you sign in, and that lookup has to match exactly. Every encrypted write produces different ciphertext, so an encrypted address could not be matched at all. It is also the address you already gave us to send mail to.
The name you give a chart, and the gender recorded on it. Both are used to sort and list your charts. This is the weakest part of the picture and we know it: it is marked for a second look rather than settled, and we would rather say so here than leave the two out.
The machinery around your content: status flags, timestamps, which model produced a reading, and the internal ids that link one row to another. None of it holds birth data or anything you wrote.
A description of encryption is worth exactly what enforces it. Ours is a test that runs in our build and reads the database schema itself.
It carries two lists: the fields that must be encrypted, and the fields deliberately left readable, each with its reason written next to it. If a field in the first list is ever turned back into plain text, the build fails and names it. If someone adds a new field that could hold your writing or your birth details and puts it in neither list, the build fails then too. An unclassified field is treated as a mistake rather than given the benefit of the doubt.
That rule is the durable part, which is why we do not quote a tally of encrypted fields. The list grows every time the product grows a new kind of reading. What stays constant is that a new home for your content cannot ship until somebody decides, on the record, whether it is encrypted, and the build holds them to that decision.
We wrote the check after finding the failure it prevents. Two kinds of reading were once stored as plain text while our own privacy page implied otherwise. Both are encrypted now. The test exists so the next drift of that kind is caught by a build rather than by a reader.
This describes how your data is stored. It is not a security audit, and we have no third-party certification to point at. If that changes we will name it here rather than imply it.
When you delete your account the rows are deleted outright, with no retention window, and the entries in our search index go with them.
For the wider picture (what we collect, who else processes it and the choices you have), see the Privacy Policy.
This page is a plain-language summary provided for transparency and is not a substitute for formal legal advice. Questions? Email hello@astrosignal.ai.