You’re handing us your Stripe keys and your database. Here’s exactly what we do with them.

ParityRail connects to two systems per project, and the access it requests is deliberately minimal:

• Stripe — read only. You provide a restricted Stripe key with read scopes. Our connector makes no write calls to Stripe, ever. We read customers, subscriptions, prices, and entitlements to compute what access each payment promised.
• Your app database — read only by default. You connect a Postgres role granted only SELECT. On top of that, every read connection sets default_transaction_read_only = on — a database-level lock, not just a permission we ask you to trust.
• Narrow repair grants — opt-in. If you enable repairs, you provide a separate role that may write only to the specific plan, premium, trial, and entitlement columns your mappings name. Repairs are single-row, parameterized, and approved by a human by default.

We do not ask for, and have no use for, your application source code, your customers’ passwords, or any table outside the mappings you configure.

Your secrets — Stripe API keys, database connection strings, webhook signing secrets — are sealed with AES-256-GCM using a server-side key before they ever touch storage. Sealed values are versioned, and the plaintext never returns to the browser. The dashboard only shows non-secret identifiers, like a database host and name.

All traffic — between you and ParityRail, and between ParityRail and your systems — is encrypted in transit with TLS.

ParityRail is multi-tenant: one system serving every customer’s workspace. Keeping workspaces apart is enforced as a hard rule.

• 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 is indistinguishable from a request for one that doesn’t exist — we never confirm or deny what we can’t show you.
• API keys are hashed with SHA-256 (the plaintext is shown once, at creation), scoped to your organization or a single project, and carry an explicit capability — read for read-only API and MCP access, or repair for approving and executing mutating actions.

Every state-changing operation — a repair executed, an incident ignored, a verification result — is written to an audit log with the actor, the target, and the before/after state. Each entry is chained to the previous one with a hash.

The append-only guarantee is enforced by the database itself: triggers reject any attempt to UPDATE or DELETE an audit row. Not even ParityRail can rewrite history. Your per-customer Access Ledger is built directly from this record, so the story behind any promise is traceable and audit-ready.

ParityRail relies on a short list of infrastructure subprocessors. We keep it small on purpose.

The current list also lives in our data processing addendum. We’ll post material changes there before they take effect.

• State snapshots captured during reconciliation are retained on a rolling 90-day window and pruned automatically after that.
• Incidents and audit records are retained for the life of your workspace so your Access Ledger stays complete and audit-ready.
• Deletion. Deleting a project removes its configuration and connected credentials. On request, we will delete a workspace and its associated data; write to security@parityrail.com.
• Export.Your data is yours. Incidents and audit history are available through the API, and we’ll help with a full export on request.

If you believe you’ve found a vulnerability, or you suspect a security incident involving ParityRail, email security@parityrail.com. We aim to acknowledge reports within two business days and will keep you updated as we investigate.

Our machine-readable contact details follow the security.txt standard. Please give us a reasonable window to remediate before any public disclosure — we’ll work with you in good faith.

ParityRail is not SOC 2 certified today, and we won’t claim otherwise. We’d rather tell you exactly where we stand than imply a badge we haven’t earned.

What’s already true today:

• Read-only access to your systems, enforced at the database and at Stripe.
• Credentials encrypted at rest with AES-256-GCM; TLS in transit.
• Strict tenant isolation on every request path.
• A tamper-evident, append-only audit log enforced by the database.
• Role-based access and hashed, capability-scoped API keys.

Where we’re headed:

• Formalizing our controls and pursuing SOC 2 Type II as we grow. We’ll update this page as milestones land.
• A signed DPA is available now — see /legal/dpa.

Have a security questionnaire or need something in writing? Reach out to security@parityrail.com — we answer these directly.