Exactly two commands call out.

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.

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 assignments, invitations, join requests, verified domains, order and invoice references, sign-in sessions, and the append-only audit log of licensing actions (issued, revoked, reassigned, downloaded), which records the IP address of each sign-in and invitation acceptance, and the IP address and browser of each license download or token reveal. Paddle, our merchant of record, holds full card numbers and does not send them to us. The privacy policy describes this data, and the list of third parties we use says who else receives it and why.

What the portal cannot see: 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 skarn check, a license file, in by any offline means. Nothing in the scan path ever attempts a connection. See air-gapped licensing.

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.