security

Last updated: February 2026

Latent Patterns is a small, deliberately simple service. We minimise our attack surface by minimising what we collect and what we run. This page describes how we protect your data and what you can expect from us.

1. infrastructure

Latent Patterns runs on Cloudflare Pages using the Workers runtime (V8 isolates) deployed across Cloudflare's global edge network. There is no single origin server — requests are handled at the nearest Cloudflare data centre.

• All connections are served over HTTPS with TLS 1.2+. HTTP requests are automatically redirected to HTTPS by the Cloudflare edge.
• Static assets are served directly from Cloudflare's CDN.
• The application runs in V8 isolates — lightweight, sandboxed execution environments with no shared memory between requests.
• The admin interface is protected by Cloudflare Zero Trust (device posture via WARP) and WebAuthn passkey authentication (FIDO2).

2. data storage

User data is stored in PlanetScale PostgreSQL, accessed via Cloudflare Hyperdrive connection pooling. The database is not directly exposed to the internet — it is accessible only through Hyperdrive bindings in the Workers runtime.

• The database stores email addresses, session identifiers, subscription state, lesson progress, support tickets, survey responses, live interaction data, and — when available via profile enrichment — job title, employer, industry, seniority, and location.
• We do not store passwords. Authentication uses single-use magic links or OAuth.
• We do not store payment card details. All payment processing is handled by Airwallex. We store only an Airwallex customer ID and subscription status.
• We do not store OAuth access tokens. OAuth tokens are used once during login to fetch your email address and are then discarded.
• Content (courses, glossary) is static and bundled at build time — not in the database.
• Downloadable courseware zip artifacts are stored in a private Cloudflare R2 bucket and served through a dedicated download worker, not directly from a public bucket URL.
• Enterprise API keys (BYOK) are encrypted at rest using AES-256-GCM and decrypted only at LLM proxy time. Keys are never logged or exposed in responses.
• Enterprise SIEM integration credentials (endpoint URL and authentication header values) are encrypted at rest using AES-256-GCM. Authentication values are decrypted only at delivery time and are never logged or exposed in responses.
• Database backups include managed point-in-time recovery and encrypted offsite snapshots. Offsite backups are encrypted before leaving the application environment and cannot be decrypted by the storage provider.

3. authentication

We use passwordless authentication. There are no passwords to leak, brute-force, or reuse. The primary sign-in method is LinkedIn. You can also sign in with another OAuth provider or a magic link sent to your email.

LinkedIn (primary)

• Sign-in uses LinkedIn's OpenID Connect flow with the openid profile email scope.
• We receive your name, email address, and locale from LinkedIn. We derive a country code from the locale. We do not access your connections, posts, or any other LinkedIn data.
• OAuth flows use a cryptographically random state parameter stored in an httpOnly cookie to prevent CSRF attacks.
• Access tokens are used once to fetch your profile and are then discarded — they are not stored.

other OAuth providers

• We also support sign-in via Google, Microsoft, GitHub, and Okta.
• The same security model applies: cryptographic state parameters, minimal scope (email only), and no token storage.
• GitHub accounts require a verified primary email.

magic links

• Magic link tokens are generated with 256 bits of cryptographic randomness, are single-use, and expire after 15 minutes.
• Tokens are marked as consumed immediately upon verification, preventing replay.

sessions

• Sessions are identified by a cryptographically random token stored in an httpOnly, Secure, SameSite=Lax cookie.
• Sessions expire after 30 days.
• Session tokens cannot be read or manipulated by client-side JavaScript.
• Sessions are database-backed and validated on every request — they can be revoked server-side at any time.

admin authentication

• Admin users authenticate with WebAuthn passkeys (FIDO2 standard). Private keys never leave the authenticator device.
• Admin sessions use a separate cookie (admin_session) with SameSite=Strict, scoped to /admin, with a 4-hour expiry.
• Destructive admin actions require passkey re-authentication.
• Admin access requires both an allowlisted email address and a registered passkey.
• The admin interface is additionally protected by Cloudflare Zero Trust — requests must originate from an authenticated device running Cloudflare WARP before they reach the application layer.
• Passkey counters are validated on each authentication to detect cloned authenticators.
• Admin impersonation of user accounts is time-limited to 1 hour and fully audit-logged.

4. third-party services

We use the following third-party services:

