Security

This page describes what is actually true of Production Engine's code and infrastructure today, not an aspirational security program. Every claim below is either verifiable in the product's source code or published in a provider's own compliance documentation, cited by name. If you need something this page doesn't answer, contact us (below) or ask for our Data Processing Agreement.

Production Engine is multi-tenant: every production company on the platform is a separate tenant, and tenant isolation is enforced in three independent layers rather than relied on as a convention:

• Request context: every authenticated request runs inside a tenant scope carried by Node's AsyncLocalStorage, entered once at the authentication seam and available to every function the request touches, without it being passed explicitly through each call.
• Database access: every database query runs through a Prisma client extension that stamps or filters the tenant id automatically. A query against a tenant-scoped model with no tenant in context throws rather than running unscoped, and a model that isn't registered with the isolation layer also throws rather than being silently allowed through.
• Static analysis in CI: a build-time check scans every route and library file and fails the build if it finds a documented way around the scoping layer, including a unique-key lookup that would bypass automatic tenant filtering, an unscoped database call outside its narrow allowlist, a tenant id column that could be null, a uniqueness constraint that isn't scoped per tenant, or a foreign key written from client input with no tenant check above it.

In short: tenant isolation fails closed. A bug that forgets to scope a query throws an error rather than returning another tenant's data, and a class of bypass that the code doesn't already account for is caught in CI before it reaches production.

• Passwords are hashed with scrypt (Node's built-in implementation), a per-user random salt, and a timing-safe comparison on verification. No third-party identity provider holds account credentials; hashing and session issuance happen in Production Engine's own code.
• Sessions are an HMAC-SHA256-signed token stored in an HttpOnly cookie: not readable by JavaScript in the browser, sent only over HTTPS in production, and scoped SameSite=Lax. A session carries an epoch value tied to the account, so changing your password invalidates every other session immediately rather than waiting for expiry.
• Public endpoints that are common abuse targets are rate-limited against a shared store, so the limit holds across every server instance: password reset, setting a password from an invitation, access requests, document signing, and file upload.
• Sign-in is throttled per email and per IP, but that particular counter lives in each server instance's memory rather than the shared store, so an attacker spread across instances gets more attempts than the number suggests. Moving it to the shared store is tracked work, not a shipped guarantee, and we would rather say so here than let you assume otherwise.

The AI estimator sends the brief you type, and, inside a signed-in workspace, your tenant's own rate configuration, to a language-model provider through the Vercel AI Gateway. See Privacy Policy for what that means and how to avoid putting something in a brief you don't want a model provider to process.

Card data never reaches Production Engine's servers. Checkout is handled entirely by Stripe's hosted flow: Stripe is a PCI DSS Level 1 service provider, the highest level of PCI certification, and because Production Engine never sees or stores card numbers, our own PCI compliance scope is the shortest self-assessment category (SAQ A).

Production Engine runs on established providers rather than self-hosted infrastructure. What each one states publicly about encryption, backups, and certifications, as of the date above:

• Vercel (application hosting, edge functions, file storage): SOC 2 Type 2 attestation for security, confidentiality, and availability; ISO 27001:2022 certified. States it encrypts data at rest with AES-256 and data in transit with HTTPS/TLS 1.3.
• Neon (Postgres database): SOC 2 Type 1 and Type 2, ISO 27001, and ISO 27701 certified. States it encrypts data at rest with AES-256 in a hardware security module and supports TLS's strictest verify-full mode for connections, and offers point-in-time restore (the exact retention window depends on plan tier).
• Resend (transactional email): SOC 2 Type II compliant and GDPR compliant. States it encrypts data at rest, with row-level encryption on sensitive tables, uses TLS 1.3 or higher in transit, and keeps point-in-time backups for 30 days.
• Stripe (payments): PCI DSS Service Provider Level 1, described under Payments above.

These are the providers' own public statements, cited so you can verify them directly rather than take our summary on faith: Vercel's security and compliance page, Neon's compliance page, and Resend's security page.

Production Engine does not currently hold its own SOC 2 or ISO 27001 certification: the statements above are about our infrastructure providers, not an independent audit of Production Engine itself. We also don't run a public bug bounty program at this time. If you find a security issue, email us (below) directly rather than filing it publicly.

Email security@production-engine.com. We will acknowledge a good-faith report and work with you on disclosure timing.