# How data privacy works

> Three privacy classes, enforced by the database itself: private per user, shared with members, or public to read.

Once your app has users, the most important question is: who can see which data? Vaulter is built so the safe answer is the default, and the rules are enforced by the database itself, not by code the agent might get wrong.

## Three privacy classes

Every table in your app is declared as one of three classes, and the platform generates the enforcement:

- **Private per user.** Each signed-in user reads and writes only their own rows. If someone creates a booking, saves a note, or uploads a file, that record belongs to them, and nobody else's account can see it. This is the class the agent uses for personal data.
- **Shared.** Every signed-in user of your app can read and write all rows. Right for genuinely collaborative data, like a team board everyone edits.
- **Public.** Anyone can read the rows, but only signed-in users of your app can write them. Right for content everyone browses, like a product catalog or an events list.

The agent declares the class when it creates a table, and you can see the resulting policy on any table with the **View Policies** button in the Database panel. The rules live in the database itself, so they hold no matter what the app's code does.

## Membership is the boundary

Behind all three classes sits one idea: your app knows who its members are. When someone signs in to your app for the first time, they become a member of that app, and every privacy rule checks membership plus, for private data, ownership of the row. Data in one app is never visible to users of another app.

## Signing in and reading data

Reading personal or shared data requires being signed in. That is what makes per-user privacy possible: the app has to know who you are before it can show you only your rows. Signed-out visitors can use your app's public pages, and can read tables you have marked public, but they cannot touch member data.

## Built-in profiles

Every app gets a `profiles` table automatically, holding each user's email, display name, and avatar. It is private per user by default, and it is how your app greets people by name after they sign in.

## Getting it right before you publish

Before you launch an app with real users, confirm the privacy behavior:

- Sign in as one test user, create some data.
- Sign in as a different test user, and check you cannot see the first user's data.

If anything is shared that should be private, or private that should be shared, tell the agent precisely who should see what, and it will change the table's class.

> Two separate decisions, often confused: **who can open the app** ([public vs private](/docs/auth/public-vs-private)) and **who can see which data** (this page). Setting one does not change the other.