• Cloudflare — infrastructure (Pages, Workers, Hyperdrive, R2, Workers AI). Handles TLS termination, DDoS protection, edge routing, and database connection pooling. Workers AI runs on-edge AI inference for exit ticket grading using Meta Llama models — assessment data does not leave Cloudflare's network.
• PlanetScale — PostgreSQL database hosting. All application data (accounts, sessions, subscriptions, progress, etc.) is stored in PlanetScale-hosted PostgreSQL with managed backups and point-in-time recovery.
• Airwallex — payment processing. Airwallex handles all card data. We receive subscription lifecycle events via HMAC-signed webhooks.
• Resend — transactional email delivery (magic links, notifications). The provider sees recipient email addresses and email content.
• People Data Labs — profile enrichment. On first login we look up your email to retrieve publicly available professional information (job title, employer, location). No data is sent beyond your email address.
• Daytona — sandbox container infrastructure for interactive terminal sessions. Receives sandbox configuration (Docker image, environment setup). No personal data is sent beyond the session identifier.
• Anthropic — AI model provider for in-terminal coding assistance. Receives code context and chat messages from terminal sessions. Enterprise users may supply their own API keys (BYOK) instead of the platform key.
• OpenAI — AI model provider available only when an enterprise supplies their own OpenAI API key (BYOK). Not used for platform-provided AI features.
• Honeycomb — application observability and reliability monitoring. Receives operational telemetry data (request traces, structured log events, performance metrics) including pseudonymized email addresses, IP addresses, and organization domains. Pseudonyms are deterministic HMAC-SHA256 transformations that cannot be reversed without our server-side key. Honeycomb does not receive raw email addresses, raw IP addresses, raw organization domains, user content, payment information, or authentication credentials.
• Sentry — error tracking and crash reporting. Receives error reports (stack traces, error messages, request metadata) when application errors occur. Error context includes the same pseudonymized identifiers used in Honeycomb telemetry — not raw PII. Sentry does not receive raw email addresses, raw IP addresses, user content, payment information, or authentication credentials. Used exclusively for error detection and debugging. Data is retained according to Sentry's standard retention policy.

We do not use third-party analytics, advertising networks, tracking pixels, or any service that profiles our users. We do run a first-party event and pageview measurement system for product analytics, reliability, and journey analysis.

5. rate limiting

API endpoints, authentication, support, and newsletter routes are rate-limited by IP address using a sliding window with limits appropriate to each route category. Content browsing routes are not rate-limited.

Rate-limited responses return a 429 status with a Retry-After header. Airwallex and Resend webhooks are exempt from rate limiting as they are verified by cryptographic signature.

6. data retention

• Account data is retained for as long as your account exists.
• Expired session records are periodically purged.
• Used magic link tokens are retained briefly for audit purposes and then purged.
• Rate limiting records are retained for a 1-minute sliding window and then purged.
• Application audit logs (login events, admin actions, payment events) are retained for a minimum of 30 days and then purged.
• First-party tracking datapoints are retained for up to 90 days and then removed by retention jobs.
• Support tickets in waiting_on_customer status are automatically resolved after 30 days of inactivity.
• Terminal session records are retained for operational monitoring and cost attribution. Session content (terminal I/O) is not persisted after the session ends.
• Live interaction session data (polls, Q&A, quizzes) is retained for the lifetime of the session and available for export by the session creator.
• Enterprise BYOK API keys can be revoked at any time; revoked keys are retained (encrypted) for audit purposes.
• Enterprise SIEM forwarding delivers audit events in real-time to customer-configured endpoints. Events are forwarded only to the enterprise that owns them — strict tenant isolation is enforced at the application layer. Delivery status metadata (last success/error) is retained on the SIEM configuration record. No audit data is buffered or queued for SIEM delivery; if delivery fails, the event remains in our internal audit log only.
• If you delete your account, all associated data — sessions, progress, subscription records, support tickets, survey responses — is permanently removed.

7. application security

• CSRF protection — SvelteKit provides built-in CSRF tokens for form actions. Session cookies use SameSite=Lax (Strict for admin). OAuth flows use cryptographic state parameters.
• SQL injection — all database queries use parameterized statements via Drizzle ORM. No raw SQL is exposed to application code.
• XSS protection — SvelteKit escapes all template output by default. No @html directives are used with user-controlled content. Session cookies are httpOnly. Content is processed at build time, not runtime.
• Webhook verification — Airwallex and Resend webhooks are verified with cryptographic signature validation on the raw request body before any processing occurs.
• Input validation — all form inputs and API parameters are validated server-side with type checking, length limits, and allowlist constraints.
• Courseware download protection — downloads require an authenticated, active subscriber session and are issued as short-lived one-time tokens. Tokens are redeemed atomically, preventing replay and hotlink reuse.
• Rate limiting — edge-cached, per-IP rate limiting on API endpoints, authentication, support, and newsletter routes with category-specific thresholds.
• Audit logging — all authentication events, admin actions, impersonation, and payment events are logged with timestamps, actor information, IP addresses, and user agents.
• Tracking metadata controls — event metadata uses an allowlist with size caps and PII rejection checks before persistence.
• Open redirect prevention — return-to URLs are validated to only allow same-origin relative paths.
• Terminal sandboxing — interactive terminal sessions run inside isolated Daytona sandbox containers with configurable resource limits. LLM usage is budget-capped per terminal embed per subscriber per day.
• Enterprise BYOK encryption — enterprise API keys are encrypted at rest using AES-256-GCM and decrypted only at LLM proxy time within the terminal worker. Keys are never logged or exposed in responses.
• SCIM provisioning — enterprise team provisioning endpoints use bearer token authentication with tenant-scoped, provider-specific routing. Tokens are hashed before storage.
• Enterprise SIEM isolation — enterprise SIEM event forwarding enforces strict tenant boundaries. Each audit event is tagged with its enterprise plan ID at creation time. The SIEM delivery engine verifies plan ID ownership before every delivery. Events from one enterprise can never reach another enterprise's SIEM endpoint. SIEM authentication credentials are encrypted at rest and excluded from all logs.

