Helm network behavior: every request the app can make

Applies to: AINumbers Helm (browser app + helmd engine)
Purpose: a complete inventory for egress firewalls and proxy allowlists
Last reviewed: 2026-07-24

Helm's default posture is zero egress. Almost every request below is either same-origin, a user-initiated OAuth flow, or a single-purpose call to a named external host. The one exception is a passive, default-on version-check poll, itemized in full in §2. There is no telemetry, no analytics beacon, no crash reporting, and no request anywhere on this page ever carries document content, file contents, or account data.

1. Hosted origins Helm itself talks to

Host	Purpose	Traffic shape
`ainumbers.co`	Serves the static Helm browser app and the daemon-served UI mirror. No API calls; static asset loads only.	Plain HTTPS GET, static HTML/CSS/JS/font assets.
`anchor.ainumbers.co`	Anchor relay: forwards a content hash to third-party timestamp services (RFC 3161 TSAs, OpenTimestamps calendar servers) on Helm's behalf, because browsers cannot reach those services directly (no CORS). The relay never sees anything but a hash; it is untrusted, and the client independently verifies the returned proof against its own hash.	Plain HTTPS POST, JSON in/out, no websockets or SSE. Triggered only when a user runs a workflow with anchoring enabled, or requests anchoring explicitly.
`fonts.googleapis.com` / `fonts.gstatic.com`	Google Fonts stylesheet and font files (site-wide convention, CONTRACT.md).	Plain HTTPS GET on page load, standard web-font request.

2. helmd engine (optional, local daemon)

When installed, helmd listens on 127.0.0.1 only. It never binds a non-loopback interface. Most requests between the browser UI and helmd are same-machine loopback traffic, not internet egress. The one exception is the version-check row below, which helmd relays outward on the UI's behalf:

Endpoint: http://127.0.0.1:<port>/* (REST + Server-Sent Events). Trigger: any UI action once paired. Auth: every call carries the single-use pairing bearer token; every request is checked for exact Host and Origin match (rebind and CSRF defense).
Endpoint: http://127.0.0.1:<port>/version. Trigger: handoff/detection probe, only on explicit user click, never on page load. Payload: capability/version JSON, no user data.
Version-check poll, on by default: the UI calls its own daemon at loopback GET /version-check once on boot and then every hour (ui/app.mjs, checkSkew() plus an hourly setInterval). helmd then makes one real outbound request, GET https://ainumbers.co/helm/version.json: a bare GET, no request body, no identifiers, no telemetry. The response is a static version-notice JSON used only to show a passive "an update exists" banner; nothing is downloaded or applied automatically. Like any HTTP request, it necessarily reveals the caller's IP address and User-Agent to the server it's sent to. Running helmd doctor triggers the same call once, separately. To disable it, set "versionCheckUrl": "" in ~/.helm/config.json (any falsy value works); helmd then reports the check as disabled and makes no outbound call at all. This is normal update-check behavior, the same category of request VS Code, npm, Homebrew, and Docker Desktop all make by default; it is not telemetry and carries no data about the user or their work.

3. OAuth connector flows (only the connectors a user explicitly connects)

Helm never talks to a connector's API until a user clicks "Connect" for that specific provider and completes its consent screen. Each flow is standard OAuth 2.0 + PKCE (RFC 8252 loopback for helmd; SPA flow for the browser app).

Provider	Endpoints	Scope discipline
Microsoft (Graph)	`login.microsoftonline.com/` (authorize/token), `graph.microsoft.com/` (API calls after consent)	Browser = SPA client, 24-hour refresh-token cap (re-auth prompt, no silent long-lived token). helmd = native/public client, longer-lived RTs via loopback PKCE.
Google (Drive)	`accounts.google.com/` (authorize/token), `www.googleapis.com/drive/v3/` (Picker-selected files only)	`drive.file` scope only, not `drive.readonly`: Helm can only ever see files the user explicitly picked via the Google Picker, never a folder- or account-wide listing.
GitHub	`github.com/login/oauth/` (authorize/token), `api.github.com/` (API calls after consent)	Browser = fine-grained personal access token, pasted in by the user (no OAuth redirect needed). helmd = OAuth app flow.
Any connector defined by a workflow manifest	Only the exact `(host, method)` pairs listed in that connector's egress allowlist	Default-deny: a call to any host/method not on the manifest's allowlist is rejected before the network request is made, and every allow/block decision is written to the append-only journal.

A dedicated, fragment-free /oauth/callback.html page receives the authorization redirect and immediately scrubs the token from browser history (history.replaceState) before any other script runs.

4. Anchoring, hash-only itemization

When a workflow run requests an anchored timestamp, exactly one value leaves the machine: a SHA-256 content hash (or a Merkle root over a batch of hashes). No inputs, outputs, file contents, or account data are ever included in an anchor submission.

The hash is POSTed to anchor.ainumbers.co (the shipped Anchor Suite relay).
The relay forwards it to one or more of: an RFC 3161 Time-Stamp Authority, or the OpenTimestamps calendar servers (a.pool.opentimestamps.org, b.pool.opentimestamps.org, alice.btc.calendar.opentimestamps.org).
The signed proof comes back through the relay to the client, which independently verifies it against the hash it already computed locally. The relay is never trusted; it is a CORS-bridging courier only.

5. What Helm never does

helmd makes exactly one kind of unsolicited outbound call: the version-check poll in §2, on by default and fully documented above, including how to turn it off. Outside of that one endpoint, there is no other background polling, heartbeat, or "phone home."
No analytics, telemetry, or crash-reporting beacon in either the browser app or helmd. The version-check request carries no user data, session data, or identifiers of any kind, only a bare GET.
No egress to any host not itemized above or explicitly allowlisted by a connector manifest the user installed.
No cross-origin fetch is attempted automatically: the handoff/detection probe from ainumbers.co to 127.0.0.1 only ever fires after an explicit click, is wrapped by the browser's own Local Network Access permission prompt, and a denial simply keeps the session in browser-only mode. Nothing is retried silently.

Fully offline / relay-blocked mode: with all egress blocked, including anchor.ainumbers.co, Helm's run-to-evidence loop still completes end to end: the kernel executes locally, the evidence bundle is produced and signed locally, and the anchor step is recorded with an explicit queued/skipped marker in the bundle rather than silently omitted or faked. Anchoring can be completed later, or the bundle can be shared and verified as-is, offline, via the verifier embedded in the bundle itself.

Questions about a specific host, port, or payload shape not covered here: security@postoaklabs.com.