Twellie — Security Overview

Last Updated: April 19, 2026

This page describes the technical, organisational, and operational controls Twellie uses to protect your data. It supplements — and does not replace — the binding commitments in our Privacy Policy and Data Processing Addendum.

1. Infrastructure

Primary cloud: Supabase (backed by AWS) for database, authentication, storage, and realtime.
Edge: Cloudflare (when enabled) for DNS, CDN, TLS termination, and DDoS protection.
AI inference: Google Gemini and Anthropic Claude via their business APIs (contractual no-train commitments).
Email: Resend for transactional + marketing (separate suppression lists).
Payments: Stripe — we never touch raw card data.
Error monitoring: Sentry with client-side PII scrubbing.

All primary sub-processors hold SOC 2 Type II or equivalent third-party attestation.

2. Encryption

Scope	Encryption
Data in transit (web, mobile, API)	TLS 1.2+; HSTS one-year, preload-eligible
Data at rest (databases, file storage)	AES-256 (via Supabase/AWS KMS)
Backups	AES-256
Secrets (API keys, tokens)	Managed via provider vaults; not stored in code
Passwords	bcrypt (managed by Supabase Auth)

3. Access Control

Multi-factor authentication required for all administrative access.
Least-privilege access — engineers are granted only what they need for their work.
Role-based access control on production data with quarterly access reviews.
Immediate revocation on offboarding.
Secrets management: all production credentials are stored in encrypted vaults, rotated at minimum annually, and never placed in source control.
Pre-commit secret detection (gitleaks) catches accidental commits before they leave the developer's machine.

4. Application Security

Server-side authentication via Supabase-issued JWTs, verified locally using HMAC.
Row-Level Security (RLS) in Postgres restricts every query to the authenticated user's rows.
Every user-data endpoint requires auth and enforces ownership at the database layer; 404 returned on cross-user access to prevent ID enumeration.
Rate limiting (per-user + per-IP) on all analysis endpoints.
Input validation via Pydantic schemas; never direct string interpolation into database queries (we use PostgREST with value quoting).
Output sanitization in Jinja templates (autoescape on, | tojson in <script> contexts).
Content Security Policy restricts what the browser will load and execute.
HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy enforced on every response.

5. Secure Development

Code review required for all changes to production code (minimum one non-author reviewer for user-data paths).
Automated vulnerability scanning on every deployment.
Static analysis (type checks, linter) required to pass CI.
Dependency scanning with a seven-day patch SLA for critical CVEs.
Pre-commit hooks (gitleaks + ruff) block secrets + enforce style locally.
Test suite: over 230 tests covering auth guards, SSRF allowlist, XSS prevention, rate limiter counting, JWT verification, sanitiser patterns, and cross-user 404s.

6. AI Safety

No training on user data. Our contracted AI providers commit that business-API inputs are not used to train their foundation models; we store no prompts or outputs beyond the report itself, which is scoped to the user.
Prompt hardening. User-supplied fields are wrapped in <<<BEGIN_DATA>>> / <<<END_DATA>>> fences with an instruction layer telling the model to treat them as data, not instructions. Mitigates the common prompt-injection class.
Output scrubbing. Credential-like tokens (Stripe sk_live_*, JWTs, Google API keys, AWS keys, common header formats) are redacted from logs before they leave the process.
SSRF allowlist. Any URL the backend fetches on a user's behalf (photo fetches, WeasyPrint resources) is passed through a DNS-resolving guard that blocks loopback, link-local, RFC1918, and IMDS endpoints.

7. Network Security

Production runs in isolated VPCs with restricted inbound rules.
Administrative access only via bastion + MFA.
Separate environments (dev / staging / prod) with no production data in lower environments.
Egress filtering on outbound connections from the pipeline service.

8. Monitoring and Logging

Sentry captures unhandled exceptions in real time; on-call is paged for critical spikes.
UptimeRobot / external uptime monitor pings /health every five minutes.
Structured logs with request-correlation IDs and user-ID tags (via Sentry scope) to trace one user's request across the pipeline.
Retention: application logs 90 days; Sentry events at the retention window selected in Sentry; billing and security logs 7 years.

9. Incident Response

Documented incident-response plan with defined severity levels and escalation.
On-call rotation for security incidents.
Breach notification within 72 hours of awareness where legally required (GDPR Art. 33, CCPA, and many U.S. state laws).
Post-incident reviews with corrective-action tracking.
Annual tabletop exercise.

10. Business Continuity and Disaster Recovery

Daily backups with point-in-time recovery for the primary database.
Backup integrity tested monthly (a restored snapshot is spot-checked).
Recovery Time Objective (RTO): 4 hours for the primary service; 24 hours for non-critical secondary services.
Recovery Point Objective (RPO): at most 15 minutes of transactional data loss in the worst case.

11. Vendor Risk Management

Every Sub-processor is contracted with a data-processing agreement aligned to GDPR / CCPA standards.
Annual review of vendor security postures, focused on SOC 2 / ISO attestations.
Material changes to the Sub-processor list are announced at least 15 days before activation (for customers with a DPA).

12. Compliance Roadmap

Framework	Status
GDPR / UK GDPR	Continuous compliance; DPA available on request
CCPA / CPRA	Continuous compliance; Do-Not-Sell portal live
U.S. state comprehensive privacy laws (CO, VA, CT, UT, TX, OR, MT, IA, TN, DE, NH, NJ, IN, NE, and counting)	Continuous compliance
SOC 2 Type II	Target: Q4 2026, after first SOC 2 Type I
ISO 27001	Under evaluation for 2027
PCI-DSS	Not applicable — cardholder data handled solely by Stripe
HIPAA	Not applicable — Twellie does not handle PHI
FedRAMP	Not applicable — not a federal contractor

13. Responsible Disclosure

If you believe you have found a security vulnerability in Twellie:

Email security@twellie.com with a clear description, steps to reproduce, and any proof-of-concept.
Please do not publicly disclose the issue until we have had a reasonable opportunity to remediate (generally 90 days).
We commit to:
- Acknowledging receipt within two business days;
- Triaging and giving an initial severity assessment within five business days;
- Maintaining a dialogue until remediation;
- Crediting reporters in our public acknowledgements (if desired);
- Not pursuing legal action against researchers acting in good faith, consistent with our Terms of Service.

We do not currently run a paid bug-bounty programme, but we may provide swag or service credits at our discretion.

14. Out of Scope for Responsible Disclosure

Social engineering of our employees or customers;
Physical attacks against our premises or employees;
Denial-of-service attacks;
Attacks against third-party services (Supabase, Stripe, etc.) — report those directly to the vendor.

15. Attestations

We will publish third-party attestations here as they are completed. At time of this writing, no third-party security audit has been completed; an internal security review dated April 2026 addresses OWASP Top 10 and is reflected in the current controls.

16. Contact

Security issues / vulnerabilities: security@twellie.com (PGP public key available on request)
Privacy inquiries: privacy@twellie.com
General: help@twellie.com

Security is an ongoing practice, not a destination. We will update this page as we harden the platform; material changes are announced with the Last-Updated date at the top.