Security & data privacy

ChatData Sync is built on the principle that every tracking space belongs solely to its owner. Your data is never accessible to other users, and assistant access is strictly scoped to the single tracker you authorize — not your account, not other trackers.

Core security principles

🔒

Tenant isolation

Each tracking space lives in a separate Firestore collection boundary. Security rules enforce that only the verified owner can read or write project data. There is no path from one user's tracker to another's.

🗝️

Scoped assistant tokens

Each tracking space generates its own project-scoped access token. When you connect an assistant, it receives only the token for that specific tracker — not account-level credentials and not access to your other spaces.

🧱

Default-deny Firestore rules

All Firestore documents start with a default deny policy. Access is granted only through explicit rules tied to verified identity, project ownership, and token scope. Updates are constrained to approved field sets.

🛡️

Prompt sanitization

User-supplied schema descriptions and assistant inputs are normalized and scanned for prompt-injection control phrases before processing. Oversized or deeply nested payloads are rejected with explicit error codes.

How access control works at each layer

Your account

Account access uses Firebase identity (Google Sign-In). AI and project management endpoints require a verified Firebase ID token. Your projects are only visible when your identity token is present and valid.

Your trackers

Each tracking space has an ownerId that matches your authenticated account ID. Tracker reads return 404 (not 403) when the caller is not the owner — this prevents enumeration of other users' tracker IDs.

Assistant access

Assistants authenticate using a project-scoped API key. The key authorizes sync operations (read, write, update, list) on one specific tracker only. It cannot be used to access your account settings, other trackers, or the schema generation surface.

Records

Record reads return 404 when a document does not exist. Write operations validate the record against the table schema before saving. Schema upserts are always scoped to the calling tracker and can only match records already owned by that tracker.

Key rotation

API keys are server-generated and can be rotated at any time. Rotation is rate-limited and requires the existing key — it cannot be triggered by account credentials alone. Rotated keys are invalidated immediately.

Input limits

Request body size, object nesting depth, field count, and string length limits are enforced on every endpoint. Requests that exceed any limit are rejected before reaching business logic.

Common questions about data and privacy

Can my assistant access other users' data?

No. Assistant tokens are project-scoped. A token issued for your tracker cannot read or modify any other tracking space, regardless of who owns it.

Can other users see my tracker names or data?

No. Tracker list queries are scoped to your authenticated account. Requests for tracker details return a generic 404 if the caller is not the owner — the existence of your tracker is not revealed to others.

What happens to my data if I delete a tracking space?

All records in the tracking space are permanently removed. The project-scoped API key is invalidated. Your data is not retained for analytics, training, or any other purpose.

Is my schema description used to train AI models?

No. Schema descriptions you provide are used only to generate your data model. They are not shared, used for model training, or retained beyond the generation process.

Where is my data stored?

Data is stored in Google Firestore and served via Firebase App Hosting and Cloud Run. No data is stored outside Google Cloud infrastructure.

Start free — your data stays yours

Create a tracking space, connect your assistant, and see how isolation and scoped tokens work in practice.

Get started free