Security

The worst failure a multi-tenant product can have is showing one customer another customer’s data. We defend against it in two independent places, so that a mistake in either one is not enough on its own.

• In the database. Every table holding customer data has row-level security enabled, with policies that scope reads and writes to the owning account. This is enforced by Postgres, not by application code.
• In every query. Server code also filters on the account explicitly. This matters most on the paths that use a privileged connection for background work — webhooks, scheduled jobs — where row-level security is bypassed by design and the explicit filter is what remains.

The account identity is always taken from the authenticated session on the server. A client-supplied account identifier is never trusted, in any request.

All connections use TLS, with HSTS set for two years including subdomains. Data at rest is encrypted by our database and storage providers.

Mailbox credentials get an additional layer. OAuth tokens and SMTP passwords for the mailboxes you connect are encrypted with AES-256-GCM by the application before they are stored, using a key held outside the database. They are never returned by any API endpoint — not to an administrator, and not to you. Once connected, a credential can be replaced but not read back.

Accounts are authenticated by Supabase Auth. Passwords are stored as hashes by Supabase and never reach our application code. Registration requires email confirmation, and the session is refreshed and revalidated against the auth server on every request rather than trusted from a cookie.

Error messages are written not to leak whether an address is registered. Signing up with an existing address returns the same response as signing up with a new one, because the alternative turns the signup form into a tool for confirming who your customers are.

There is no administrative area inside the web application, and one is not going to be added. Administration runs from a separate desktop client against a dedicated API, and nothing administrative is served from the public site — no page, no code in the browser bundle, no route to discover.

More importantly, operators are a separate identity from customer accounts. Compromising someone’s customer session yields no administrative capability whatsoever, because the two authentication systems share nothing.

That API is built with the assumption that it is reachable and will be attacked:

• Argon2id password hashing, with only hashes of session tokens stored.
• Per-credential lockout, rate limiting, and responses that resist username discovery.
• An optional network allow-list, re-checked on every request rather than at login.
• A required permission on every endpoint, checked by a wrapper — so an endpoint that forgets to declare one fails to compile rather than shipping unguarded.
• An audit record for every authenticated call, including the ones that were denied.
• No endpoint that can create an operator or mint an API key in a customer’s name. Provisioning happens from a local command-line tool that already requires access to a trusted machine, so a compromised session cannot manufacture durable credentials for itself.

• A Content Security Policy restricting scripts, frames, connections and form targets to known origins, with framing denied outright.
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Strict-Transport-Security set on every response.
• Every input crossing a trust boundary validated against a schema before use.
• Every list endpoint bounded — a default page size and a hard maximum, so no request can ask the database for everything.
• Payment webhooks recorded before processing and treated as idempotent, so a retry from the payment provider cannot double-credit an account.

Logs are an underrated way to leak data, because they are copied, shipped and retained by systems that were never reviewed as data stores.

• Authentication tokens, API keys and passwords are never logged.
• Full email bodies are never logged.
• IP addresses are stored only as salted hashes. That is enough to rate limit and to spot abuse, and not enough to reconstruct who was where.

Content is sent to the AI provider to fulfil the specific request you made — a search, an enrichment, a draft — and for nothing else. Your data is not used to train models.

Every discovery and enrichment response has to arrive with grounding evidence and source URLs. One that does not is discarded rather than saved. That is a data integrity control as much as a product decision: it is what stops the CRM filling with confident, invented records that look exactly like real ones.

Public business facts — a company’s name, address, website — may be cached to avoid repeating an identical search. Anything you create or annotate is never cached, because a cache shared across accounts is a tenancy boundary in a place nobody thinks to look.

We hold no SOC 2 report and no ISO 27001 certification. We are not going to imply otherwise with a badge, and if a procurement process requires one today, we are not the right answer for it yet.

What we can give you is specifics: the controls on this page, the commitments in the Data Processing Addendum, and a direct answer to a direct question at security@prospexly.com.

If you have found a security problem, please tell us at security@prospexly.com. Include what you found, how to reproduce it, and what you think the impact is.

What you can expect from us:

• An acknowledgement within two working days.
• An assessment and a plan within ten working days.
• Credit in the fix notes, if you want it.
• No legal action for research conducted in good faith under the terms below. Reporting a vulnerability properly is a favour, and treating it as a breach is how organisations stop hearing about their problems.

Please, while testing:

• Use your own account and your own data. Do not access anyone else’s.
• Do not run denial-of-service tests, send bulk mail through the platform, or degrade the service for other customers.
• Stop as soon as you have confirmed a problem, and do not extract more data than needed to demonstrate it.
• Give us a reasonable chance to fix it before disclosing publicly.

If your report involves customer data being exposed, say so in the first line so it is triaged immediately. The breach obligations in the Data Processing Addendum start from the moment we know.