ChatData Sync keeps each tracking space isolated to its tenant. The owner controls explicit collaborator access, and assistant access is limited to the single tracker and policy you authorize — not your account or other trackers.
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.
Each tracking space supports a legacy project key and named assistant connections. A named connection receives only the permissions, sections, fields, and lifetime you choose — not account-level credentials and not access to your other spaces.
All Firestore documents start with a default deny policy. Access is granted only through explicit rules tied to verified identity, project ownership, sharing, and credential scope. Updates are constrained to approved field sets.
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.
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.
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.
Assistants authenticate using a named connection secret or the legacy project-scoped API key. Named connections authorize only the allowed sync operations, tables, and fields on one tracker and are checked for active status and expiry. They cannot access your account settings, other trackers, or the owner-only schema generation surface.
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.
Project API keys can be rotated from tracker settings. Named connections can be suspended, rotated, or revoked independently. Named secrets are shown only at create or rotate time; the server keeps a hash and a hash-derived fingerprint, and inactive or expired credentials stop working.
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.
No. Assistant credentials are tracker-scoped. A credential issued for your tracker cannot read or modify any other tracking space, regardless of who owns it. A named connection can also be restricted to selected operations, tables, and fields.
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.
All records in the tracking space are permanently removed. The project-scoped API key and named assistant connections are invalidated. Your data is not retained for analytics, training, or any other purpose.
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.
Data is stored in Google Firestore and served via Firebase App Hosting and Cloud Run. No data is stored outside Google Cloud infrastructure.
Create a tracking space, connect your assistant, and see how isolation and least-privilege connections work in practice.
Get started free