Security at CURA
Last updated September 9, 2026 (v2.3)
CURA sits in front of your DMs, which means we owe you more than vague reassurance. This page is the specific list of what we do to protect your account and your messages — including the limits, stated plainly, because a security page that only brags is a marketing page.
Your platform passwords
In plain English: OAuth platforms: you sign in on the platform’s own screen and we never see the password. Other connection methods are stated honestly below.
For platforms connected through official OAuth (run for us by Composio or Unipile), you sign in on that platform’s own screen and CURA never sees or stores the password — the platform hands over a limited-permission key instead.
Two platforms work differently, and we say so rather than hide it. WhatsApp connects as a linked device (like WhatsApp Web): no password involved, but session credentials live on our servers while connected. Telegram signs in with your phone number and a code from Telegram; if your Telegram account has a two-step-verification password, Telegram’s own protocol requires it once to complete that sign-in — it is used for that step, not kept as your password. Some optional integrations accept API keys you paste in; those are stored encrypted.
Encryption at rest, and its limits
In plain English: Primary-database message content is encrypted at rest. CURA holds the key — this is not end-to-end encryption — and some working stores are not yet encrypted.
Message content in CURA’s primary database is encrypted at rest. If someone got hold of the raw storage, they would be looking at ciphertext. The server holds the decryption key in order to run the service, so this is protection against storage theft — not end-to-end encryption, and we will never call it that.
Honest limit: a few internal working stores (the inbox sync cache, WhatsApp linked-device session files, and call logs) are not yet encrypted at rest. They sit on access-controlled servers, and bringing them under the same encryption is active engineering work. This page changes when that lands.
Who can see your messages internally
In plain English: Our admin dashboards are built around usage metadata — counts and spend, not reading your conversations.
The dashboards we use to operate CURA are built to surface usage metadata: message counts, spend, token usage, quota. Running the service does not involve anyone reading your conversations, and security-relevant access is logged.
No internet service can honestly promise its operators could never access data the server can decrypt — that is exactly why the encryption section above refuses to claim end-to-end. What we promise is what we practice: content access is not part of operations, and the audit log exists so that claim is checkable.
Two-factor authentication, with recovery codes
In plain English: Add a second lock with any authenticator app. Lost phone does not mean lost account.
You can turn on two-factor authentication with any standard authenticator app. When you enable it, we give you one-time recovery codes to keep somewhere safe, so losing your phone does not lock you out.
It is optional, but we recommend it for everyone. It takes about a minute.
Rate limiting and short-lived tokens
In plain English: Automated attacks get throttled, and stolen tokens expire fast.
Our endpoints are rate limited, so brute-force and credential-stuffing attempts hit a wall before they get anywhere.
Session tokens are short-lived and signed, refresh tokens rotate, and reuse of a stolen refresh token is detected and shuts the session down. Even an intercepted token stops working quickly instead of granting access forever.
Payments go straight to Stripe
In plain English: Stripe processes every payment. There is no card number in our database to steal.
All billing runs through Stripe. Your card details go directly to Stripe and never touch our servers; the only thing we keep is your payment status.
That means CURA’s database simply does not contain card numbers, for anyone, ever.
Found a security issue? Tell us
In plain English: Email hello@curavision.ai. We read every report and we will respond like people, not a ticket queue.
We welcome good-faith security research. If you think you have found a vulnerability, email hello@curavision.ai with enough detail for us to reproduce it.
We read every report and we will get back to you. Please give us a reasonable window to fix the issue before sharing it publicly, and we will be straight with you about what we found and when it is fixed.