Privacy Policy

DBShifts ("we", "us") operates the DBShifts data platform (the "Service") — database migration, the Data Console, and the Agent Gateway. This policy explains what we collect, how we use it, and your rights. By using DBShifts you agree to this policy.

Account: name, email, bcrypt-hashed password. If you enable two-factor authentication, an encrypted TOTP secret and hashed recovery codes.

Database connection details: hosts, ports, names, and credentials you provide — encrypted at rest, decrypted only in memory during a job or query.

Usage: job IDs, status, row counts, schema metadata, error logs, reconciliation results.

Agent & console activity: audit logs of gateway queries (table, columns, row counts, masked columns, requesting IP) and Data Console access — kept so you can answer "who saw what". Agent tokens are stored only as SHA-256 hashes.

Sign-in security: device fingerprints (IP + browser) of known sign-ins, used to alert you to new-device access.

Billing: plan + subscription status. Card data is handled by Stripe, never stored on our servers.

Technical: IP, browser, pages visited (server logs).

• Operate the Service and run the migrations, queries, and monitors you start
• Send transactional and security email (verification, reset, new-device sign-in, 2FA changes)
• Process billing and enforce plan quotas
• Detect errors, abuse, and security incidents (rate limits, anomaly alerts)
• Comply with legal obligations

Password breach screening: when you set a password we check it against known breaches using k-anonymity — only the first 5 characters of a SHA-1 hash ever leave our servers; your password never does.

We never train ML models on your data or sell it to advertisers. (DBShifts contains no AI/LLM components; the Agent Gateway governs your agents' access — we run none of our own.)

DBShifts is a data processor acting on your instructions. Credentials are encrypted at rest. Row data moves between your source and target via our worker nodes and is not persistently stored after a job completes. Migration logs retain counts and timestamps, not full row payloads. Rows a target rejects may be quarantined for your review until you retry or discard them. You are responsible for your right to migrate the data involved.

Both products read your connected databases on demand — query results are returned to you (or your agent) and are not persistently stored by us, with two exceptions: audit logs (metadata about each access: table, columns, row counts, masked columns, IP — not full row payloads, except write-action undo snapshots you explicitly approve) and masked test-data copies you generate into a target you control.

PII masking, column rules, row limits, usage budgets, and token IP restrictions are applied server-side according to your policy configuration. Detection of sensitive columns is automated and best-effort — review the scan results; you remain the controller of what your policies expose. Owner "replay" of an agent query re-runs it under the same masking rules and is itself audited.

If you enable Slack approvals, write-action proposals (action name, parameters, requesting agent) are sent to the Slack webhook you configure — governed by Slack's own terms.

Strictly necessary (always on, no consent required): dbshift_token/dbshift_refresh (httpOnly auth session) and dbshift_csrf (CSRF protection).

Analytics (optional, off until you accept): a first-party dbshift_session_id stored in your browser to count unique visitors and a first-touch campaign tag (UTM / referrer) used only to understand how people find and use the site. First-party only — no advertising or third-party tracking cookies, and no analytics fire until you choose “Accept all”.

Security (set only when you use the feature): dbshift_mfa (5-minute two-factor challenge ticket during sign-in) and dbshift_td (30-day "trust this device" marker you opt into). Both httpOnly.

Local storage (not cookies, never sent to us): dbshift_logged_in (UI signed-in hint) and dbshift_product (which product you chose at sign-in).

Your choice is saved in dbshift_cookie_consent. You can change or withdraw it any time via the “Cookie settings” link in the footer; choosing “Essential only” immediately clears any analytics identifiers.

• TLS 1.2+ in transit; credentials encrypted at rest with rotatable keys
• bcrypt password hashing + breach screening on new passwords
• Optional TOTP two-factor authentication with hashed recovery codes
• httpOnly JWT cookies + CSRF double-submit tokens
• Agent tokens: hashed at rest, scopable, revocable, optionally IP-bound
• Rate limiting, usage budgets, and anomaly detection

Report vulnerabilities to security@dbshift.io.

• Account deletion: scheduled with a short grace period (sign in again to cancel), then all owned data — projects, credentials, data sources, gateways, agent tokens, test-data sets — is permanently purged
• Database credentials: deleted with the resource or the account, whichever comes first
• Migration logs: deleted within 90 days
• Gateway audit logs: 90 days
• Webhook delivery records: 30 days
• Reconciliation monitor history: 90 days
• Billing records: retained 7 years (financial regulation)

Access, correction, deletion, portability, and objection. Email privacy@dbshift.io; we respond within 30 days. We do not sell personal data.

• Amazon Web Services — API hosting + workers (EC2)
• Vercel — frontend hosting (global CDN)
• MongoDB Atlas — primary database (AWS)
• Stripe — payments (US/EU)
• Slack — only if you enable Slack approvals, and only the proposal metadata you route there
• Have I Been Pwned — anonymized password-breach screening (5-character hash prefix only)

Material changes are announced via email or in-app notice at least 14 days before taking effect.