Security
Written from the architecture, not from a template.
Slate is a small system and this page describes the actual one: where it runs, what it holds, who can reach it, and which parts are not finished yet.
Your LinkedIn session
The Slate Collector is a desktop application that runs on your Mac. You sign in to LinkedIn inside it, yourself, in a browser on your own machine. Slate's servers never receive your LinkedIn password, your cookie, or any other credential for your seat, and there is no Slate-operated LinkedIn account anywhere in the system.
That is an architectural fact rather than a policy: the session lives in a browser profile on your disk, and the only thing that travels between your machine and the Slate server is an order going out and a set of collected profiles coming back, over one webhook.
Collection is paced against your seat's own daily limit, stops on any LinkedIn checkpoint, and never works around a login or a second factor. Profile visits are visible to the people visited, which is why they run only after screening has cut the list, and why they can be switched off.
Where Slate runs
The Slate server is a single application server with a single SQLite database file, hosted on a dedicated virtual machine at Hetzner in Germany. Everything the product serves is served over HTTPS. There is no third-party analytics, advertising, or session-recording script on any page of this site or inside the product.
Deployment is one verified operation: a script that pushes, waits for the build, restarts the service, and then proves the running commit changed rather than assuming it did. The commit that is actually running is readable from inside the product by anyone signed in, and is deliberately not published to anonymous visitors.
Sign-in and sessions
You sign in with an email address and password, or with Google if your workspace has it configured. There is no third sign-in provider.
Sessions are recorded on the server, not just in a cookie. Signing out revokes the session row, so a cookie captured beforehand stops working immediately rather than staying valid for the rest of its lifetime. This was a real defect once: a signed-out cookie replayed after logout still answered as the person who had held it. The server-side registry is what fixed it, and every session is listed on your profile page where you can revoke any of them.
The session cookie is HTTP-only, restricted to same-site navigation, and expires after thirty days.
Who can see what
Access inside a workspace is checked on the server on every request, by two independent gates rather than by hiding a button.
- Products are separate grants. Recruiting and M&A are held independently. A member with only M&A cannot reach a Recruiting route even if that route predates the product boundary.
- Roles can be scoped. A recruiter can be assigned specific roles. Every role-scoped route checks the assignment against the database, so an unassigned role answers as if it does not exist rather than confirming that somebody else's role exists.
- Owner-only screens are owner-only at every address. Slate serves its static files from the site root, which means each screen's document has a second raw address. Those addresses are mapped back to the guarded routes. This gap has been found and closed more than once, and there are tests that hold both addresses to the same rule.
The audit log
Consequential actions are recorded with who did them and when: stage decisions, screening runs, role changes, membership and grant changes. The log is visible to the workspace owner and is not editable from the product.
Backups, including what is not done yet
Slate has a backup tool that takes a consistent snapshot of the database, verifies that the copy is readable and complete, and rotates old ones. It exists because a plain file copy of a database in write-ahead-logging mode can pass an integrity check and contain zero rows, which is a failure mode you discover at exactly the wrong moment.
What is not finished: as of the date above, the scheduled timer that runs that tool automatically, and the off-box mirror that puts a copy on different hardware, are not yet installed on the production server. This page will say so until they are. We would rather you knew that than read a sentence about “regular encrypted backups” that is technically arguable.
What Slate stores, and what it does not
Stored: the candidate records your Collector sent, the screening verdicts and their rationale, your roles and playbooks, your spend and daily view ledger, your workspace members and their grants, the audit log, and your account's own sign-in credentials as a one-way hash.
Not stored: your LinkedIn credentials, your LinkedIn session cookie, or your payment card details. Slate also does not harvest email addresses from LinkedIn: contact details exist in a workspace only when you turn on enrichment, in which case they come from a named provider under that provider's terms and Slate records where each value came from.
Sub-processors
Slate uses a small number of third parties, each for one job:
- Hetzner — the server and its disk.
- Anthropic — the model calls that screen candidates. Screening prompts contain candidate profile text.
- Resend — transactional and recruiting email, where you have enabled it.
- Google — sign-in, only for workspaces that use it.
- Your selected enrichment provider — only when you enable enrichment, and only for the contacts you ask about.
Slate does not sell data to anyone and does not use your workspace's candidate data to train any model.
Reporting a vulnerability
Write to [email protected] with enough detail to reproduce the issue. We will acknowledge within three working days and tell you what we found and when we expect to have it fixed. Please do not run automated scanning against the production service, and please do not access an account that is not yours; if a proof of concept needs an account, ask and we will make you one.
Slate is a small company with no bug-bounty budget. We will credit you if you would like us to.