Sacred Logic™

Security & Vulnerability Disclosure

Last updated 24 July 2026

How we protect your data (summary)

We take a practical, defence-in-depth approach appropriate to a pre-launch platform:Authentication.Sign-in is handled by Clerk, a specialist identity provider; we don't store your password.Authorisation.Access to privileged data and admin functions is enforced on the server against a cryptographically-verified identity — never a value supplied by the browser. Admin routes are gated in middleware and again server-side.Payments. Card data is handled directly by Stripe and never reaches or is stored on our systems. Payment webhooks are verified against the raw request signature.In transit. Traffic is served over encrypted connections (TLS/HTTPS).Least privilege & audit. Administrative access is limited on a need-to-know basis, and every administrative action is written to an append-only audit log.Data minimisation. We collect only what we need and retain it only as long as needed (see the Privacy Policy).Providers.We rely on established providers — Clerk, Convex, Stripe, and Vercel — which operate their own security programmes.Honest note: Sacred Logic™ is a pre-launch MVP. We do not yet hold a formal security certification (such as ISO/IEC 27001 or SOC 2), and we don't claim one. No system is perfectly secure, but we work to protect your data and to respond quickly to issues.

Reporting a vulnerability

We welcome reports from security researchers and users acting in good faith. If you believe you've found a security vulnerability, please email burren.art.gallery@gmail.com with “Security” in the subject line. Please include: what you found, the steps to reproduce it, the affected URL or feature, and its potential impact. A proof-of-concept helps us reproduce and fix it quickly.

Scope

In scope: this website and web application.Out of scope: the systems of our providers (Clerk, Convex, Stripe, Vercel) — please report those to the provider concerned; and findings that require social engineering, physical access, denial-of-service / volumetric testing, or spam. Please do not run automated scanners that degrade the service.

Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will regard it as authorised, will work with you to understand and resolve the issue promptly, and will not pursue or support legal action against you. In return, please: act in good faith; avoid privacy violations, data destruction, and service disruption; only interact with accounts you own or have explicit permission to access; stop as soon as you've confirmed a vulnerability; and never access, modify, or retain data that isn't yours.

What to expect

We aim to acknowledge your report within 5 working days, keep you reasonably informed of progress, and let you know when the issue is resolved. With your permission, we're happy to credit you once a fix is released. We don't currently run a paid bug-bounty programme, so reports are made on a voluntary basis.

Coordinated disclosure

Please give us a reasonable opportunity to investigate and fix an issue before disclosing it publicly, so that users aren't put at risk. We're grateful for reports that are shared privately first.

This page is a good-faith summary and has not yet been reviewed by a lawyer. A machine-readable version is published at /.well-known/security.txt (RFC 9116).