Security

Tenant isolation

Every record that belongs to a customer carries the workspace that owns it, and workspace scope is applied in the data-access layer rather than left to each screen to remember. A query that forgets its workspace filter does not silently return another tenant's rows — it fails the tenancy guard.

• Workspaces belong to an organisation; a user only sees workspaces they are a member of.
• Cross-workspace reads are not possible through the application API.
• Deleting a workspace cascades to its leads, signals, campaigns, messages and connections.
• What the product learns from performance data is stored per workspace and is never pooled across customers.

Provider credentials are encrypted at rest

CRM tokens, mailbox credentials, enrichment API keys and social session data are encrypted before they are written to the database using authenticated encryption, with the key held outside the database in the application environment. They are decrypted only in the process that needs to make the call.

• Credentials are never returned to the browser after they are saved — the UI shows a masked hint and a status, not the value.
• They are redacted from logs, error reports and support exports.
• Revoking a connection removes the stored secret rather than flagging it inactive.
• Rotating the encryption key re-wraps stored secrets without customers re-entering them.

Role-based access control

Permissions are checked on the server for every mutating action. Hiding a button is a nicety; the check that matters happens before the write.

Exact role names and boundaries are enforced in code; the table above is the shape of it rather than an exhaustive matrix.

Audit logging

Security-relevant events are written to an append-only audit trail with the actor, the workspace, the target record, a timestamp and the request context. Audit entries are not editable from the application.

• Sign-in, sign-out and failed authentication attempts.
• Member invitations, removals and role changes.
• Provider credential creation, update and revocation.
• Send-mode changes, including any switch to full auto.
• Suppression and blacklist additions and removals.
• Data exports and bulk deletions.

Outreach safeguards

Most of the real-world risk in a tool like this is sending something that should not have been sent. The safeguards are therefore enforced at send time, in one place, rather than at enrolment:

• Suppression is checked immediately before dispatch, so an entry added mid-campaign takes effect on the next step.
• Suppression can be scoped to a person, an email address, a domain or a whole company.
• Replies and unsubscribes stop remaining sequence steps automatically.
• Per-sender and per-channel daily caps are enforced; a step waits rather than being dropped.
• Review-before-send is the default for new campaigns, and full auto is per campaign, role-gated and reversible.
• Requests submitted through the public do-not-contact form are held on a platform-level list that is checked before the per-workspace one, so they cover workspaces created after the request and cannot be overridden by a customer.

Infrastructure

• Data is encrypted in transit over TLS, and at rest by the managed database and storage layer.
• Passwords are stored as salted hashes using a slow, memory-hard algorithm — never reversibly.
• Sessions are signed and expiring; sign-out invalidates them server-side.
• Outbound webhooks are HMAC-signed with a timestamped payload so a captured delivery cannot be replayed.
• Backups run on a rolling window and are restorable; restore drills are part of our operational routine.
• Dependencies are monitored for known vulnerabilities and patched on a regular cadence.

What we do not have

Reporting a vulnerability

If you have found a security issue, email support@ethosmr.com with the subject “Security disclosure”. Include enough detail to reproduce it.

We will acknowledge within two business days and keep you updated until it is resolved. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and data destruction, and give us reasonable time to fix the issue before disclosing it. We do not currently run a paid bug bounty.