Skip to content

Security Model

Sarma Linux edited this page Jun 4, 2026 · 3 revisions

Security model

slipstream runs entirely on your machine. There is no account, no telemetry, no remote service. This page is honest about what that means and what it does not.

What runs and where

  • The helper and the MCP server are local Node processes Claude Code spawns. They read your project and write under .claude/slipstream/. They make no network calls.
  • The dashboard server binds 127.0.0.1 on a free port (src/dashboard/server.ts). It is reachable only from your machine. There is no 0.0.0.0 bind and no auth, because the threat model is a local-only loopback service, not an exposed one. If you forward the port or run in a shared environment, that assumption changes; do not.

Secret redaction

The dashboard activity stream can carry tool inputs, and a tool input can contain a token or a connection string. Even though the stream is local, you might screen-share the dashboard, so slipstream redacts before an event ever reaches disk (redactSecrets in src/dashboard/events.ts). The patterns it masks:

  • Bearer tokens and authorization headers.
  • Common provider key prefixes: sk_, pk_, rk_, ghp_, github_pat_, xoxb, and others.
  • AWS access key ids (AKIA...).
  • KEY=, TOKEN=, SECRET=, PASSWORD= style assignments.
  • Connection strings with inline credentials (scheme://user:pass@host).
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#0d1117','primaryTextColor':'#f5f7fa','primaryBorderColor':'#38bdf8','lineColor':'#22d3ee','fontFamily':'monospace'}}}%%
flowchart LR
  Hook[hook reads tool input] --> Make[makeEvent]
  Make --> Redact[redactSecrets + redactData]
  Redact --> Disk[(append-only log)]
  Disk --> UI[dashboard]
Loading

makeEvent is the only way to construct an event, and it always redacts, so a caller cannot accidentally skip it. This is blunt by design. It masks things that are not secrets before it lets a real one through, which is the safe direction. Do not treat it as a vault; it is a screen-share guard.

What slipstream never does

  • It never sends your code, prompts or memories anywhere. If it phoned home it would not be slipstream.
  • It never executes a skill's verification command for you; the agent runs gates, and you see them.
  • Everything is written under your project only, all under .claude/slipstream/: the PreCompact digest and the memory store, the auto-captured observations, the budget.json control and the savings.json optimization tally. Add .claude/slipstream/ to .gitignore to keep them off the remote (slipstream's own .gitignore already does, anywhere in the tree), or commit memory/ deliberately if you want to share durable facts with your team.
  • Observations are derived from the dashboard event log, which is already redacted, so the same masking covers the observation memory — a secret never reaches an observation either. The optimization tally records only byte counts, never content.

sp-reviewer's secret scan

The sp-reviewer subagent (Subagents) greps the diff for the same leak shapes before a push and fails the review if it finds one committed to the tree. That is a pre-push guardrail, not a substitute for a real secret scanner in CI.

Supabase RLS

The sp-schema subagent and the supabase-rls skill default to deny: a table with RLS enabled and no policy denies all access. That is the safe starting point slipstream encourages for any table holding user data.

See also


SarmaLinux . sarmalinux.com . Repository

Clone this wiki locally