Back to Blog

How to Prepare Staging Data Before Connecting AI

Staging first only helps if staging isn't a full copy of production PII. What to scrub, how to subset, and when a fake seed is better than a prod dump before Claude or Cursor connects.

“Use staging” is incomplete if staging is last night’s prod dump with every email and API key still in it.

AI makes that riskier: broad questions, rows in chat context. Staging-first only helps when staging is safe enough to explore.

Prep checklist — with staging first, table allowlists, explore unfamiliar databases:

What “safe enough” means

For AI exploration you want:

  • Real shape (tables, types, rough distributions)
  • Fake or hashed identity where you can
  • No production tokens, raw card data, or private message bodies
  • Small enough that a curious SELECT COUNT doesn’t hurt

Perfect anonymization is a project. A scrubbed subset ships this week.

Prefer these patterns

1. App seeds
rails db:seed / SQL seeds with obvious fake users (alice@example.com). Best for learning schema and demos.

2. Subset + scrub
Copy N days of data or one tenant, then overwrite PII columns.

3. Branch from prod, then scrub
Neon/Supabase branch for shape, run scrub scripts before any MCP URL exists.

4. Views for AI
Staging can keep messy tables while the AI user only sees views without email/phone (allowlists).

What to scrub or drop

| Category | Examples | Action | |----------|----------|--------| | Identity | email, phone, name, address | Fake or hash | | Secrets | API keys, session tokens, password hashes | Remove tables or columns from AI role | | Messages | support bodies, private notes | Drop or replace with lorem | | Payments | PAN, bank accounts | Never on AI staging | | Auth internals | reset tokens | Drop |

Keep org_id, statuses, amounts, timestamps — that’s what makes answers useful.

Minimal scrub examples (Postgres)

Fake emails:

UPDATE users
SET email = 'user_' || id || '@example.com'
WHERE email IS NOT NULL;

Null out tokens:

UPDATE api_keys SET key_hash = 'redacted', prefix = 'redacted';

Or revoke access instead of updating:

REVOKE ALL ON api_keys FROM synra_readonly;
-- and keep api_keys off the Synra allowlist

Run scrub before you create the Synra connection, or rotate credentials after.

Size the subset

  • One workspace / org for multi-tenant apps (org_id guide)
  • Last 30–90 days of events if events are huge
  • Full dimension tables (plans, products) — they’re small and useful

Empty staging makes migration checks and index review weak — you want some messy realism, not production volume.

Checklist before you paste the URI into Synra

  • [ ] Staging (or branch) is not the production primary
  • [ ] Emails/phones faked or views hide them
  • [ ] Token/secret tables revoked or allowlisted out
  • [ ] SELECT-only user for AI
  • [ ] Connection named staging-scrubbed (honest)
  • [ ] One known-answer count still works after scrub

When prod-shaped data is required

Use a read replica with a tight allowlist and trained users — not an unsanitized staging dump you treat casually because the hostname says staging.

“Staging” isn’t enough by itself. Scrub first, then connect.

mcpserver.design (7-day Solo trial) when the data’s ready.

Related reading:

← Back to Blog