Helm network behavior: every request the app can make

Applies to: AINumbers Helm (browser app + helmd engine)
Purpose: a complete, reviewable inventory for network-security teams, egress firewalls, and proxy allowlists, not a marketing summary
Last reviewed: 2026-07-23

Helm's default posture is zero egress. Nothing on this page happens unless a user takes the specific action that triggers it, and every request below is either same-origin, a user-initiated OAuth flow, or a single-purpose call to a named external host. There is no telemetry, no analytics beacon, and no background polling of any kind.

1. Hosted origins Helm itself talks to

HostPurposeTraffic shape
ainumbers.coServes 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.coAnchor 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.comGoogle 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. All requests between the browser UI and helmd are same-machine loopback traffic, not internet egress:

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).

ProviderEndpointsScope 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.
GitHubgithub.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 manifestOnly the exact (host, method) pairs listed in that connector's egress allowlistDefault-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.

  1. The hash is POSTed to anchor.ainumbers.co (the shipped Anchor Suite relay).
  2. 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).
  3. 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

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: [email protected].