8. what we don't do

• We do not store passwords.
• We do not store payment card numbers.
• We do not store OAuth access tokens. We do not access your LinkedIn connections, posts, or profile data beyond your name, email, and locale.
• We do not run third-party JavaScript (analytics, ads, social widgets).
• We do not use third-party tracking cookies.
• We do not sell or share user data with anyone beyond the services listed above.
• We do not have a public-facing API beyond what the application itself uses.

9. cookies

We use a small number of first-party cookies. No third-party cookies.

• session — user authentication. httpOnly, Secure, SameSite=Lax, path=/. 30-day expiry.
• admin_session — admin authentication. httpOnly, Secure, SameSite=Strict, path=/admin. 4-hour expiry.
• lp_anon — first-party anonymous tracking id (httpOnly, Secure, SameSite=Lax, path=/, 1-year expiry, rotated every 90 days).
• lp_journey — first-party journey state cookie (httpOnly, Secure, SameSite=Lax, path=/, 1-year expiry).
• return_to — preserves your destination during login. httpOnly, Secure, SameSite=Lax. 10-minute expiry. Deleted after use.
• customerId_provider_oauth_state — CSRF protection during OAuth sign-in. httpOnly, Secure, SameSite=Lax. 10-minute expiry. Deleted after use.
• sitewide_notification_dismissed_key — remembers the last sitewide notification message you dismissed so it stays hidden until a new message is published. httpOnly, Secure, SameSite=Lax, path=/. 365-day expiry.
• utm — stores UTM campaign parameters from your first visit for attribution. httpOnly, Secure, SameSite=Lax, path=/. 30-day expiry.
• ref — stores the external URL you arrived from. httpOnly, Secure, SameSite=Lax, path=/. 30-day expiry.
• survey_anon_* — identifies anonymous survey respondents to prevent duplicate submissions. httpOnly, Secure, SameSite=Lax. 30-day expiry.
• live_anon_<sessionId> — identifies anonymous live interaction participants within a session. httpOnly, Secure, SameSite=Lax. Session-scoped.

We do not currently honor browser Do Not Track (DNT) or Global Privacy Control (GPC) signals.

10. observability and telemetry

We use Honeycomb for application observability and Sentry for error tracking — monitoring service health, request latency, error rates, and reliability via Service Level Objectives (SLOs).

• Operational telemetry (request traces, structured log events, performance metrics) is transmitted via OpenTelemetry (OTLP) over HTTPS to Honeycomb's ingestion endpoints.
• Error reports (stack traces, error messages, request context) are transmitted to Sentry when application errors occur. Non-error log events are recorded as Sentry breadcrumbs for debugging context.
• Telemetry includes: request method, URL path, route pattern, response status code, operation duration, operation success/failure, rate limit category, service identifiers, and pseudonymized user identifiers.
• Telemetry does not include: raw email addresses, session tokens, API keys, passwords, request/response bodies, cookie values, raw IP addresses, raw organization domains, user agent strings, or any user-generated content.
• Email addresses, IP addresses, and organization domains are pseudonymized using HMAC-SHA256 with a server-side secret key. The pseudonym (e.g., pii_a3f7c2e1b9d4f8a0) is deterministic — the same value always produces the same pseudonym — allowing event correlation for debugging without exposing raw PII. The pseudonym cannot be reversed without access to the server-side key. The application code physically cannot serialize raw PII into telemetry without an explicit unwrap call — the type system enforces this at compile time via opaque Pii<T> wrapper types.
• Telemetry data is retained according to each provider's standard retention policy (Honeycomb and Sentry).

11. reporting a vulnerability

If you discover a security vulnerability, please report it responsibly. Do not open a public issue.

• Email security@latentpatterns.com with a description of the issue and steps to reproduce.
• We will acknowledge your report within 48 hours.
• We ask for a 90-day disclosure window to investigate and remediate before public disclosure.

We publicly acknowledge researchers who help improve our security on our security hall of fame. Qualifying researchers receive one year of free access to the platform.

Our security.txt is available at the standard well-known URI.

safe harbor

When conducting vulnerability research according to this policy, we consider this research to be:

• Authorized under any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
• Authorized under any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
• Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
• Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.

12. contact

For security questions or concerns: security@latentpatterns.com