security.

an honest account of how the architecture is built, hosted, encrypted, and gated. written for enterprise and AI-lab due diligence. it describes what is true today and marks what is planned as planned. nothing on this page is a certification we do not hold.

infrastructure and hosting

the consumer and business surfaces (noctaracorp.com, takethemirror.com, pupulcorp.com) run on Vercel as serverless functions in US regions. drylies.com runs on Cloudflare Pages. all four sites are served over HTTPS with TLS terminated at the platform edge; there are no plaintext HTTP origins. application logic lives in stateless serverless functions, so there are no long-lived application servers to patch or harden by hand. the database is Supabase managed Postgres, hosted in a US region.

encryption

in transit. all traffic between browsers, our functions, and our providers travels over TLS. Vercel, Cloudflare, Supabase, Stripe, Resend, and the Anthropic API each terminate TLS on their edge; we do not accept unencrypted connections.

at rest. the database is Supabase managed Postgres, which encrypts data at rest and in transit at the platform level. payment data is held by Stripe, not by us. file storage, where used, is Supabase Storage, also encrypted at rest by the provider. we rely on these managed providers for at-rest encryption rather than rolling our own.

access control and secrets

• least-privilege keys. the Supabase service-role key is used only server-side inside serverless functions and is never shipped to the browser. the browser is given a restricted publishable key with narrowly scoped access.
• secrets management. all credentials (database keys, Stripe keys, Anthropic API key, Resend key, signing secrets) are stored as platform environment variables. no secret is committed to source control.
• sessions. user sessions are carried as signed tokens, JWT or HMAC depending on the surface, so a session cannot be forged without the server-side signing secret.
• authentication methods. Sign in with Apple, email magic links, and a behavioral mark. some enterprise SSO is handled through Clerk.

application security

• input validation. request payloads to our functions are validated server-side before they touch the database or downstream providers.
• gated scheduled jobs. scheduled jobs (crons) are authorized with a Bearer CRON_SECRET that only the platform and the function share. we do not rely on a request header such as x-vercel-cron as a trust boundary, because that header can be spoofed by an external caller. a job will not run for a request that cannot present the secret.
• least-privilege keys. as above, the browser never receives a key that can read or write arbitrary rows; privileged operations only happen server-side under the service-role key.
• row-level scoping. reads and writes that return personal data are scoped to the authenticated user or organization, not exposed broadly to any caller.

data privacy and the architectural separation

this is the part that is structural, not just policy. in VEX (the coach-facing product), a coach sees the returned reading. that is the word, the rhythm, and the lever the reading surfaces. the coach does not see the client's raw written answers. client readings are consent-gated: an individual's reading is exposed to a coach only after that individual has explicitly consented. the separation is enforced in code, not by a promise to behave.

what we hold. readings, email addresses, and a behavioral timing signal. the timing signal is specified honestly, including what it cannot do, in the behavioral signal.

what we do not hold. no card numbers, no government IDs, no health records. the product makes no medical or diagnostic claims, and we do not collect the categories of data that such claims would imply.

AI processing. reading inputs are sent to the Anthropic Claude API to produce the reading. that text is processed by Anthropic under their commercial API terms, which state that data submitted through the API is not used to train their models. the text is sent for the purpose of generating the reading and is not sold or repurposed by us.

vulnerability management and monitoring

we keep dependencies current and apply updates as advisories surface; running on serverless platforms means the underlying OS and runtime are patched by the provider rather than by us. application and function errors are captured in platform logs, which is how we detect and investigate failures and anomalous behavior.

planned. planned formal third-party penetration testing has not yet been performed. we intend to engage an external firm for a penetration test as enterprise demand warrants, and we are willing to scope a customer-specific test as a closing condition for an enterprise engagement. we will not represent that a pen-test has occurred until one has.

subprocessors

the third parties that process customer or participant data on our behalf are listed, with role and region, at /subprocessors. the principal ones are below. we provide written notice before adding a new subprocessor.

payments run through Stripe, which is certified PCI-DSS Level 1. Noctara never sees or stores card numbers; card data is entered directly into Stripe's hosted fields and tokenized on their side.

SOC 2

the controls described on this page are in place today. a formal SOC 2 Type I or Type II audit has not been completed. planned we will pursue a SOC 2 audit as enterprise demand warrants. our current readiness posture is documented at /soc2-readiness.

responsible disclosure

if you believe you have found a security vulnerability, please report it to security@noctaracorp.com (or hello@noctaracorp.com if that is easier). please give us a reasonable window to investigate and remediate before any public disclosure, and do not access, modify, or exfiltrate data that is not yours while testing. we will acknowledge legitimate reports and work the fix in good faith.