# Security overview

> How Vaulter isolates apps, protects the preview, and keeps your data safe.

Security is built into how Vaulter works, so the safe defaults are the ones you get without thinking about it. Here is a plain-language overview of what protects your apps and your data.

## Apps are isolated

Each app's data lives in its own isolated space on the backend, and every access rule checks which app is asking. One app cannot reach into another's data, even though they share infrastructure, and two apps can define identically named tables without ever touching each other. When you publish, your app is served from Vaulter's edge network over HTTPS, with certificates managed for you, including on custom domains.

## User data is private by default, in the database itself

For apps with sign-in, data privacy is enforced by the database, not by app code. Every table carries a declared [privacy class](/docs/data/data-privacy): private per user, shared with the app's members, or publicly readable. The rules are generated by the platform rather than hand-written by the AI, and they check both app membership and row ownership on every query. Even if the app's code had a bug, the database would still refuse to hand one user another user's rows.

Two extra guarantees behind that:

- The agent is not allowed to write its own security predicates, and it can never drop tables.
- A table created without a declared privacy class is denied by default, rather than left open.

## Sign-in is handled by one hardened surface

Your users authenticate through Vaulter's [hosted portal](/docs/auth/sign-in-portal): passwordless email codes and major identity providers, with session handling done once, centrally, for every Vaulter app. Publishing runs a consistency check so an app with a sign-in page but no working account system cannot ship.

## Secrets stay out of code, and away from the AI

API keys and service credentials live in [Vaulter's connection layer and Vault](/docs/data/secrets-vault), not in your app's files. Your app uses third-party services through server-side calls that attach credentials on the way out, so keys are never sitting in the browser. The agent can check that a secret exists, but can never read its value.

## Your part

The platform handles the infrastructure, but a few choices are yours:

- Decide whether your app requires sign-in, and who can register. See [Public vs private apps](/docs/auth/public-vs-private).
- Confirm data is classed the way you intend: test with two accounts and check that private data stays private.
- Keep secrets in the Vault, never pasted into chat or code.
- If you [bring your own Supabase](/docs/data/byo-supabase), the project is yours; review its access rules before launch.

If you have a security concern or believe you have found a vulnerability, contact us through [support](/docs/reference/troubleshooting) and flag it as security-related; those reports go to the front of the queue.