Security
Built paranoid.
An AI app builder has one unusual security job: it runs code nobody has reviewed yet, thousands of times a day. Kashvi's architecture starts from that fact — and this page explains exactly how, in plain language, including what we don't have yet.
The threat we design for first
Most platforms defend against malicious outsiders. An AI app builder has to defend against its own output too: every build produces fresh, unreviewed code that immediately runs in your browser. If that code could read your session, your other projects, or your connected keys, a single bad generation — or a malicious prompt hidden in pasted content — would be a disaster.
So Kashvi's first security decision is architectural, not procedural: generated apps never run on the platform's origin. Previews execute inside a sandboxed iframe served from a separate domain, which means the browser itself — not our goodwill — guarantees the app cannot touch your Kashvi account, tokens or files. The same isolation applies to every published app.
Everything else on this page builds on that foundation: scoped data so app users only ever see their own rows, hashed credentials everywhere, encrypted secrets, and a validation pass that checks every build before you see it. Security here is a property of the system, not a promise in a PDF.
The posture, in plain language
Generated code is untrusted by design
Every app preview runs in a sandboxed iframe on a separate origin from the platform. Code the AI writes — or a user pastes — cannot read your Kashvi session, your tokens, or any other project. The browser’s same-origin policy is the wall, and we keep the apps on the far side of it.
Credentials are hashed, sessions are opaque
Platform passwords are hashed with PBKDF2 (never stored, never logged). Sessions are random opaque tokens with server-side expiry; resetting a password revokes every existing session. Google sign-in is verified server-side against Google’s token endpoint.
Per-user rows in every generated app
Apps built on Kashvi get real authentication and a database where each end-user’s rows are scoped to them — list, update and delete operations carry ownership guards on the server, not just in the UI. End-user passwords in generated apps use the same PBKDF2 hashing as the platform.
Your keys are encrypted at rest
When you connect your own Supabase, your access token is encrypted (Fernet/AES) before it touches the database and is only decrypted server-side at the moment of use. API keys for the AI models live in server environment variables — never in code, never in the browser.
HTTPS everywhere
The studio, the API and every published app are served exclusively over TLS. Preview traffic, build streams and database calls all ride encrypted connections.
Your work is not training data
Kashvi builds with Anthropic’s Claude via the commercial API. Anthropic does not train models on API data by default — your prompts and code build YOUR apps, nothing else.
Compliance, honestly.
We do not yet hold SOC 2 or ISO 27001 certifications — most early products don't, and pretending otherwise is exactly the kind of dishonesty a security page shouldn't contain. Formal audits are on our enterprise roadmap. What we offer today is architectural transparency: this page describes the real system, and we answer specific security questionnaires directly.
Found a vulnerability? Email our disclosure address — we read every report and credit researchers who help us.
Security questions, answered
Is AI-generated code safe to run?+
Treat it like any code: review what matters. Kashvi’s job is to make the blast radius small — generated apps run in an origin-isolated sandbox where they cannot access your platform account, and every build passes an automated validation step before it reaches your preview.
Who can see my projects?+
Only you. Projects are private by default; publishing to a shareable link is an explicit action you take per project, and you can flip a project back to private at any time.
How is my app users’ data protected?+
Every generated app ships with per-user data scoping enforced on the server: a signed-in user can only list, edit or delete their own rows. End-user passwords are PBKDF2-hashed. If you connect your own Supabase, its row-level security and your keys stay under your control.
Where is data stored?+
Platform and app data live in a managed PostgreSQL database. Teams that need data residency or full control connect their own Supabase project — Kashvi migrates the schema but your instance, region and keys are yours.
Do you have SOC 2 or ISO 27001?+
Not yet — we are an early-stage product and say so honestly. Formal certifications are on the roadmap alongside our enterprise features. The architecture decisions on this page are how we protect you in the meantime.
How do I report a vulnerability?+
Email our security disclosure address with details and steps to reproduce. We read every report, respond quickly, and credit researchers who help us — responsible disclosure is always welcome.
Build on a system,
not a promise.
Start free, keep your code, and see the isolation for yourself.
Start building free →