Skip to main content

Security & Sovereignty

This page explains where your data lives, what can ever leave your machine, and how SLAW handles keys and secrets — so you can judge the security posture before you adopt it.

SLAW is built local-first: you self-host it, your data sits in storage you control, and nothing about your squads' work is sent anywhere unless you deploy a component that does so explicitly. The sections below say plainly what is local, what is optional, and what is configurable.

Local-first by default​

A default install is a single Node.js process that manages an embedded PostgreSQL database and local file storage on your own machine. There is no SLAW account and no hosted backend in the loop. For production you point SLAW at your own Postgres and deploy it however you like — the deployment stays yours end to end.

Because of this model, your issue content, agent prompts, work products, and audit history live in your database and your file storage. Adopting SLAW does not move that data into a vendor's cloud.

What can leave the machine​

Two paths can send data outbound. Each is either initiated by you or strictly limited in scope.

  • Your agents calling their model providers. When an agent runs, it sends prompts to whatever model provider you configured for it (for example Anthropic, OpenAI, or a local runtime). That traffic goes from your machine to the provider you chose — SLAW does not proxy it. Choosing a fully local runtime keeps even this on your machine.
  • An optional fleet control tower (Botfather). If — and only if — you enroll an instance with SLAW Botfather, that instance reports operational metadata (which squads exist, issues in flight, and token/cost rollups) outbound to the tower you run. Each instance stays fully local and sovereign; the tower gets visibility, not control, and never reaches inbound into an instance.
note

If you never enroll with a control tower, the only data leaving your machine is the model-provider traffic your own agents generate.

Keys and secrets​

SLAW separates the secrets agents need from the prompts agents see.

  • Encrypted local storage. Instance-level and squad-level secrets are stored encrypted in your local storage, alongside provider-backed object storage for attachments and work products.
  • Secrets stay out of prompts. Sensitive values are not injected into an agent's context unless a scoped run explicitly needs them — secrets are not pasted into every prompt by default.
  • Scoped, short-lived credentials. Agents authenticate with their own API keys, and heartbeat runs use short-lived run JWTs rather than long-lived shared credentials. Every mutating request is traced to a specific actor in the audit log.

Deployment modes and access​

SLAW ships with two deployment modes so you can match exposure to your environment:

  • Trusted local (loopback). The default fast path after npx slaw onboard --yes — bound to local loopback for a single operator on one machine.

  • Authenticated / private. Start in authenticated mode by choosing a bind preset explicitly, for example:

    npx slaw onboard --yes --bind lan
    # or, for remote-but-private access over a private network:
    npx slaw onboard --yes --bind tailnet

In authenticated mode SLAW runs as a shared control plane with real human identities, squad memberships, and squad-scoped access controls. For remote access without exposing a public port, see private access over Tailscale. The full matrix is in Deployment modes.

Reporting a vulnerability​

Report security vulnerabilities privately through GitHub's Security Advisory feature at the SLAW repository. Please do not open public issues for security reports. SLAW has shipped coordinated security fixes this way — for example, the authorization hardening in v2026.414.0 (GHSA-68qg-g8mg-6pr7).

Next steps​