Local Network Access (LNA) admin one-pager

Audience: IT/security admins managing Chrome or Edge via policy
Applies to: the optional cross-origin handoff from the Helm browser app at ainumbers.co to the local helmd engine
Last reviewed: 2026-07-23

What Local Network Access is

Local Network Access (LNA) is a Chromium security feature that blocks a public web page from silently reaching addresses on a user's local network, including 127.0.0.1 (loopback), unless the page has been explicitly granted permission. It closes a class of attacks where a malicious site probes or attacks devices and services on a private network the visitor's browser can reach but the site's own server cannot.

Why Helm asks for it

Helm's primary architecture keeps the browser app and the optional local engine (helmd) on separate origins by design: the app runs at ainumbers.co, and the engine listens only on 127.0.0.1. Most of Helm's functionality (kernels, evidence bundles, offline verification) needs no local engine at all and works with zero LNA involvement.

For the subset of features that benefit from the local engine, primarily durable storage, OS-keychain-backed credentials, and connectors that CORS blocks in a browser, Helm's primary path is a same-origin handoff: the page navigates the user to http://127.0.0.1:<port>/#token=…, which the browser treats as a same-origin destination, not a cross-origin fetch. This path needs no LNA permission at all and works in every major browser, including Safari.

An optional enhancement exists for Chrome and Firefox: a detection probe from the hosted page directly to 127.0.0.1, used only to show connection status without navigating away. This probe only fires after an explicit user click (never on page load), and it is exactly the kind of cross-origin-to-loopback request LNA governs. A denied LNA prompt is a clean no-op: Helm falls back to the same-origin handoff path with no broken functionality.

What to allow, and what not to

Scenario	LNA involvement
Browser-only Helm (kernels, evidence bundles, Verify)	None. No local network access requested at any point.
Same-origin handoff to `helmd`	None. Top-level navigation to a same-origin page, not a cross-origin request LNA mediates.
Optional status-detection probe (Chrome/Firefox enhancement)	LNA-gated. Prompts the user unless pre-authorized by managed policy below. Denial degrades gracefully.

Paste-ready managed policy (Chrome/Edge)

To pre-authorize the optional detection probe for managed fleets so users are not prompted, deploy the LocalNetworkAccessAllowedForUrls enterprise policy scoped to the Helm origin only:

{
  "LocalNetworkAccessAllowedForUrls": [
    "https://ainumbers.co"
  ]
}

Reference (Windows Group Policy / ADMX): set under Software\Policies\Google\Chrome (Chrome) or Software\Policies\Microsoft\Edge (Edge) as LocalNetworkAccessAllowedForUrls, a list-type policy, with the single origin above. Via chrome://policy-compatible JSON policy management (Chrome Browser Cloud Management, Intune ADMX ingestion, or a local Local State/Preferences deployment), set the same key with the same value.

This policy authorizes only the ability to ask 127.0.0.1 whether helmd is running and reachable; it does not grant Helm any additional capability, does not bypass the loopback API's own Host/Origin/bearer-token checks, and does not affect any other site. Deploying it is optional: Helm functions fully without it, using the same-origin handoff path instead.

Questions about scoping this policy alongside other enterprise controls: [email protected].