How We Keep Data Safe

01Our Approach

AlphaScout holds very little that is sensitive, and we keep it that way on purpose. The product reads public sources; we store no personal e-mail addresses or phone numbers in company data; and card details never reach our servers. What remains (accounts, API keys, saved companies and notes) is protected as described here.

This page says what is in place today, in plain terms, and what is not.

02Data in Transit and at Rest

• Everything is served over HTTPS with TLS 1.2 or 1.3 only, forward secrecy and HTTP Strict Transport Security (preloaded). Plain HTTP is redirected.
• Customer accounts have no password to steal: sign-in is Google or a one-time link sent by e-mail, and sessions use secure, HTTP-only cookies.
• API keys are shown once and stored only as SHA-256 hashes; a database leak would not reveal a usable key. Keys can be limited to your servers' addresses and given an expiry, and a key used from many addresses or to walk through every profile is paused automatically (see the API docs).
• Credentials you give us for other services (a CRM token, a Slack webhook) are encrypted with AES-256-GCM before they are stored.
• Payments are handled by Dodo Payments, the merchant of record. Card numbers are entered on their page and never touch AlphaScout.

03Access Control

• Workspaces have owner, admin and member roles. Only owners and admins manage keys, billing and members.
• Sign-ins from a new device trigger an e-mail alert, and you can see and end your sessions from your account.
• Requests are rate-limited per address, per account and per API key, and sign-in and public forms are protected against automated abuse.
• Our own admin console runs on a separate host with separate cookies and shorter sessions, and only named staff accounts can sign in.
• The REST API and the MCP server are read-only. An API key cannot change your pipeline, shortlist, billing or settings.

04Application Security

• A strict Content Security Policy, frame blocking, content-type sniffing protection and a locked-down permissions policy on every page.
• State-changing requests are checked against the site's own origin; inputs are validated against schemas; database access goes through a typed ORM with bound parameters.
• Our crawler refuses to fetch anything that resolves to a private, loopback or link-local address, so a hostile web page cannot point it at our own network.
• Dependencies are audited for known vulnerabilities and updated; framework security patches are applied promptly.

05Infrastructure

• Only SSH, HTTP and HTTPS are open to the internet. Databases and the engine API are not reachable from outside: they sit on a private network, and the engine answers only the web app, which presents a shared secret.
• Application containers run as unprivileged users with every Linux capability dropped and privilege escalation disabled.
• Repeated failed logins are banned automatically, and operating system security updates install automatically.
• Production secrets live outside the code repository and are never committed.

06What We Don't Have Yet

AlphaScout is a young product, and we would rather be exact than reassuring:

• We do not hold a SOC 2 or ISO 27001 certification yet, and we have not published an independent penetration test.
• There is no single sign-on (SAML) or audit-log export for customers yet.
• Customer data is hosted in one region. Tell us if your policy requires a specific one.

If a security questionnaire is part of your buying process, send it through the contact page and we will answer it honestly.

07Reporting a Vulnerability

If you think you have found a security problem, please tell us through the contact page before sharing it publicly, and include enough detail to reproduce it. Our security.txt has the same details in machine-readable form.

Please don't access other customers' data, degrade the service or run automated scanners against production. We will acknowledge reports within three working days and keep you updated until the issue is fixed.