Beacon

Trust

Last updated: June 17, 2026

Security & Trust at Beacon

Beacon runs your outbound on data you care about: your product, your prospect lists, and the conversations they produce. That trust is the product, so we treat security as a first-class feature, not a checkbox. This page is a plain-language, honest account of how Beacon actually protects your data and your reputation. Where something is real and shipping, we say so. Where something is planned but not yet done, we label it on the roadmap rather than implying it exists.

Two principles guide everything below:

  1. Least surprise. Your data stays inside your workspace, your sending happens from your own mailbox, and nothing goes out the door without a human deciding to send it.
  2. No overstatement. We would rather under-claim and earn trust than market a certification we do not hold.

Data isolation: one workspace, one wall

Beacon is multi-tenant, and isolation is enforced in the data layer, not just by convention.

  • Every business record carries a `workspace_id`. Contacts, companies, steps, events, calls, deals, templates, suppression entries, audit logs, API keys, and webhooks are all stamped with the tenant they belong to.
  • The query layer requires a workspace. Every data-access function takes a required workspace argument as its first parameter, so the type system rejects an unscoped query at compile time. A developer literally cannot write a database call that forgets which tenant it is for.
  • By-id lookups are IDOR-proof. Fetching a record by its id always adds AND workspace_id = ?. Guessing or replaying another workspace's record id returns nothing, because the row is scoped to the caller's tenant.
  • The request's tenant comes from the authenticated session, not from anything the client can spoof. Background jobs (research, sending sweeps) resolve the tenant per record they process.
  • It is tested, not just asserted. A write-side isolation test seeds overlapping data across two workspaces and verifies zero cross-tenant leakage across the suite.

When you sign up, Beacon provisions a brand-new, fully isolated workspace with its own roles and configuration in a single transaction, so a half-built tenant can never exist.

Encryption

  • In transit: All traffic to and from Beacon is served over HTTPS/TLS. Session cookies are flagged Secure in production, so they are never transmitted over plain HTTP.
  • At rest: Your data lives in managed PostgreSQL hosted by Supabase, and application backups are handled by that platform. Encryption at rest and backup management are provided by the database host (Supabase / Postgres) rather than something Beacon reimplements.
  • Outbound to AI and webhooks: Calls to our AI provider and to your configured webhooks go over TLS; webhook delivery additionally hardens against SSRF (see Responsible AI below).

Authentication & access control

  • Passwords are hashed, never stored in plaintext. We use scrypt with a unique per-password salt, and password verification uses a constant-time comparison to resist timing attacks.
  • Sessions are signed and revocable. Signing in mints an HMAC-signed session cookie that the edge layer can verify statelessly, backed by a server-side session row that can be revoked instantly (sign-out deletes it; expired sessions are swept automatically). Cookies are HttpOnly, SameSite=Lax, and Secure in production.
  • The auth gate fails closed. In production, the signing secret (AUTH_SECRET) is mandatory: if it were ever missing, every session is rejected rather than waved through. A forged or tampered cookie never reaches application routes.
  • Role-based permissions. Users hold roles (admin / manager / rep, plus custom roles) that carry granular permission flags. Sensitive routes check the specific permission of the authenticated session user on the server, so destructive actions (resetting data, deleting the workspace, managing billing or team) require the right role, and concurrent sessions never inherit each other's permissions.
  • Significant actions are audit-logged within the workspace.

Your data, your control — no lock-in

Your data belongs to you, and you can get it out or delete it yourself, without filing a ticket.

  • Self-serve GDPR export. A workspace admin can download a single machine-readable JSON bundle of the entire workspace (contacts, companies, activity, deals, audit records, and more) at any time. For safety, the export deliberately excludes secret material: password hashes, API-key hashes, webhook signing secrets, and live session tokens are redacted or omitted.
  • CSV export anytime. Beyond the GDPR bundle, your full contact book and your activity feed export to CSV with one click from the Contacts and Analytics pages. No export tax, no "contact sales to leave."
  • Hard delete (right to be forgotten). A workspace admin can permanently delete the entire workspace and every record tied to it. This is an irreversible hard delete with no soft-delete or undo, gated behind a typed confirmation (the exact workspace name, or the literal word DELETE). It runs in a single transaction in FK-safe order so it either fully completes or rolls back cleanly.
  • Granular control too. You can delete individual contacts, companies, and deals in-app, and suppress any individual address at any time.

Deliverability & anti-spam

