Small surface. Explicit boundary.

Current controls

• Public registry payloads are generated only from allowlisted public source paths.
• Paid Pro source must never enter the public repository or build output.
• Health output contains no secrets or private diagnostics.
• Type checking, dependency locking, lint, tests, and production builds are release gates.
• Production identity, database, email, monitoring and backup adapters are server-only. Checkout remains disabled until the restricted Stripe runtime key, release archive and complete customer journey pass.
• Protected-download and webhook contracts require current server authorization, signed and replay-resistant evidence, and verified provider events; their public routes return indistinguishable unavailable responses until paid launch gates pass.

Vulnerability reporting

Email support@kreydlabs.com with Security report in the subject. Do not submit sensitive vulnerability details through a public issue. Include affected URLs, impact and reproducible steps, but never include another person's data or a destructive proof.

We aim to acknowledge a valid report within two UK business days. This is a target, not an SLA or a bug-bounty promise. Do not access unnecessary data, disrupt service, use social engineering or demand payment.

Commercial infrastructure

Vercel serves the production origin; WorkOS, Convex, Resend, Better Stack and Backblaze B2 are configured behind it. Stripe products, prices and signed webhooks exist, but checkout stays disabled while its least-privilege runtime key and the protected paid release remain gated. Configuration alone is not treated as evidence of a complete customer journey.

Customer-facing safeguards

Account, billing, download, export, and deletion routes must authorize each request on the server and return conservative unavailable responses when a dependency or entitlement cannot be proven. Payment webhooks require provider signatures and replay-resistant processing; download links require a current licence and short expiry. Refund and membership changes must update access from durable records, not from a browser-visible success message.

Logs and alerts should carry request identifiers, event types, and safe operational context without recording credentials, payment details, protected source, or unnecessary customer data. Encrypted backups need tested restoration, and deployments need a rehearsed rollback path. Those controls remain launch evidence requirements, even when individual provider dashboards report healthy configuration.