1. Overview

BOOST is built to handle real estate workflows that involve sensitive client and transaction information. The goal is to keep authentication, storage, and access control simple, predictable, and secure, while avoiding unnecessary collection of personal data.

This page describes intended security behavior and does not replace your own security, legal, or compliance review. Not legal advice. Not financial advice.

2. Account authentication

BOOST uses email and password authentication only. Social-login and OAuth-based sign-in are intentionally excluded to keep credential flows straightforward and easy to reason about.

• Each user has a unique email and password combination for access.
• Passwords are never stored in plain text; they are hashed using industry-standard algorithms.
• Password reset and email verification flows are handled through dedicated endpoints and do not expose sensitive tokens in URLs beyond what is necessary to complete verification.

You are responsible for choosing strong passwords and not reusing credentials from other systems. Brokerage policies may require additional internal controls.

3. Data storage & encryption

BOOST is implemented on Cloudflare Workers, with data stored in Cloudflare D1 and KV. The design assumes that only the minimum necessary data is stored for account, usage, and tool operations.

• Cloudflare D1 is used for structured data such as accounts, subscriptions, and usage records.
• Cloudflare KV is used for configuration, cached metadata, and non-sensitive preferences where appropriate.
• All communication with the BOOST application and API is intended to use HTTPS only.

BOOST is not designed to store full payment card numbers or other PCI data; billing providers handle those details separately.

4. Secrets, API keys, and webhooks

BOOST relies on secrets for internal configuration and for external integrations such as billing and email. These are kept out of client-side code and are never exposed in the browser.

• API keys for internal services are stored as environment variables or platform secrets.
• Any future BOOST-issued API keys for your own integrations must be kept server-side and never placed in front-end JavaScript, public repositories, or client apps.
• Webhook endpoints (for example, billing events) are expected to validate signatures and operate over HTTPS.

Key rotation and revocation should be part of your operational playbook. When a key is compromised, it should be immediately revoked and replaced.

5. Access control & roles

BOOST is designed primarily for individual agents and small teams. Roles and access are kept intentionally simple to reduce misconfiguration risk.

• Each user signs in with their own unique email and password.
• Future team features may introduce roles (for example, admin vs. standard user), but the core principle is that non-admin users cannot change billing or security-sensitive settings.
• Access to administrative views (billing, subscription management, API keys) is restricted to users with appropriate privileges.

If your brokerage requires more granular roles, you should define an internal policy for who may hold admin access to BOOST-related settings.

6. Logs, monitoring & data retention

BOOST uses logging for operational monitoring, debugging, and usage tracking. Logs are not intended to be used for long-term storage of client content.

• Request logs may include timestamps, tool IDs, usage counts, and high-level request outcomes (success, validation error, etc.).
• Where possible, verbose content is avoided or truncated in logs to reduce the risk of sensitive data being stored unintentionally.
• Data retention periods should be kept as short as practical, consistent with debugging and audit needs.

You should avoid putting highly sensitive content (for example, full legal names with IDs, banking details, or social security numbers) into prompts. BOOST is not intended as a storage system for confidential documents.

7. Content handling & compliance

BOOST tools focus on property features, client goals, and process explanations. They explicitly avoid protected-class content, crime data, school ratings, and demographic descriptions.

• Inputs are validated to discourage or block prohibited topics where possible.
• Outputs are filtered to remove unsafe phrasing and insert required disclaimers.
• Content is treated as transient working material, not as an official record; you remain responsible for how it is stored, archived, and shared.

Fair Housing/CREA compliant; no protected-class criteria, crime statistics, school ratings, or demographic content used. Not legal advice. Not financial advice.

8. Your responsibilities

Even with a security-conscious design, final responsibility for safe and compliant use of BOOST rests with you and your brokerage.

• Protect your login credentials and do not share accounts.
• Limit who can view or change billing, API keys, and security settings.
• Regularly review access and revoke it when team members change roles or leave.
• Avoid entering unnecessary personal information in prompts; keep details limited to what is required for the task.
• Confirm any jurisdiction-specific security or privacy requirements with your broker, legal counsel, or IT department.

BOOST is one part of your overall security posture. Use it alongside your brokerage's existing security, privacy, and compliance controls.