SlateDocs
Docs Tour Changelog Download
Privacy & trust

Security details

Protections around Slate's local server, the files it writes and your databases, and what it does not do. To report a vulnerability, see Privacy & Security.

Contents#

Keys and tool configs#

No API keys. Model providers are the agent CLIs (any of the 16) you already signed in to.

Nothing is written into another tool's config until you connect one.

  • Most tools: Slate edits the tool's MCP config and, where the tool takes hooks, installs recall hooks beside it.
  • Claude Code and Codex: Slate runs the tool's own plugin install, then removes its own MCP entry once the plugin supplies the server, so nothing is listed twice.
  • Connect one tool yourself, from setup's Connect step or Connect → Agents. Then Slate keeps tools you install later registered too.
  • Launch auto-connect never reaches Claude Desktop: it gets Slate when you turn Claude Code on and keeps it when you turn Claude Code off.
  • Until you connect a tool, auto-connect is off and no file outside Slate's data directory is touched. Turning it off removes what Slate put there and stays off across restarts.

Every write copies the original aside first. Slate keeps the five newest copies of each file it rewrote and sweeps the rest at launch. Only its own go: a <file>.bak or <file>.bak-20260101-120000 you made stays.

Sign-in never touches the renderer. Cloud sign-in opens your system browser and returns to a loopback address on Slate's server, which does the code exchange. No code, token or password passes through the UI. The session lands in a 0600 file outside the database.

The local server#

The workspace port only answers the app. The server listens on loopback. A web page you visit can POST to a localhost port (CORS only stops it reading the reply), so the server refuses any request whose Origin is not Slate's webview and any request to a non-loopback hostname (DNS rebinding). Origin proves nothing about a non-browser program, so every request also presents a token minted each run into a 0600 file (slate-server-token) in the app-data folder, never in a folder you moved the workspace to. The app window gets it from Slate; another process only by reading that file, which only your user can.

Three cases carry no header: a CORS preflight from the app window (runs nothing), the live event stream (cannot set headers, so the token is in its address), and the two sign-in redirect landings (cloud account, work gateway). Each acts only on a sign-in Slate started, once.

The auto-capture port is authenticated. With auto-capture on, a loopback port lets git hooks and shell scripts push a note into Memory. The server rejects requests that do not look like local tooling (which stops a browser), and anything that writes must present the server token (which stops other processes, since only your account reads the file). Captured notes are ranked by recall and can reach later AI sessions, hence the guard. To drive it yourself, send the token as an x-slate-token header, read from slate-server-token. One port and one token per machine.

Validated tool arguments. Every MCP argument is checked against a Zod schema first. A wrong or missing type is rejected, nothing is coerced, an undeclared argument is dropped.

Workspace isolation#

Each workspace stays in its own file and Slate refuses to mix them.

  • A server request must name its workspace; one that does not is refused, not filed into Personal.
  • Slate's own code cannot open a workspace file without naming it.
  • An agent session works in the workspace of the first folder it names and is refused another workspace's folder.
  • Each file records its workspace, so a misplaced file does not open as another workspace.
  • Sessions shows every workspace at once, and so does the live_sessions tool: an agent in any workspace sees every running session, with its title, last reply, goal and folder. recall with scope: "workspaces", and get_doc on a doc shared with you, read the cloud copy of every workspace you belong to. Nothing else crosses workspaces.
  • A test plants a marker in one workspace and asks every part of the server and every agent read for it from another. It must never come back.

Encryption and the webview#

Slate encrypts nothing at rest. workspace.db, shared workspace files, machine.db and their WAL sidecars are unencrypted. Confidentiality rests on your OS's full-disk encryption (FileVault, BitLocker, LUKS) and file permissions. There is no SQLCipher build, key or passphrase. Anyone with the decrypted volume and your user's read access can read every workspace. If you need application-level encryption at rest, Slate does not meet that today. The cloud session and work gateway sign-in files are unencrypted too, but 0600 and outside every database.

Webview CSP. The Tauri webview runs under an enforced Content Security Policy, so the renderer cannot reach arbitrary network origins.

Writes, backups and restore#

  • Transactions. Every change is a SQLite transaction; WAL mode lets reads continue during writes.
  • Backups. Slate copies a database aside before any schema migration and keeps the last three per store. Leaving or deleting a workspace forever also keeps a copy.
  • Restore. Settings → Workspaces → (the workspace) → Storage → Restore a backup lists them. It applies at the next launch, and the workspace it replaces is kept too. If a connected agent still has the workspace open, the restore is refused; quit those tools and retry.

Managed Macs#

For IT teams that deploy Slate with an MDM (Jamf, Kandji, Intune and others).

  • Start at login is a managed preference. Push a configuration profile for the domain app.slate.workspace with the key StartAtLogin, a boolean. true starts Slate at login on every Mac and false keeps it off. Slate reads the key only when the profile forces it. The switch in Automations › Built-in then shows your answer, says Managed by your organization and cannot be changed, and Slate never asks the person.
  • What the login item is. An SMAppService agent registered by the signed app, from a plist inside the bundle (Contents/Library/LaunchAgents/app.slate.workspace.login.plist). Slate writes nothing to ~/Library/LaunchAgents. The item shows under Slate's name in System Settings → Login Items. A Login Items profile (com.apple.servicemanagement) can allow it with a Label rule for app.slate.workspace.login or a BundleIdentifier rule for app.slate.workspace, so the person is not asked to approve it. Slate is signed with its own certificate, not an Apple Developer ID, so there is no team identifier to match.
  • What runs at login. The app with no window, its menu bar icon and its local server, so agents can reach Slate's MCP server. A signed-out Slate opens its window to ask for sign-in.

Last updated

Esc