Beacon is built so volume cannot wreck your sender reputation, and so recipients can always make it stop.

  • One-click unsubscribe (RFC 8058). Every tracked send carries List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers plus a visible unsubscribe footer, so the unsubscribe mailbox providers like Gmail and Yahoo now require is honored automatically, with no human in the loop. Unsubscribing adds the address to the workspace's do-not-contact list.
  • Automatic hard-bounce suppression. A permanent SMTP failure (bad address) automatically suppresses that address, logs a bounce event, and parks the contact, so nothing retries a dead address and your lists stay clean without an admin babysitting them.
  • A suppression (do-not-contact) list checked before every send. Suppression is consulted on every outbound message, and is idempotent, so an address can never be re-contacted once suppressed, whether it landed there by unsubscribe, bounce, or a clear "stop" reply.
  • You are the sender, by design. Email goes out through your own SMTP / email provider, under your own domain and authentication (SPF/DKIM/DMARC). Beacon does not blast from shared pool IPs that strangers can poison. (We also publish a free deliverability checker that grades your SPF, DKIM, and DMARC posture.)
  • Sending windows and jitter keep approved messages within working hours and add natural spacing instead of firing in a detectable burst.

Responsible AI

Beacon's AI researches and drafts; it does not act on its own.

  • Anti-fabrication guardrail. The research engine is explicitly instructed to prefer sourced facts over speculation, to label anything inferred as inferred, to drop any "signal" that would be true of any company in the category, and to say so honestly when it genuinely cannot find recent signals rather than padding. Each signal carries its source through to the dossier, and any signal without a source is dropped.
  • Never invent people or verification. The AI is instructed never to invent a colleague's name (it may only reference real contacts already on file) and never to assert enrichment or verification that did not actually happen. If a live research call fails, Beacon fails loud and retries rather than silently fabricating a dossier of invented facts.
  • Human in the loop before anything sends. Beacon computes exactly one pending next step per contact. A rep reviews it in the Action Queue and approves, edits, skips, or regenerates. Nothing is delivered to a prospect without a person choosing to send it.
  • SSRF-safe outbound. Webhook delivery validates the actual IP a connection is about to use, refusing private, loopback, link-local, and cloud-metadata ranges (defending against DNS-rebinding), never follows redirects, and enforces HTTPS plus a hard timeout. This closes the common server-side request forgery paths against our outbound integrations.
  • Durable rate limiting protects public and sensitive endpoints across instances.
  • Your data is not used to train models. Customer and prospect content is sent to our AI provider only to return results to you.

Subprocessors

Beacon relies on a small, fixed set of vetted subprocessors. We do not currently use third-party web analytics, advertising, or external error-monitoring providers.

| Subprocessor | Purpose | |---|---| | Anthropic | AI research and drafting (Claude models + live web search). Inputs are not used to train models. | | Supabase | Managed PostgreSQL hosting (account data + customer content), including encryption at rest and backups. | | Vercel | Application and API hosting (serverless / edge compute). | | Stripe | Subscription billing and payment processing. Card data is held by Stripe; Beacon never stores it. | | Your own email / SMTP provider | Sending your outreach (and, where configured, reading replies). Chosen and controlled by you, under your agreement with that provider. |

If we ever add or change a subprocessor, we will update the list before or promptly after the change. The authoritative, up-to-date list lives on our subprocessor page (warmbeacon.com/subprocessors — publish the canonical list URL here).

Compliance posture

  • GDPR. For account data, Beacon is the controller. For the prospect data you upload, you are the controller and Beacon is the processor — we act on your documented instructions and process that data only to provide the service. We support data-subject rights through self-serve export and deletion, and a Data Processing Agreement (DPA) incorporating the EU Standard Contractual Clauses and the UK International Data Transfer Addendum is available on request (on the roadmap to publish a self-serve DPA link).
  • CCPA / CPRA. We do not "sell" personal data and we do not "share" it for cross-context behavioral advertising as those terms are defined under the CCPA/CPRA. California residents' access, deletion, and correction rights are supported through the same in-app tools and our privacy contact.
  • SOC 2 — on the roadmap. Beacon has not completed a SOC 2 audit. We are committed to pursuing a SOC 2 Type II examination as we scale, and will publish the report and bridge letter here when it is available. We will not claim it before it is real.
  • Independent penetration test — on the roadmap. We have not yet commissioned a third-party penetration test. This is planned, and results / a summary letter will be made available to customers under NDA once complete.

If your security or procurement team needs more detail than this page provides, reach out and we will share what we have and walk you through our practices honestly.

Reporting a vulnerability

We welcome reports from security researchers and treat them as a gift, not a threat. If you believe you have found a vulnerability in Beacon:

  • Email security@warmbeacon.com with a description, reproduction steps, and any relevant proof-of-concept.
  • Please give us a reasonable window to investigate and remediate before any public disclosure.
  • Please do not access, modify, or delete data that is not yours, and avoid degrading service for others (no automated scanning that causes load issues, no social engineering of our staff or customers).

Acting in good faith under these guidelines, you will not face legal action from us for your research. We will acknowledge your report, keep you updated on remediation, and credit you if you would like.

Last updated: June 17, 2026. This page describes Beacon's security practices in good faith and will evolve as the product does; aspirational items are explicitly labeled "on the roadmap."