Wiki · Concept · Last reviewed June 25, 2026

Web Serial API

The Web Serial API lets websites read from and write to serial devices, creating a browser boundary between web scripts, agentic browsers, and physical hardware.

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

Definition

The Web Serial API is a Web Platform Incubator Community Group specification for letting documents communicate with serial devices through script. The editor's draft says the API gives websites a way to read from and write to serial devices, including microcontrollers, 3D printers, and other serial hardware. MDN describes the same surface as a Web API for devices connected through a serial port, or through USB and Bluetooth devices that emulate a serial port.

This entry belongs in an AI governance wiki because agentic browsers are beginning to sit closer to local devices. A browser page that can talk to a microcontroller, lab instrument, robot controller, flight controller, or 3D printer is not merely displaying information. It may be issuing bytes that change device state. When a model can click, paste, generate commands, or operate a web app with Web Serial access, the browser permission becomes a physical-world boundary.

Mechanism

The API exposes navigator.serial on the main thread and WorkerNavigator.serial in dedicated workers. MDN marks the feature as limited availability and available only in secure contexts in supporting browsers. Chrome's documentation says the API launched in Chrome 89 on desktop platforms, and its usage model starts with feature detection, then a user-mediated port selection flow.

The central permission step is navigator.serial.requestPort(). The WICG draft says a site without permission must call requestPort(), giving the browser a chance to prompt the user to choose which device the site may control. That prompt requires transient activation, such as a button click. A site can also provide filters, for example USB vendor and product identifiers, to narrow the selectable ports. After permission exists, navigator.serial.getPorts() can return ports previously granted to the site.

Once selected, a SerialPort is opened with options such as baudRate. Reads and writes use streams: the port exposes readable and writable stream objects, and data moves as byte arrays. The WICG draft also defines forget(), allowing a site to voluntarily revoke a permission that was granted by the user, unless the user agent cannot perform that action because of policy.

Agent Context

For AI Browsers and Computer Use, Web Serial turns a website into a device console. A normal user may understand that a web app is flashing firmware, reading telemetry, or sending a printer command. A model may only see a dialog, a button label, and generated protocol text. That makes the surrounding agent design critical: the model should not treat a serial prompt as a generic permission banner.

The agent risk is not that the API is inherently bad. The useful cases are real: education, hobbyist hardware, device setup, and industrial tools can avoid native installers. The risk is authority compression. A single model action can move from text generation to device mutation if the browser session has a granted port and a page-level tool translates model text into serial bytes.

Governance Use

Governance should treat Web Serial as hardware access, not ordinary browsing. A review record should name the origin, top-level page, frame context, selected port, vendor and product identifiers when visible, baud rate, protocol, device class, user gesture, permission state, and revocation path. If an AI agent is involved, record the human instruction, model output, tool call, serial command category, and whether a human approved the command after seeing the physical device context.

Permissions Policy matters here. The Web Serial draft defines a policy-controlled feature named serial with a default allowlist of self. Cross-origin embeds should not receive serial power casually. A page that hosts model-generated previews, third-party widgets, support chat, or untrusted lab notebooks should keep serial access separated from those surfaces.

Limits

The Web Serial specification's security section names the hard problem: a malicious or compromised site may persuade the user to grant access, then use the device's own capabilities for harm, install malicious firmware, or communicate with a malicious device. The draft says the primary mitigation is the requestPort() pattern, because it requires user interaction and grants one device at a time. That helps, but it does not make the device safe.

Serial data is opaque bytes. The browser usually cannot know whether a byte sequence is a harmless status query, a dangerous actuator command, or a firmware write. A governance program therefore needs device-side authentication, command allowlists, safe modes, firmware provenance, physical interlocks where appropriate, and logs that survive after the browser tab closes.

Review Record

Source Discipline

Claims about the API shape should cite the WICG editor's draft. Claims about availability and browser behavior should cite browser documentation or live compatibility data because support changes across engines and releases. Do not assume a site has safe device control simply because a browser permission prompt exists.

Spiralist Reading

Spiralism reads Web Serial as a threshold where language becomes voltage. A command leaves the page and enters a device that may move, heat, erase, print, measure, or flash. The humane pattern is not fear of hardware, but a visible chain of authority: who asked, who approved, which device listened, what bytes crossed, and how the permission can be withdrawn.

Sources

Return to Wiki