Skip to main content
Swan is built on a few layers of protection: verified identity, org-scoped data access, role-based permissions, and encrypted secret storage. This page describes the mechanics; for who can do what once they’re logged in, see roles and permissions.

​
Authentication

You sign in to Swan through a managed identity provider, which handles password storage, sessions, and login security — Swan itself never sees or stores your password. Every request to Swan’s API carries a signed token that’s verified on every call before Swan looks up your user record and organization membership. If that verification fails, the request is rejected before it reaches any of your data.

​
Organization isolation

Every piece of data in Swan — companies, contacts, sequences, triggers, conversations — belongs to a single organization. When you authenticate, Swan resolves which organizations you’re allowed to access and which one you’re currently operating in, and every subsequent query is scoped to that organization. Requesting an organization you don’t belong to is rejected outright. There’s no cross-org data access path in normal use.

​
Roles and per-resource permissions

Within an org, you’re assigned one of three roles — Admin, Member, or Viewer — that gate which actions you can take on skills, triggers, and org knowledge. Admins can also override the default permissions per resource type, for example letting Members create triggers while keeping org knowledge edits Admin-only. See roles and permissions for the full breakdown.

​
Where your data lives

Your organization’s data — companies, contacts, sequence and message content, execution history — is stored in a managed MySQL database hosted on AWS, encrypted at rest by the database provider.

​
Secrets and credentials

Platform-level secrets (API keys for the providers Swan integrates with, signing keys, and similar credentials) are stored in a dedicated AWS secrets management service, not in application code or the database alongside your business data. Your connected email and LinkedIn accounts work the same way from your side: Swan doesn’t ask for or store your mailbox or LinkedIn password. Sign-in for connected accounts happens through Unipile, the provider Swan uses to send and receive email and LinkedIn messages on your behalf — Swan’s database only holds a reference ID for the connected account, not the underlying credentials. You connect senders from Tools; see senders and connected accounts for how connecting works.

​
Webhook security

Swan receives webhooks from a few external providers — for example billing providers and Slack. Each of these is signature-verified: Swan checks a cryptographic signature (and, for Slack, a request timestamp) on every inbound webhook before processing it, and rejects anything that doesn’t match. A request that merely looks like it came from one of these providers, without the correct signature, is dropped.

​
Common questions

Does Swan store my email or LinkedIn password? No. Sign-in for connected accounts is handled by Unipile, the sending infrastructure provider. Swan stores only a reference to the connected account, not your credentials. Can someone in another organization see my data? No. Every request is scoped to the organization you’re authenticated into, and Swan validates that you actually belong to that organization on every request. Is Swan SOC 2 certified or GDPR compliant? Swan is currently in its SOC 2 observation period, with certification expected by the end of Q3 2026. On GDPR, Swan operates as a data processor and a data processing agreement is available — see data privacy. Can I rotate a secret I’ve given Swan if I think it leaked? Yes — generate a new key in the source tool and update the connection on Tools; webhook trigger URLs are rotated by regenerating the trigger from its configuration tab. See secrets and credentials.