Security and privacy

Cusp is local-first. The agent runtime runs on your machine, and your code and session history stay there unless you use a cloud feature. Model requests go to the provider you chose: directly with your own keys, or through Cusp's managed gateway when you use Cusp models. Cusp needs an account, so the app also talks to Cusp's servers to sign you in.

What runs whereCopy Anchor Link

Your code and session history stay on your machine unless you use a cloud feature such as sync or artifacts. The Privacy Policy lists exactly what reaches Cusp's servers.

What leaves your machineCopy Anchor Link

• Model requests. To do its work, the agent sends the model your prompts, the instructions it loaded, and the content of files and command output it read. These go directly from the daemon to the provider you chose, under that provider's data policy. Choose a provider whose retention and training terms suit your code. A local model through Ollama or LM Studio keeps everything on your machine.
• Tool traffic. WebFetch and WebSearch make requests to the sites and search service involved. MCP servers receive what the agent sends them. Shell commands do whatever they do; use the sandbox to limit them.
• Update checks, when you choose Check for Updates… in the desktop app.

TelemetryCopy Anchor Link

Crash reports and usage metrics are off by default. Cusp asks once, and you can change your choice in Settings → Privacy. DO_NOT_TRACK=1 or CUSP_TELEMETRY=off turns both off regardless. Reports are scrubbed of paths, secrets and code on your machine and again on the server, aren't linked to your account, and are kept for up to 90 days. There is no third-party analytics. Details: Privacy Policy.

Keys and secretsCopy Anchor Link

• Desktop app: provider keys are stored in the OS credential store (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux). Cusp's database holds only a reference. Key values are never logged or included in error messages.
• CLI: keys come from environment variables, or from an apiKeyHelper command in settings for keys that rotate.
• Shell commands run with secrets stripped from their environment, so a command the agent runs doesn't inherit your provider keys.
• MCP configuration can reference secrets as ${VAR}. Expanded values are never shown to the model.
• Cloud (coming soon): keys stored in the cloud are encrypted with envelope encryption under a managed key.

The local daemonCopy Anchor Link

• Binds 127.0.0.1 only. Listening on any other interface requires an explicit flag intended for cloud sandboxes.
• Uses a random port and a new bearer token on every launch. Every request needs the token. The address and token are written to a discovery file only you can read, so the CLI and editor extensions can find the daemon.
• Accepts browser requests only from allowed origins (the desktop app's own), checked on both HTTP and WebSocket connections.
• The desktop app never writes the token to disk or logs.
• Hooks, MCP servers and shell commands don't inherit the token.

For the full picture of trust boundaries and controls, see Security model.

Safeguards around the agentCopy Anchor Link

Every check fails closed. A sandbox that can't be applied, a classifier that's unavailable, or a hook that can't be reached results in a prompt or a denial, never a silent allow.

Prompt injectionCopy Anchor Link

Text the agent reads (web pages, issues, files from dependencies) can contain instructions aimed at the agent. Cusp's design assumes this will happen:

• Content from tools is data. It doesn't carry your authority.
• Messages from other agents arrive as information, not as instructions from you, and can't grant permissions.
• The permission engine, protected paths and sandbox apply no matter what the model was persuaded to try.

Treat a repository you don't trust the way you'd treat running its code: review its .cusp/ and .claude/ folders, hooks and MCP servers before trusting the workspace.

Desktop app hardeningCopy Anchor Link

• Loads only its bundled interface; no remote content.
• A strict content security policy limits the UI to itself and the loopback daemon.
• All calls from the UI to the native shell pass through an isolation layer with an explicit allowlist.
• Signed and notarized on macOS, signed on Windows. Updates are signature-checked against a key compiled into the app.

Data on diskCopy Anchor Link

The data directory is ~/.cusp for the CLI and ~/Library/Application Support/run.cusp.desktop/daemon for the desktop app on macOS. Delete it to remove all local session history.

Reporting a vulnerabilityCopy Anchor Link

Please report security issues privately to security@cusp.run rather than in a public issue. Our vulnerability disclosure policy explains what is in scope, our response times and our safe-harbour commitment.