/* security posture · last reviewed 2026-05-13 */

Local-first by design. Three documented network calls. MIT.

Sverklo indexes code on your machine, stores the index on your machine, and never sends code, queries, file paths, or symbol names anywhere. The only network calls are: model download on first run (one fixed URL), opt-in telemetry (9 documented fields, off by default), and an explicit user-initiated update check. Audit the source — it's MIT, reproducible from clone.

Why local-first matters now

Between April and May 2026, multiple high-profile MCP supply-chain disclosures landed: command-injection vectors in popular MCP servers, registry poisoning probes succeeding against 9 of 11 registries tested, and ~200K vulnerable MCP instances identified across the ecosystem. Industry guidance shifted to "stick to vendor-maintained or AAIF reference servers."

Sverklo's posture didn't change because it never had a network surface to harden. The threat model is shaped by what's not in the architecture:

0
network calls for indexing, search, memory, or any tool execution
0
API keys, auth tokens, or cloud accounts required
MIT
licensed source — audit, fork, vendor as you please

The disclosure cycle has kept compounding through May 2026:

Sverklo's attack surface against this cycle: no remote endpoint (nothing to authenticate, nothing to hijack), no protocol-revision risk (we don't expose a network protocol — sverklo runs over stdio inside the user's MCP client process), no outbound except the three documented calls in the table below. CVE-2026-33032-class issues categorically don't apply because there is no listening service to expose.

The three network calls, in full

EndpointWhen · what's sent
onnx model
(one URL)
Once, on first run. Downloads the 86 MB ONNX embedding model from a fixed sverklo CDN URL to ~/.sverklo/models/model.onnx. Subsequent runs use the cached file. No telemetry attached to this fetch. SHA-256 verified at install time.
t.sverklo.com
(opt-in only)
Only if the user runs sverklo telemetry enable. Sends the 9 fields documented in TELEMETRY.md: install_id (UUID), version, os, node_major, event type, tool name (or null), outcome (ok/error/timeout), duration_ms. No queries, code, file paths, symbol names, IP addresses, hostnames, usernames, project names, git SHAs, branches, repo URLs, error messages, or stack traces. Mirrored to ~/.sverklo/telemetry.log before the network call so you can audit exactly what left.
api.github.com
(explicit only)
Only when the user runs sverklo --check-update or equivalent. Fetches the latest release tag for version comparison. No data sent beyond the standard HTTP request.

Everything else stays on your machine: the SQLite index, the memory journal, the embeddings, the chunk store, the symbol graph. Sverklo has nothing remote to authenticate to because there is nothing remote.

Reporting a vulnerability

Do not file public GitHub issues for security vulnerabilities. Email security@sverklo.com with a description, reproduction steps, the affected version (sverklo --version), and your impact assessment. We aim to acknowledge within 3 business days and ship a fix or mitigation within 14 days for confirmed high-severity issues. PGP available on request.

In-scope

Out of scope

Full policy + coordinated disclosure timeline: SECURITY.md.

What you can audit, today

The honest version of "no telemetry by default": sverklo prints a one-line prompt asking once whether you'd like to opt in. If you skip or say no, nothing happens — no network call, no buffered events, no later retries. The opt-in is a sentinel file at ~/.sverklo/telemetry.enabled; the override is a sentinel file at ~/.sverklo/telemetry.disabled. The disabled file always wins.