Is Continio Secure? An Honest Answer.

This is the question I would want to ask if I were you.

I've written about building Continio through vibe coding - using AI as a development partner without a formal engineering background. The natural follow-up is: okay, but is it actually secure? Does the code hold up? Should I trust it with my conversations?

The honest answer is: better than you might expect, not as hardened as a funded team product, and I'm going to tell you exactly where things stand.

What's actually in place

Authentication is handled by Supabase, a proven platform used by thousands of production applications. Your login is not something I wrote. JWT tokens are verified on every request using Supabase's public key infrastructure, with algorithm pinning and expiry checking. There is no way to get a response from the API without a valid, non-expired token tied to your account.

Every database query that returns or modifies your data is filtered by your user ID. Your threads, messages, and memory anchors are not accessible to another user's request. Queries use parameterised values throughout - the standard protection against SQL injection - and I run checks to make sure this stays true as the codebase grows.

Payments are handled entirely by Stripe. I do not touch card numbers at any point. The webhook that updates your subscription status verifies Stripe's cryptographic signature and rejects anything that doesn't match or is more than five minutes old.

Rate limiting is active on the API: per-minute and per-day caps per user, which prevent runaway usage whether accidental or malicious.

Row-level security is enforced on all eighteen database tables. On every deploy, the startup process not only enables RLS but actively creates the correct access policies if they do not already exist. the policy on every table is: only return rows where user_id matches the authenticated user. This runs automatically, table by table, before the server accepts any traffic.

How I check and maintain this

Security is not a one-time decision. I review the codebase regularly against a checklist that covers the areas an independent reviewer would look at: authentication flows, data isolation, input handling, API exposure, third-party integrations, and server configuration. When I find something, I fix it. That practice is baked in, not occasional.

The checks I run cover: confirming that every endpoint that should require authentication does, that no query returns another user's data, that no credentials are hardcoded in the codebase rather than environment variables, that third-party webhooks are cryptographically verified before being trusted, that rate limiting is active, and that the app rejects malformed or oversized requests before they reach the database. I scan dependencies for known CVEs on a regular basis. At the time of writing, there are none.

Token handling on the frontend is worth naming specifically because it's a common failure point. Continio does not store your auth token in localStorage. Tokens are fetched fresh from Supabase's auth SDK per request and never written to persistent browser storage. The only thing in localStorage is your theme preference.

What isn't in place yet

I haven't had an independent security professional review the code. That is the honest gap. I can read for obvious issues. I can run the standard checks. I cannot replicate the pattern recognition of someone who has spent years finding the non-obvious ones.

A professional security review is on the roadmap before Continio moves out of early access into general availability. That is a specific commitment, not a vague aspiration, and I will write about it when it happens.

What this means for you

Your conversations are yours. They are not used to train models, not sold, not shared. The memory system is visible and editable - you can see exactly what Continio knows about you and remove anything you want. That is an architectural decision, not a feature added afterwards.

If you are using Continio for genuinely sensitive professional work - legal matters, medical decisions, commercially sensitive strategy - I would recommend keeping that material in a separate, appropriately secured system until the independent review is complete. That is not hedging. That is me being honest about where we are.

For most everyday use - thinking through problems, writing, planning, working through ideas - the current posture is appropriate.

The broader point

Security is not a box you tick once. It is a practice. The question is not whether a vibe-coded product can be secure - it is whether the person building it takes it seriously, catches problems, fixes them, and is honest about what they do not know yet.

I take it seriously. I am fixing what I find. And I am telling you about it.

---