Wiki · Concept · Last reviewed June 25, 2026

Local Network Access

Local Network Access is a web-platform proposal for requiring user permission before a website reaches local network or loopback destinations through the user's browser.

Category: Concept Updated: June 25, 2026 Tags: browser security, local network, agents, permissions

Definition

Local Network Access, or LNA, is a WICG web-platform proposal meant to stop public websites from silently reaching devices and services on a user's local network. The specification frames the problem plainly: public websites can make requests to local devices and servers, including routers and software interfaces on the user's own machine. LNA changes that default by requiring the user to grant permission before those requests proceed.

The proposal follows Chrome's paused Private Network Access work, but it uses a permission gate rather than making local devices opt in through CORS preflight headers. Chrome's developer documentation says the goal is to reduce cross-site request forgery attacks against local devices and to reduce local-network fingerprinting. MDN describes the same technology as a set of local network restrictions backed by permission prompts and Permissions-Policy directives.

Mechanism

LNA divides request targets into address spaces. MDN names three broad categories: local addresses, such as private network addresses reachable only on the current network; loopback addresses, such as 127.0.0.1 or localhost, reachable only on the user's device; and public addresses, reachable from the wider internet. Chrome's documentation treats a local network request, for its first milestone, as a request from the public network to a local network or loopback destination.

In supporting browsers, local and loopback requests are gated behind separate permissions named local-network and loopback-network. MDN also records a backwards-compatible local-network-access alias. The permissions are restricted to secure contexts, and document-level delegation can be controlled through Permissions Policy directives and iframe allow attributes.

LNA is not just a new name for Cross-Origin Resource Sharing. CORS governs when scripts can read cross-origin responses. LNA addresses cases where the request itself is the danger, even if the attacking page never reads the response. A malicious public page may only need to send a state-changing request to a router, printer, intranet tool, or local development server.

Agent Context

For AI Browsers and Computer Use, Local Network Access is a boundary around a model's borrowed browser reach. A browser agent may be asked to diagnose a printer, configure a home device, connect to a local media server, call a development API on localhost, or open a corporate intranet panel. Those use cases can be legitimate. They are also exactly the kind of surface where hidden instructions, compromised pages, or careless automation can turn a user's browser into a bridge into private space.

LNA therefore belongs in agent permission design. The model should not experience the prompt as an obstacle to click through automatically. The prompt is evidence that the web page is asking to cross from public content into local authority. An agent runtime should record the origin, target, reason, user confirmation state, and whether the request came from page script, model action, tool output, or a human instruction.

Governance Use

A useful review distinguishes local-network access from ordinary internet egress. For an agentic browser, the risky act is not only "can it reach the web?" but "can a public origin cause it to reach inside the user's network?" Procurement and red-team tests should include router addresses, intranet hosts, loopback services, local development ports, iframe flows, service workers, WebSockets, and mixed-content cases where permission may relax a block.

Organizations should also decide which origins may ask for local access at all. Support portals, device setup tools, enterprise SSO flows, and local companion apps may have a reason. Advertising, analytics, untrusted embeds, and model-generated previews usually do not. The governance record should make that distinction inspectable.

Limits

Local Network Access does not secure the local device. A router with default credentials, an unauthenticated printer panel, or a development server with dangerous endpoints remains weak. LNA reduces drive-by reach from public websites; it does not replace authentication, CSRF tokens, network segmentation, firmware updates, or least-privilege agent tools.

It also depends on implementation. The WICG document is a proposal, MDN describes behavior in supporting browsers, and Chrome's staged rollout has changed over time. Reviewers should name the browser, version, flags or enterprise policy state, platform, request type, and whether the test covered top-level pages, frames, workers, and persistent permissions.

Review Record

Source Discipline

For standards claims, cite the WICG Local Network Access specification. For implementation claims, cite browser documentation and test the exact browser release. Avoid treating the older Private Network Access preflight design as the current Chrome direction without noting that Chrome documentation says Local Network Access replaced that paused effort.

Spiralist Reading

Spiralism reads Local Network Access as a boundary of locality. The user's network is not just another URL space; it is a room full of devices, credentials, habits, and implicit trust. The browser can see both the public street and the private room. LNA asks for a visible threshold before a website steps through. Agent systems should preserve that threshold, not smooth it away.

Sources

Return to Wiki