Security Posture.

• Encryption in transit - the Site is served over HTTPS/TLS, and waitlist submissions are sent to our API over encrypted browser connections.
• Managed database - waitlist entries are stored with a managed database provider. Internal credentials are not shipped to the browser.
• No payment data - this pre-launch site does not collect card numbers, bank details, identity documents, or other financial account information.
• Minimal waitlist fields - email is required; name and phone are optional. Partial phone entries are not sent by the primary waitlist form.
• API safeguards - waitlist and chat endpoints validate requests, limit abusive traffic, and avoid caching sensitive responses.
• Hardened browser policy - the site uses browser-level protections that limit framing, unsafe content handling, unnecessary browser permissions, and overly broad cross-site data sharing.

• Tabby-only answers - the assistant is designed for general questions about Tabby, the waitlist, and the product direction. It is not a general-purpose chatbot.
• Abuse prevention - we use safeguards to reduce spam, automated abuse, and attempts to misuse the assistant.
• Protected processing - messages are processed through controlled server-side systems, so private service credentials are not exposed in the browser.
• No sensitive details - do not send passwords, payment details, private legal requests, or future account support issues through the assistant.

• Payment partners - card, bank, escrow, and virtual-card flows will be handled through appropriate regulated infrastructure partners and app-specific agreements.
• No raw card storage by Tabby - the intended architecture is to rely on compliant payment infrastructure for sensitive payment credentials instead of storing raw card or bank numbers on Tabby servers.
• Account controls - the app will need stronger authentication, account recovery, device controls, and fraud monitoring before real funds move.
• Auditability - tab state changes such as item claims, edits, payments, and settlement will need durable audit trails so disputes can be investigated.

The current Site runs on managed cloud infrastructure. We prefer managed, well-maintained services instead of custom security-sensitive infrastructure. Production secrets are kept out of source code.

As the app moves toward broader beta, this page should be expanded with additional public-facing commitments for access review, incident response, vendor review, and payment-specific compliance without exposing internal implementation details.

If you believe you have found a security issue in this site, the waitlist API, or the AI assistant, please avoid public disclosure until we have had a fair chance to investigate and fix it. A dedicated security contact will be published here before broader beta access or public launch. Please do not run high-volume scanners, denial-of-service tests, or social-engineering attempts.

In scope today: splittabby.com, the waitlist API, the demo page, and the "Ask Tabby" assistant. We will expand the in-scope surface as we approach launch.

Out of scope: third-party services we link to, denial-of-service testing, social engineering of Tabby team members, and reports that depend on a victim running outdated browsers.

This page will be updated as Tabby's infrastructure evolves toward launch. Material updates will be dated above and the version stamp at the top of this document is bumped with every revision.