Security

Encryption at rest

Every credential you enter — your Salesloft API key and each enrichment provider's API key — is encrypted before it's stored, using AES-256-GCM envelope encryption. Each encrypted blob is tagged with the version of the key that encrypted it, so the key can be rotated later without breaking access to anything encrypted under a previous version.

Encryption in transit

All traffic between Pulsar Enrich and Salesloft, your enrichment providers, Resend, and your browser happens over HTTPS/TLS. We don't accept plaintext connections for any of this.

How credentials are handled

A provider API key is decrypted only in memory, only at the moment we're about to make the API call it's for, and only by the process handling that job. It's never written back out in plaintext, never included in logs, and never re-displayed in the dashboard after you paste it in.

Sign-in

There are no passwords for team accounts. Signing in means entering your Salesloft email; if it matches an active Admin on a connected team, we email a one-time link and a 6-digit code, both valid for 10 minutes. The code is capped at 5 attempts. The link requires an actual click to complete sign-in — we deliberately don't auto-sign-in the moment the link is opened, because some corporate email systems automatically visit links in incoming mail to scan them, which would otherwise burn the one-time link before a person ever saw it. A resend option is available if a link or code expires.

Tenant isolation

Every table that holds tenant data — connections, credentials, cadence configs, enrichment jobs, audit log — is scoped by a tenant ID, and every dashboard session is bound to one tenant at sign-in. The one exception is our own internal operator login (used by PulsarGTM staff, not customers), which can explicitly switch between tenants to provide support; that ability is separate from the customer sign-in path and not available to it. We currently rely on this scoping being applied consistently at the query layer; a dedicated automated test suite that actively tries to read or write across tenant boundaries is in progress and not yet in place — see Roadmap below.

Webhook verification

Salesloft webhook deliveries are verified with an HMAC signature check against a callback token generated uniquely per tenant at connection time, so a request can't be spoofed as coming from Salesloft without that token.

Infrastructure

The application, background worker, Postgres database, and Redis queue all run on Railway. We don't run our own servers or data centers; we inherit Railway's platform-level security practices for the infrastructure layer.

Roadmap — what's next, stated honestly

A few things we know are worth doing and haven't shipped yet:

• An automated, DB-backed tenant-isolation test suite that actively attempts cross-tenant reads/writes and asserts they fail.
• Per-tenant credit caps and rate limiting on enrichment jobs.
• A self-service settings page for disconnecting Salesloft and requesting data deletion, rather than an email request.

Reporting a security issue

If you find a security issue, please email security@pulsargtm.com rather than filing it publicly. We'll acknowledge and follow up as quickly as we can.