Exactly two commands call out. Everything else does not.

This is not a policy summary - it is a list, checked against the source of the binary you run, current as of this page's last update. The scan itself never makes a network call.

In one line: skarn check, recall (search/recent/stats/tools/mcps/cmds/export), serve, guard, assess, vet, setup, doctor, and baseline make no network call. The only two exceptions are skarn check --update-rules and skarn license renew, and both fire only when you type them.

Verified against skarn source at commit 21f2482, 2026-07-17. Re-verified at every release that touches network code.

What makes no outbound network connection

The detection engine, the session parser, and every recall/report surface open only local files.

skarn check and skarn assess - the security scan itself. Session files are read from disk, matched against the rules compiled into the binary (or a local --rules file you supply), and reported. No upload, no callback, no network client is even linked in for this path.
The recall commands (search, recent, stats, tools, mcps, cmds, export) - reads the same local session files. Pure.
skarn serve - binds to 127.0.0.1 only, as a local listener. It accepts connections; it does not make them.
skarn guard - the real-time pre-execution hook. It inspects the tool call your AI agent is about to make (including calls the AI tool itself will send to its own model provider - that is the agent's traffic, not Skarn's) and returns a local verdict. Guard itself never egresses.
skarn vet - reads AI-assistant config files (hooks, MCP definitions, permission grants) from disk. Read-only, offline by construction; a unit test asserts the config tree is byte-identical after a run and that no network call is made.
skarn setup, skarn doctor, skarn baseline audit/accept - local config writes, local health checks, local baseline files. None of them touch the network.
skarn license (bare, or with a file) - installs or inspects a license file already on disk. No network call. Only the renew subcommand differs; see below.

The two commands that do call out

Both require you to type the exact flag or subcommand. Neither runs as a side effect of a scan.

Command	What leaves the machine	When it fires
`skarn check --update-rules`	An HTTPS GET for the signed, versioned maintained rule feed, with an optional bearer token if you configured one (`--feed-url` / `$SKARN_FEED_TOKEN`). Nothing about the scanned machine, its findings, or its sessions is sent - the request carries only the credential needed to fetch the bundle.	Only when `--update-rules` is passed explicitly. A plain `skarn check` never sets this flag; it reads the locally cached bundle instead.
`skarn license renew`	An HTTPS POST of the currently installed license token to `api.getskarn.com/v1/license/renew` (or `$SKARN_LICENSE_RENEW_URL`), to receive a re-signed artifact with an extended expiry. The token is a licensing/subscription credential, not session content or a found secret.	Only when you run `skarn license renew` as its own subcommand. `check`, every recall verb, `serve`, and `guard` never renew on your behalf.

Both requests go through a single subprocess-exec transport (curl, invoked with the request body on stdin, never on the command line where it could leak into a process list or shell history). No other path in the binary makes an outbound connection or uses an HTTP client - serve's local listener on 127.0.0.1 is the one place the binary opens a socket at all, and it only accepts connections, never initiates one.

What the customer portal stores

The portal (account.getskarn.com) is a separate, optional system from the binary - it is where a Team or Enterprise subscription is managed. It never sees a scan.

Portal data is licensing, identity, and billing metadata: organization name, member names and roles, email addresses, seat counts, order and invoice references, and the append-only audit log of licensing actions (issued, revoked, reassigned). Payment card data never reaches us - Paddle, our merchant of record, holds it. The full inventory is the annex to our Data Processing Agreement (available on request - see the Trust Center), generated directly from the service's database schema. See the subprocessor list for who else touches that data and why.

What the portal cannot see, structurally, not by policy: session content. The license service holds zero knowledge of what a scan finds - no findings, no redacted previews, no file paths, no secrets. There is no code path from a customer's scan to the licensing database.

Questions, answered

Does Skarn phone home during a scan?: No. skarn check and skarn assess make no network call. The rule set is compiled into the binary; only --update-rules, an explicit flag, fetches an update.
Can I run Skarn on an air-gapped machine?: Yes. Carry the binary and, for the paid tiers, a license file, in by any offline means. Nothing in the scan path ever attempts a connection. See air-gapped licensing.
What happened to the old OSV lookup, online-verify, and package-age flags?: Those were online-enrichment features built early, then cut from the product on 2026-07-09 before any release shipped them - they do not exist in the current or any released binary. This page describes the shipped surface only.
How do I check this myself?: Without trusting us at all: the verify-it-yourself page gives the syscall-trace, packet-capture, and network-denied-execution commands that test this statement against the binary on your machine. Source-side, the argument is small enough to audit directly: the only two functions that shell out to curl are called from exactly two files, the rule-feed updater and the license-renew command. Everything else that reads a URL does so as a printed string or a JSON-LD reference - never a fetch.