Twellie policy

Security

Plain-English terms for using Twellie's buyer-side property reports, valuation logic, privacy controls, and support policies.

Last Updated: July 10, 2026

This page describes controls that are implemented in the current Twellie code and production configuration, plus work that remains before a paid public launch. It supplements, but does not replace, our Privacy Policy and Data Processing Addendum. It is not a certification or third-party audit report.

1. Current Architecture

Web and API hosting: the static web application is configured for Vercel and the Python API for Fly.io.
Identity and data: Supabase provides authentication and Postgres storage.
Payments: Stripe-hosted Checkout and Billing Portal handle payment-card entry; Twellie does not receive raw card numbers.
Property data: the production adapter is configured for the RentCast API and does not automatically fall back to a legacy collection source. Paid checkout remains disabled unless the RentCast credential is available, a written commercial-rights review is recorded, and the prospective valuation benchmark gate passes.
Monitoring and email: the application supports Sentry and transactional email when their production credentials are configured. Configuration support is not a claim that alert routing or delivery has been independently tested.

Current and conditional providers, purposes, and attestation status are listed individually on the Sub-Processors page. We do not claim that every provider has the same certification.

2. Implemented Application Controls

Supabase access tokens are verified with the project's asymmetric ES256/JWKS signing keys, including issuer, audience, expiry, and signature checks.
Browser access and refresh tokens are held in HttpOnly, Secure, same-site cookies in production rather than browser local storage.
Unsafe cookie-authenticated requests enforce an exact same-origin check; explicit Bearer clients remain supported.
Password, signup, recovery, session, refresh, password-update, and OAuth-exchange routes have per-client-IP process-local limits. Supabase IP forwarding is enabled with a dedicated server-only secret key. The current limiter assumes the documented single-process deployment and must move to an atomic shared store before horizontal scaling.
HomeAI tables use Postgres Row-Level Security and explicit grants. Raw report calculation records are service-only; owner-facing report routes scope by user ID and apply the report's decision/redaction gate.
Stripe webhooks require signature verification, use stored event IDs for idempotency, and fail with a retriable server error when durable fulfillment fails.
Pydantic validates API input. Report templates use Jinja auto-escaping.
The browser security policy restricts script, connection, framing, and other resource origins. HSTS, frame denial, MIME sniffing protection, referrer policy, and permissions policy are set by the application.
Address-bearing report, workspace, pricing, and progress flows use same-origin assets and keep property addresses out of navigation and analytics URLs.
Sentry's application hook, when enabled, removes request bodies, cookies, query strings, breadcrumb messages, free-form exception messages, and known credential fields before transmission. send_default_pii is disabled.
User-supplied outbound URLs used by protected fetch paths are checked against an SSRF guard that blocks loopback, private, link-local, and metadata-service destinations.

3. Data Access Model

The API uses a server credential for durable writes and selected reads, which bypasses RLS by design. Those routes must therefore enforce user ownership in the application and query. RLS is an additional boundary for client-accessible tables; it is not represented as restricting the server credential.

The browser never receives the Supabase service key or the dedicated Auth secret key. Production secrets are supplied through hosting-provider secret configuration and are excluded from source control. Operators remain responsible for access review, rotation, MFA on provider accounts, and immediate revocation when access is no longer needed.

4. Secure Development Evidence

The repository includes automated tests for authentication, cookie and CSRF boundaries, rate limits, report gating/redaction, Stripe fulfillment, RLS migration contracts, address privacy, SSRF, and output sanitization.
The production-readiness checker fails closed when required secrets, data rights, or benchmark evidence are absent.
Dependency and lint checks are part of the release procedure.
No independent penetration test, SOC 2 examination, or ISO 27001 certification has been completed for EnglishAidol LLC or Twellie as of this date.

5. Operational Controls Requiring Launch Verification

The following are launch tasks or provider-dependent settings, not completed-control claims on this page:

independently confirm external uptime alerts and on-call routing;
verify transactional email delivery, bounce handling, and recovery-email delivery end to end;
document and exercise incident severity, escalation, and breach-notification procedures;
confirm Supabase backup/PITR entitlement, retention, and a successful restore test;
establish and test recovery objectives instead of publishing untested RTO/RPO numbers;
complete administrative-access review, MFA verification, secret-rotation ownership, and offboarding procedures;
perform an external security review or penetration test before representing third-party assurance;
move process-local rate counters to an atomic shared backend before adding API workers or machines.

6. Incident and Vulnerability Reporting

Report suspected vulnerabilities to security@twellie.com with reproduction steps and any proof of concept. Please avoid accessing other users' data, destructive testing, denial-of-service testing, or public disclosure before we have had a reasonable opportunity to investigate.

We will assess legally required breach notifications under the law applicable to the incident. We do not publish an untested universal response-time, on-call, or tabletop-exercise commitment.

7. Compliance Status

Twellie is not currently SOC 2 or ISO 27001 certified. Stripe handles payment-card processing on its hosted surfaces; this does not make all Twellie systems PCI certified. Provider certifications belong to those providers and are described on the Sub-Processors page.

8. Contact

Security: security@twellie.com
Privacy: privacy@twellie.com
General support: help@twellie.com