Security

The two things worth protecting in a tool like TEASE are your fan data — chats, profiles, spend, the vault — and your live account access, because a workspace holds the keys to a creator's whole business. This page explains, in plain language, what we protect and in what state. Where a protection is still being rolled out, we say so rather than dress it up as live. Security questions or a vulnerability to report? Jump to Report a vulnerability.

Your data is encrypted

Your most sensitive data is encrypted both in transit (the connection to your browser) and at rest (on disk), using strong, modern encryption.

• Credentials, integration keys and proxy secrets are encrypted at rest — a stolen database or backup copy does not hand these over in the clear.
• The most sensitive fan data captured from chats — psychological profiles, operator notes, message previews — is encrypted at rest too. If a database or backup file were ever taken, those texts do not come out readable.
• Two-factor (authenticator) secrets are encrypted at rest as well, so a leaked database copy can't be used to regenerate your one-time codes or bypass 2FA.
• The master key can live in a cloud key-management service, so a stolen database, backup or disk snapshot is useless without separate, audited access — and any mass-decryption attempt is recorded.

Encryption is transparent: it protects you without changing how the product works day to day. And there are zero secret values committed anywhere in our code or tracked documentation — we verify that continuously.

Every workspace is isolated

One customer's data is never visible to another. A request for someone else's record simply doesn't find it — there is no "peek at the neighbour's data" path.

• Isolation holds for analytics too: totals, counts and charts are scoped to your own workspace, not just individual records.
• This is proven by repeated adversarial audits (internal red-teams) and covered by automated regression tests — not merely asserted.
• A single cross-workspace issue found during one internal red-team was closed and locked down with tests before it could reach production.
• Platform-owner ("god-mode") actions are restricted to the platform owner. A customer or teammate cannot escalate into them.

Sign-in can't be bypassed or brute-forced

See Authentication for how you sign in day to day; this is what stands behind it.

• Passwords are stored hashed with a modern algorithm. Two-factor (authenticator app) with one-time backup codes is available.
• You can sign in with a passkey (fingerprint / Face ID / hardware key) instead of a password. The private key never leaves your device, is bound to our domain, and can't be phished or stolen from a database.
• Password guessing doesn't work: after a run of wrong attempts the account is temporarily locked, the lock survives a service restart, and the owner is alerted.
• Guessing the second factor doesn't work either — wrong codes lock the second factor across every door at once (sign-in and every re-confirmation step).
• A one-time code is strictly one-time: an intercepted code cannot be replayed even inside its short validity window, and a backup code can't be spent twice even under a race.
• You can't tell whether an account exists by timing the response — sign-in and registration take the same time for a known or unknown address.
• "Doors around the login" are closed: for a 2FA account, password reset, email change, issuing an API key and Telegram sign-in all require the second factor — not just inbox or session access.

You control your sessions

You can see and manage where you're signed in, and dangerous actions ask for fresh proof so a stray session can't do lasting damage.

• See your active sessions (device, country, network, when) and end any single one — a forgotten or stolen session — without signing out of the rest. "Sign out everywhere" is available too.
• A long-idle session can expire on its own, and there is a global stop switch.
• A session can be bound to a device key that never leaves the device — so a cookie copied to another computer dies quickly and can't be renewed.
• Dangerous actions require fresh proof: deleting an account asks for the password (and 2FA code). Catastrophic platform-owner actions — deleting a customer, acting as a customer, resetting their 2FA — re-ask for the password, so a hijacked or forgotten session can't do irreversible damage.
• Changing your password signs stolen sibling sessions out.

Least-privilege team access

Teammates get exactly the access you grant them — nothing more. See Team access for the full walkthrough.

• Team access is granular: per-area view / edit permissions, not all-or-nothing.
• A teammate with edit or export rights must turn on two-factor before they can change or export anything — until then they're view-only. (Their own 2FA-setup page is never blocked, so they can't lock themselves out.)
• Bulk data export (all fans, conversations, the vault) is gated behind a second factor, a daily quota and a tamper-evident audit entry — quietly siphoning the whole database from one session is not possible.
• Expensive AI features and machine access are rate-limited per user, so a teammate can't loop them to burn the AI or API budget.
• A manager can never grant permissions higher than their own.

