Security
How we protect your data
Your assistant holds your knowledge base and your customers' conversations. Here is specifically what protects them.
Your data stays yours
Everything you put in, you can take out: conversations, leads, appointments, your knowledge base and your full account record, as CSV or JSON, from the dashboard, whenever you like — no request to us and no waiting.
Deleting your account removes your data rather than hiding it — the transcripts, the leads, the knowledge base and the settings all go with it. We do not sell your data or your customers' data, and AskLeya does not train any model on your conversations. Answering a question does send it to an AI provider, whose own data policy then applies — which provider, and what it sees, is in the table below.
Where it lives
Your content sits in a managed PostgreSQL database, encrypted at rest by the provider and reachable only over TLS with credentials. Our application server exposes nothing but HTTPS and SSH — every other port is closed at the firewall — and the database credentials live in the server's environment, never in the codebase or a repository.
Card details never reach us at all. Payments go directly to Stripe, and we store only a customer reference and which plan you are on.
Encrypted in transit
Every request to the site, the dashboard, the API and the chat widget is served over TLS. HTTP is redirected, and we send HSTS with a one-year lifetime so browsers refuse to fall back. Certificates renew automatically, so none can quietly expire.
Your keys and tokens, encrypted
If you bring your own AI key, or connect a messaging channel, that credential is encrypted with AES-256-GCM before it is stored, under a key held outside the database. A copy of the database alone does not reveal them. They are never returned by the API, not even to you.
Passwords we can't read
Passwords are hashed with bcrypt — we cannot read yours, and neither can anyone who obtains the database. API keys are stored the same way, as a SHA-256 hash with only a short prefix kept so you can tell them apart, and any key can be revoked instantly.
Changing your password ends other sessions
People change a password because they think someone else has it, so the change has to mean something. It signs out every other session immediately — as does resetting your password, or removing someone from your team. No waiting for a token to expire.
One account can't reach another
Every read and write is scoped to your account, and the scope is re-read from the database on each request rather than trusted from a token. So when you remove a teammate's access, it stops on their next click — including any live chat they have open.
Limits on abuse
Sign-in, sign-up, password reset, chat, booking and lead capture all carry rate limits — per address and per account, so neither one host nor a spread-out list gets unlimited attempts. Inbound webhooks are rejected unless they carry a valid HMAC signature.
Who else is involved
Running AskLeya takes a small number of established providers — managed database hosting, an AI model provider, a CDN for the images you upload, and an email service for account and lead notifications. Each acts only on our instructions and only for that purpose. None of them is given your data for their own use, and we don't sell it to anyone.
Payments are the exception worth naming: they go directly to Stripe, so card details never touch our servers at all. We keep only a customer reference and which plan you are on.
The privacy policy sets out each category and what it handles, and customers can have the current named list on request. If you bring your own AI key, your questions go to your chosen provider instead of through ours.
Found a vulnerability?
Please tell us before you tell anyone else. Email support@askleya.io with “Security disclosure” in the subject and enough detail to reproduce it. We'll confirm we've received it, keep you posted on the fix, and credit you if you'd like.
We ask that you don't run automated scans against production, don't access or alter anyone else's data, and give us a reasonable chance to fix it before publishing. We won't pursue anyone who reports in good faith on those terms.