Security

This page says how [Company Legal Name] protects the data you trust us with. It describes what the product does today.

What we protect, in order

1. LinkedIn session material. A leak would let someone act as you on LinkedIn.
2. Your customer data: leads, conversations and message text.
3. Billing and account control: organizations, roles and payments.
4. Our own secrets: encryption keys and the credentials of our providers.

How LinkedIn sessions are sealed

When you connect an account, the browser extension or the paste page encrypts the session cookies in your own browser, to the public key of our worker. Our web servers get only an opaque encrypted block. They hold public keys only, so a stolen database or a read of the web tier's storage, logs or memory yields only blocks that cannot be opened. Sealing does not defend against someone who can change what the web tier serves to your browser (for example a hijacked deploy or a malicious dependency), because the public keys and the paste page come from it. We guard that path with reviewed deploys and with a check that the keys we serve match the ones the worker holds (a mismatch raises an alert), and we say so plainly. Only the worker holds the private keys, and it opens a session only to act on your account.

A new session does nothing until the worker has checked that it belongs to the LinkedIn account you named. Cookie values are never written to logs, error reports or job payloads, never returned by an API, and never shown in our admin console. A replaced or rejected session is deleted. We read only a short allowlist of cookies. Keys can be rotated, and after a key compromise we purge every stored session.

Separation between customers

Every record belongs to a workspace and is reached only through code that scopes to it. Screens read through named read models that start from your own accounts, so a LinkedIn identity that moves between customers never shows its previous history. Tests check that one organization cannot read or change another's data through any action or route.

Access control

Every action and API route signs the person in, checks a named permission, and only then does the work. Sensitive permissions, such as billing, deleting data and reading message text in the support view, are separate and are not part of default roles. Customers can enable two factor sign in with an authenticator app.

Our operators

The admin console is a separate deployment with its own secret. Every operator must use multi factor authentication. Reading across customers is a separate path and every use is recorded. Operators cannot read message text without a separate permission and a recorded reason.

Network and IP addresses

Each connected account uses its own fixed IP address, and our worker never falls back to a direct connection. Provider credentials are secrets kept in our secret store and are never logged.

Application hygiene

Secrets live in platform secret stores, never in our code. We review dependency updates. Payment webhooks are checked by signature. We rate limit sign in, pairing and extension endpoints, use security headers and cross site protections, and allow only listed origins for the extension. Webhook addresses you give us are checked against private address ranges.

Backups

Backups are encrypted and stored apart from the keys. We rehearse restores, and a restore re-applies do-not-contact lists first so nobody who asked to stop is contacted.

Your data

Message text is cleared 30 days after an action finishes. You can delete a lead, an account or a workspace. Stored sessions are purged 30 days after a subscription ends. See the Privacy policy for every retention period.

Providers

The companies that process data for us are on the Sub-processors page.

If something goes wrong

We follow a written incident plan. If customer data is affected, we tell the customers concerned without undue delay. If a key is ever compromised, we rotate keys, purge stored sessions and tell customers to sign out of all their LinkedIn sessions.

Report a vulnerability

Write to security@[domain]. We acknowledge a report within [Acknowledgement Time] and keep you updated. Please give us reasonable time to fix a problem before you share it, and do not access other people's data or disrupt the service while testing. Our policy and contact details are also in security.txt.