Here is what each level of access can and can't do:

Every action is enforced on the server

Permissions and validation live on the server for every data request — not just in the interface. This is the exact attack class that scraped a competitor's back-end API, and it's what this defends against.

• Server-side authorization on every request. Bypassing the interface doesn't bypass the checks.
• Payment and third-party webhooks are verified cryptographically and are closed by default — a misconfiguration never accepts everything, and a replayed payment can't double-grant.
• Common web attacks are handled: no SQL or command injection, no open redirects, no path traversal; image uploads are protected against decompression bombs; XML is parsed safely.
• When our server follows a customer-supplied address (custom-domain check, mail host), it can't be tricked into reaching an internal network address or cloud metadata.
• Chart labels and source/domain names render as text, so malicious code in a name can't run in the owner's dashboard.
• The admin panel ships a strict content-security policy and is isolated from any window that opened it. Error responses never echo your submitted password or code back, and never leak a stack trace.

We watch for abuse and lock down fast

Beyond blocking attacks, we watch for the patterns that precede a data leak.

• Abnormal read-volume alerts: if one customer's account is suddenly mass-downloading fans or conversations, it's flagged — the exact signal breached competitors never had.
• Live session-hijack detection: watching doesn't stop at login. If an active session suddenly comes from a different country, network or browser, it's recorded and the owner is alerted (and in the strictest mode the user's sessions are dropped).
• Tamper-evident audit log: records are chained and signed so history can't be quietly rewritten, and the head of the chain is published to the owner as an external anchor.
• Anti-insider tripwires (honeytokens) alert the owner if the secret store is touched.
• Rate limits on endpoints that send email or do heavy work, so they can't be turned into a mail bomb, a promo-code brute-forcer or a resource-exhaustion lever.

Custom domains are proven, not just pointed

• Connecting an external domain requires proving you own it (publishing a secret DNS record) — merely pointing a domain at us is not enough.
• Only verified domains are served: an unverified or "grabbed" host serves no content.
• When a domain is removed, its linked records are cleaned up so nothing dangling is left behind for someone else to hijack.

Hardened perimeter

• All traffic goes through Cloudflare: a web application firewall (managed + OWASP rules), bot protection, anti-DDoS, login rate-limiting and leaked-password detection.
• The origin server only accepts Cloudflare traffic.
• SSH access is key-only (passwords disabled).
• The connection to visitors is encrypted. Tightening the origin link (mutual TLS) and hiding the origin address are on the roadmap.

Privacy, minimization & your right to delete

• We minimize what we keep: IP addresses are stored coarsened (a subnet, not an exact address), and location is kept as a region center rather than a precise point.
• You can request deletion of your data, with real erasure (a scrub plus storage compaction) and a retention window. See Data Exports to take a portable copy of your own data first.
• Encrypted incremental backups to object storage are ready; restore verification and immutability are on the roadmap.

How we stay ahead

• Security is reviewed continuously — multiple rounds of adversarial audits (internal red-teams) with fixes shipped and covered by tests.
• Code dependencies are version-pinned, with build-integrity control on the frontend.
• In progress: automated vulnerability scanning in our build pipeline, a published vulnerability-disclosure policy, and an external penetration test after perimeter hardening.

We describe controls at the level of substance, not badges. We do not claim SOC 2 or ISO 27001 certification, because we don't yet hold those reports — we run SOC 2-aligned controls and follow established security practices, and we'll say so plainly rather than display a badge we can't evidence.

Report a vulnerability

Found a security issue, or have a question about our posture? Email security@tease.link and we'll get back to you. A machine-readable security.txt is published at our site root.

• Please give us enough detail to reproduce the issue, and time to fix it before any public disclosure.
• We don't run a paid bug-bounty program yet, but we genuinely appreciate responsible reports and will credit you if you'd like.

FAQ

---

Last reviewed: 2026-07-18. For availability and domain health, see Reliability. Detailed vulnerability write-ups and internal runbooks are kept private by design — this page describes results, not the mechanisms an attacker could use.