Data & privacy

Status: needs your legal/security team's review before publishing externally. Every claim below is derived from the codebase as of 2026-05-25. Items marked needs verification require engineering sign-off; items marked gap are honest acknowledgements of things that aren't yet in place.

This page explains what happens to your data when you use Tattva.

Where your data lives

• Source files (the CSV / Excel / PDF / audio bytes you upload) live in Google Cloud Storage under the operator's GCP project. The platform stores only a gs:// pointer in its database — never the file bytes.
• Source rows for analytics queries are processed by DuckDB in-process on the application server (in-memory) or by BigQuery live (for warehouse sources). They are not copied into the platform's Postgres database.
• Reasoning runs (questions, answers, tool calls, intermediate steps) are stored in Postgres for replay and auditability. This includes the full text of your questions and the full text of the platform's answers.
• Embeddings — vector representations used for semantic search — are stored in Postgres pgvector columns.
• Audit events are stored in Postgres.

What's sent to AI providers

This is the most important section. When you ask a question, parts of your data are sent to third-party AI providers to compute the answer. Specifically:

Important — agent queries can return PII to the model. When the reasoning agent runs a SQL query against your DuckDB or BigQuery source and that query returns rows containing PII (names, emails, phones, addresses), those values are passed back to the LLM provider to compose the answer. The platform's ontology profiler avoids previewing PII column values, but the reasoning agent itself does not strip PII before returning rows. If your data contains PII you do not want sent to AI providers, scope the agent's queries accordingly (e.g. don't expose those columns to it in your ontology, or restrict the source's visibility).

This is the single most important thing to know about the platform. Bring it up explicitly with your security/legal team before connecting any sensitive source.

Prompt caching

Anthropic's API caches stable parts of prompts for up to 5 minutes on their servers to make repeat queries faster. The platform takes advantage of this. Cached content is held by Anthropic per their caching documentation.

Data residency

• The platform is deployed on Google Cloud. The deployment region is set by your operator (typically asia-south1 for Kapiva, but check with your admin).
• AI providers are US-based by default: Anthropic, OpenAI, Voyage AI, AssemblyAI. Google Gemini is multi-region.
• gap — there is no per-workspace or per-project provider region pinning today. If you have data-residency requirements, talk to your admin before connecting sources.

Embedding deletion propagation

When you delete a source, the platform deletes the rows from its database and the underlying GCS file. The embeddings in Postgres pgvector are cascade-deleted with the source. However, embeddings already computed by Voyage AI sit on Voyage's infrastructure and are subject to their data retention policies — the platform does not call out to Voyage to purge them.

Audit logging

Every administrative action (member changes, project deletes, API key creation, source uploads from API key auth, ontology mutations, login/logout) is written to an immutable audit log. needs verification: the audit log is intentionally selective — it captures administrative / structural actions, not every read or every reasoning run. If you need full read-level audit, talk to your admin.

Each event includes actor, action, target, timestamp, and a hashed IP (sha256-truncated — raw IP is never persisted). User-Agent is captured raw.

Encryption

• In transit: all outbound calls to AI/embedding/transcription providers use HTTPS.
• At rest:
  • BigQuery service-account keys are encrypted in the database with AES-256-GCM using the platform's APP_ENCRYPTION_KEY.
  • Other data (messages, parsed documents, source rows, transcripts) relies on Google Cloud's managed encryption at the Cloud SQL / GCS layer (KMS-backed). There is no application-layer field encryption on these.
  • API key tokens are stored as sha256 hashes only; the platform never has access to the plaintext token after the one-time reveal on creation.
  • Session tokens are opaque 384-bit random values; the cookie value is the database row ID.
• gap — the application does not enforce TLS via HSTS headers or sslmode=require on the DB connection. TLS termination is the operator's responsibility (configure at the load balancer).

Data deletion

• Sources — deleting a source removes its DB rows and GCS objects.
• Projects — deleting a project cascade-removes sources, decisions, reasoning runs, trackers, reports. needs verification: confirm GCS objects for the project's sources are fully cleaned by the cascade.
• Sessions — sign out removes the session from the database; the cookie can't be re-used.
• User memory — you can "forget" individual remembered facts from your profile page (soft-delete).
• gap — no "delete my account" self-service. Users wanting full account deletion should email your admin or the operator. This will be addressed in a future release.

Authentication

• Google OAuth only. The platform does not support username/password sign-in. There is no MFA configuration UI yet (MFA at the Google account level applies).
• Sessions last 30 days unless explicitly signed out.
• API keys can be created from Settings → API keys. They carry the user's full permissions (scopes are stored but not enforced — gap, to be fixed before production rollout).

Third-party processors — quick list

For your security review, here are the third-party services that may receive your data when you use Tattva:

⚠️ Stub-auth gotcha — dev/test only

Status: gap — confirm stub accounts do not exist in production.

The platform supports a non-SSO stub login path at POST /api/auth/login for users whose auth_provider='stub'. It was added so RBAC test scenarios can run without multiple Google identities.

The route looks up the user by email only and issues a session — it never verifies the password. The submitted password is read off the request body, ignored, and a session row is created if the email matches a stub user.

What this means:

• For any stub account, any password value will authenticate.
• If a stub account were provisioned in production, anyone knowing that email could log in.
• Dev/QA environments seed stub accounts like owner-test@example.com, admin-test@example.com, etc. These are intentional for local testing.

What to confirm before going to production:

1. Run SELECT count(*) FROM users WHERE auth_provider='stub' on the production database. Expect zero.
2. If non-zero, either delete those rows or change the auth_provider column.
3. Consider gating the /api/auth/login route behind NODE_ENV !== 'production' or a STUB_AUTH_ENABLED env flag.

The Google OAuth path (/api/auth/google) verifies a real OAuth token from Google and is the only intended production sign-in.

What to share with security review

If you're being asked to do a security review:

1. Read this page in full. Flag the gap and needs verification items.
2. Sample the data your team will actually load. Is there PII? If so, the agent-query PII gap above is the call to make.
3. Confirm with your admin which providers are actually enabled for your deployment.
4. Check Settings → Integrations to see which provider keys are active.
5. Pull a sample of the audit log to confirm coverage matches your audit needs.

Related

• Audit log
• Integrations
• Sources — what trust levels mean