Skip to main content

Data privacy & security

DataChord is built so that the sensitive data flowing through your mappings — customer records, financial fields, health identifiers — stays isolated, protected, and accountable at every step. This page explains, in plain terms, the controls that keep your data safe and how they map to what your security team will ask about during review.

These controls are designed against the SOC 2 Type II Trust Services Criteria (Security and Confidentiality).

Your data is isolated from every other customer​

DataChord is multi-tenant, but no tenant can ever see another tenant's data. Isolation is enforced in two independent layers:

  • Application layer — every request carries your organization identity, and every query is scoped to it.
  • Database layer (Row-Level Security) — PostgreSQL itself enforces that a query can only ever return rows belonging to your organization, using native Row-Level Security policies on every table that holds your data. Even if an application-level check were ever missed, the database refuses to return another tenant's row.

This "belt-and-suspenders" design means a single bug cannot cause a cross-tenant data leak. Your session identity is also re-validated on every request against your active memberships, so a stale or revoked credential cannot be used to reach an organization you no longer belong to.

Sensitive fields are detected and protected automatically​

DataChord understands which of your fields are sensitive and acts on them without you having to find them by hand.

  • Automatic PII detection. When you profile a source, DataChord scans field names and a sample of values to identify personal and sensitive data — email addresses, phone numbers, national IDs, payment card numbers, names, addresses, dates of birth, and more. Detected fields are proposed as tagged PII for your review; nothing is enforced until you confirm it.
  • Enforced masking, not just preview. Once a field is tagged and a policy applies, the protection runs on every real pipeline run and every export — not only in a preview. Your generated code and delivered data carry the same masking as the canvas shows.
  • Three protection actions:
    • Mask — replace the value (full, or partial like "show last 4").
    • Tokenize — replace the value with a consistent, reversible surrogate.
    • Redact — remove the value entirely.

Reversible tokenization vault​

When a field is tokenized, the original value is encrypted (using a KMS-backed key) and stored in a per-organization vault, while the data flowing downstream carries only a surrogate token. Because the surrogate is consistent, your joins and analytics still work — but the real value never leaves the vault. An authorized, audited request can recover the original (for example, to satisfy a data-subject request), and tokens are isolated per organization, so one tenant can never resolve another's tokens.

Untrusted code runs in isolation, never next to your secrets​

Mappings can include AI-generated and user-authored transformation logic. DataChord executes that code in an isolated sandbox that is separated from the application's secrets and your data connections:

  • The sandbox receives only the code and the records it needs — never API keys, database credentials, or other tenants' data.
  • It runs with strict CPU, memory, time, and output limits, and with outbound network access denied by default.
  • In production, execution runs in a hardened, isolated runtime (microVM-class isolation). If that isolated runtime is unavailable, runs fail closed rather than falling back to a less-isolated path.

This means transformation logic cannot reach your credentials, your infrastructure, or another customer's data.

Everything sensitive is recorded for audit​

Governance actions are written to a durable audit trail your team can review: policy changes, masking applied to a run, PII detection results, authorized detokenization, drift events, and run completion. Audit records capture what happened and to which fields — counts and field paths — and never store raw sensitive values. This gives your auditors and your own security team a queryable record of how sensitive data was handled.

Encryption and key management​

  • Connection credentials and tokenized values are encrypted at rest using a KMS-backed key.
  • Secrets are never written to logs or embedded in generated code.
  • All traffic to DataChord is encrypted in transit.

Deployment options for stricter requirements​

Most customers run on DataChord's managed cloud. For teams with data-residency or isolation requirements, DataChord's architecture supports a single-tenant / bring-your-own-cloud deployment, where the components that process your data run inside your own cloud account. Talk to us if your security review requires this — the platform was designed to keep that option open.

Quick reference for your security review​

Question your security team will askHow DataChord answers it
Can another customer ever see our data?No — application scoping and database-enforced Row-Level Security on every table.
What happens to PII?Auto-detected, reviewed, then masked / tokenized / redacted on every run and export.
Can we recover or delete a person's data?Reversible per-org tokenization vault enables authorized lookup and erasure.
Where does AI-generated code run?In an isolated sandbox with no access to secrets, the network, or other tenants.
Is there an audit trail?Yes — durable, queryable records of every governance action, with no raw values.
Is our data encrypted?Yes — at rest (KMS-backed) and in transit.
Can we run it in our own cloud?Single-tenant / BYOC is supported for stricter requirements.