Security & Data Protection

Where your data lives

MaxxBot keeps two very different kinds of data in two different places:

• ✓Your data — your chat sessions and messages, and any spend files you upload and their classified breakdown — is stored in a dedicated Supabase (PostgreSQL) database. Every row is tagged with your account identifier and isolated per account (see below).
• ✓MaxxBot's reference data — rate benchmarks, vendor and service information, and methodology — is a shared, read-onlyknowledge base that contains no customer data at all. It is the same library for every customer and cannot be written to by a user request, so it is not a path by which one customer's data could reach another.

How one account is kept separate from another

Isolation is enforced in depth, and the last line of defence is the database itself:

• ✓Authenticated identity. Every request is authenticated by Clerk on the server. Your account identity is resolved server-side — there is no client-supplied identifier that could be forged.
• ✓Row-Level Security (RLS). Every table that holds user data has PostgreSQL Row-Level Security enabled and forced, with a policy that allows a request to read or write a row only when the row's account tag matches the authenticated account. A request with no valid account sees zero rows — it fails closed, not open.
• ✓Least-privilege database role. The application connects using a dedicated database role that is not the owner/superuser and cannot bypass Row-Level Security. So isolation is enforced by the database engine on every query, not merely by application code that could contain a bug.
• ✓Write-forgery protection.The same policy's write check blocks an account from inserting a row stamped with someone else's account identifier.

What we prove — automatically

These are not aspirational statements. We run an automated adversarial isolation test that connects as the real least-privilege application role and attempts cross-account reads, updates, deletes, and forged writes. In the most recent run it passed 18 of 18 checks, including a critical one: isolation holds for a freshly generated account identifier the policy has never encountered — evidence that the isolation is a genuine per-account rule, not a coincidence that only works for a couple of hard-coded test accounts. A separate check confirms an unauthenticated request to the chat API is rejected (HTTP 401). This suite is part of our release checks, and the underlying evidence is reproducible by anyone with database access.

Other controls in place

• ✓Encryption in transit. Connections to the application and to the database are encrypted with TLS/HTTPS.
• ✓Abuse & cost controls. Per-account and per-network rate limits bound how many requests can be made in a short window.
• ✓Specialised authentication. Account sign-in and credential handling are managed by Clerk rather than built in-house.

What is NOT yet in place — stated plainly

We think an honest security page is more useful than a reassuring one. These are real limitations of a beta product, and a security reviewer should weigh them:

• ○No SOC 2, ISO 27001, or other third-party certification. Our security statements are a first-party engineering attestation, not an audited control report.
• ○No independent third-party penetration test has been performed yet. The isolation evidence above is our own automated adversarial test, not an external red-team.
• ○The isolation test is not yet a required, merge-blocking CI gate. It passes today and is run before releases, but automating it as a hard gate is a known, not-yet-completed hardening step.
• ○Development and production are not yet on fully separated database projects. Environment separation is a standard enterprise expectation we have not yet fully met.
• ○At-rest encryption, key management, and backup/restore posture rely on our platform providers' defaults and have not been independently attested in detail here.

The straight answer

On the question that matters most — "can one user ever see another user's data?"— for the data that is customer-specific (your chats and uploaded spend), the answer is no, and we can demonstrate it: isolation is enforced by the database against a role that cannot bypass it, and verified on every release including against an account the policy has never seen. A full enterprise security programme is broader than data isolation — SOC 2, a third-party penetration test, separated environments, and a CI-gated regression check are on our roadmap and not yet complete. We would rather tell you that directly than claim MaxxBot is "fully secure." No system is.

Questions

Security or data-handling questions are welcome — email contact@yourscalex.com. See also our Privacy Policy and Terms of Service.