Security

Credentials are encrypted

Your credentials — Stripe API keys, database connection strings, webhook signing secrets — are encrypted before they touch storage, and never shown back to you. The dashboard only ever displays non-secret identifiers, like a database host and name.

The mechanism: each credential is sealed with AES-256-GCM using a server-side key from CREDENTIALS_ENCRYPTION_KEY. Sealed values are versioned, and the plaintext never reaches the browser.

Read-only by default

ParityRail can read your data but never write to it — and that’s enforced twice over, not just promised.

• Database. You connect a Postgres role granted only SELECT, and ParityRail additionally sets default_transaction_read_only = on on every read connection — a database-level lock, not just a permission you have to trust.
• Stripe.The restricted key holds read scopes only, and ParityRail’s connector makes no write calls to Stripe at all.

Repair safety

Repairs are the only path that can write to your database, and they’re constrained at every layer:

• Single row. A repair updates exactly one row, with values passed as query parameters — never string-interpolated.
• Validated identifiers. Table and column names are validated against a strict pattern and double-quoted before use.
• Column allowlist. Writes are restricted to a column allowlist derived only from your own mappings (plan, premium, trial, entitlement columns) — nothing else can be touched.
• Approval by default. Repairs are created pending and only run when you approve them. Grace states like past_due and incomplete never produce a revocation.
• Before/after diff.Each execution captures the row’s before and after state, and revalidates the live values against the expected “before” inside the transaction — so a stale suggestion can’t overwrite data that already changed. Concurrent approvals are guarded so exactly one wins.
• Post-repair verification. After a repair runs, ParityRail re-checks the customer and only reports the promise fulfilled once that follow-up check confirms it.

Everything is audited

Every change ParityRail makes is written to a record you can’t edit or delete.

• A repair executed, an incident ignored, a verification result — each is logged with the actor, the target, and the before/after state.
• Your per-customer Access Ledger is built directly from this record, so the history behind any promise is traceable and audit-ready.

Strict tenant isolation

ParityRail is multi-tenant — one system serving every customer’s workspace — so keeping workspaces apart is enforced as a hard rule, not assumed.

• Every project-scoped page, server action, and API route passes a tenancy check before it does anything.
• A request for a project you can’t reach looks identical to a request for one that doesn’t exist — ParityRail never confirms or denies what it can’t show you.
• API keys are hashed. Keys are stored only as SHA-256 hashes (the plaintext is shown once, at creation) and can be revoked at any time.
• Scoped access.A key is scoped to your organization, or narrowed to a single project, and can’t reach anything outside that scope.
• Role-based actions. Sensitive actions, like approving repairs or managing integrations, require an elevated organization role.

For how these guarantees show up in the connection steps, see Connect Stripe and Connect your database.

For your security team

Evaluating ParityRail for a team that holds production access? Our trust & security page gathers the guarantees above alongside our subprocessor list, data retention, incident-response contact, and an honest read on our SOC 2 posture. A plain-language data processing addendum is available now, and security contact details follow the security.txt standard.