Security

What follows is true today. It deliberately avoids the words that usually appear on a page like this — there is no "military grade" anything, and no badge claiming a certification nobody has issued.

Accounts and access

• Verify your email before creating an account. You can then add a password or continue using email links, passkeys or a connected sign-in provider.
• Passwords are stored as salted, computationally expensive hashes. Setting or changing a password checks for known breaches using a partial hash; the password and full hash are never sent to the breach-check service.
• Changing or removing a password requires recent verification and ends existing sessions and outstanding sign-in links. Password recovery verifies access to your email.
• Sign-in links are single-use, expire in fifteen minutes, and are stored only as a hash.
• Sessions live on the server. Signing out ends the session there, not just in the browser.
• Sign out everywhere ends every session on every device, and also kills any sign-in link still sitting unread in the inbox.
• Consequential actions — enabling automated sending, raising an offer ceiling, deleting a workspace — require a fresh confirmation, so a stolen month-old session cannot perform them.

Separation between customers

Every query that touches customer data carries the workspace identifier in the statement itself, rather than relying on an earlier check having happened. Knowing another customer's identifier is not access to it, and an automated suite asserts that on every build.

Secrets

• Vendor API keys live only on the server. They are never sent to the browser, and a build-time probe plants unique markers for each one and crawls the shipped pages, the JavaScript and the response headers to confirm none appears.
• Card details are entered on Stripe and never reach our servers.
• Customer API keys are shown once and stored as a hash.

Automated sending

• Off by default, at three independent levels.
• Bounded per buy box, per workspace, and across the whole deployment.
• A circuit breaker stops all automated sending if messages start bouncing or drawing complaints. Preparing proposals continues, so the useful half of the product keeps working.
• An opt-out is honoured at send time, not only when a message was queued.

Recovery

Backups are rehearsed rather than assumed: a restore is executed against a scratch copy and checked with integrity probes that are themselves proved able to fail. The rehearsal has been run locally; running it against the production database is an activation step that has not happened yet, and this page will say so until it has.

What has not been independently verified

Honesty is more useful here than reassurance. As of this page's date:

• No external penetration test has been performed.
• No security certification (SOC 2, ISO 27001) has been obtained or applied for.
• The disaster-recovery rehearsal has been executed locally but not remotely.
• The content security policy still permits inline script, because the framework does not yet expose a per-request nonce for its hydration payload. Every other directive is enforced.

Reporting a problem

Email security@estatemvp.com with the steps to reproduce. Please do not access, modify or keep another customer's data while demonstrating an issue — a description is enough, and we would rather hear about it than have it proved. Our security reporting guidelines list what is in scope and how quickly you can expect a reply.