Wiki · Concept · Last reviewed June 25, 2026

WebUSB API

The WebUSB API exposes selected USB device services to web pages, creating a browser boundary for agents, peripherals, and physical controls.

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

Definition

The WebUSB API is a Web Platform Incubator Community Group specification for browser access to Universal Serial Bus devices. The specification describes USB as the de-facto standard for wired peripherals and notes that many devices fit standard classes such as keyboards, pointing devices, storage, audio, or video. WebUSB is aimed at a different case: devices with vendor-specific services that otherwise require native drivers or custom desktop software.

MDN summarizes the API as a way to expose non-standard USB-compatible device services to the web, and marks it as limited availability and secure-context only. Chrome's developer documentation says WebUSB has been available in Chrome since version 61. The governance question is not whether every USB device should be controlled by a website. It is what record should exist when a web page, and therefore a browser agent, can enumerate, claim, configure, and transfer data to a local device.

Mechanism

The API is reached through navigator.usb. A page asks for access by calling requestDevice() with filters such as vendorId, productId, classCode, subclassCode, protocolCode, or serialNumber. Chrome's documentation says requestDevice() requires a user gesture. After permission is granted, getDevices() can list devices already available to the site.

WebUSB is more direct than a high-level browser API. The interfaces include USBDevice, USBConfiguration, USBInterface, USBAlternateInterface, USBEndpoint, and transfer result objects. A page may open a device, select a configuration, claim an interface, choose an alternate setting, and perform control, bulk, interrupt, or isochronous transfers. Those steps can be ordinary device setup, but they can also cross into persistent settings or operational state.

Permissions Policy is part of the boundary. MDN says the usb directive controls whether the current document is allowed to use WebUSB, and the default allowlist is self. Cross-origin frames should receive USB access only through deliberate delegation, especially when a page mixes device setup with embedded tools, ads, analytics, support widgets, or model-generated interfaces.

Agent Context

For AI Browsers and Computer Use, WebUSB is a path from language instructions to device-level action. A model could help a user configure a WebUSB-compatible microcontroller, inspect a vendor-specific peripheral, follow a device landing page, or retrieve logs from a diagnostic tool. It could also pick the wrong device, accept a permission prompt without understanding physical context, or generate transfer data that changes state outside the browser.

The risk is not that USB access is unusual. USB is mundane, which is why the boundary matters. The cable can connect to development boards, vendor adapters, diagnostic interfaces, and custom peripherals. Agentic automation around that channel should make the local device visible as an object of authority, not hide it behind a friendly web form.

Governance Use

A governance review should treat WebUSB as hardware authority. Record the top-level origin, frame origin, Permissions Policy, device name, vendor ID, product ID, serial number when exposed, configuration, interface, endpoint, transfer type, user gesture, permission state, and revocation path. If a model is involved, record the prompt, generated transfer data, tool calls, and human confirmation path.

Organizations should separate USB configuration surfaces from untrusted content. A vendor support page, classroom microcontroller lab, factory adapter tool, or diagnostic workflow should not share authority with unrelated scripts, third-party embeds, or unreviewed plugins. If the same browser profile is used by an agent, the review should also ask whether granted USB permissions persist across tasks and whether a later session can reuse access without the same physical context.

Limits

The WICG specification includes a USB blocklist and references protected interface classes. It also describes permission prompts, indicators, and Permissions Policy as protections against unwanted access. Those controls reduce ambient access, but they do not make a browser fluent in every vendor protocol. A transfer can be syntactically valid and still be unsafe for the attached device or environment.

The browser usually cannot know whether a control transfer reads harmless metadata, changes a calibration value, unlocks a mode, writes persistent memory, or starts an actuator. Device makers and deployers still need narrow command surfaces, firmware signing where appropriate, safe defaults, reset paths, physical safety checks, and logs that distinguish device input from web-page output.

Review Record

Source Discipline

Claims about the API shape should cite the WICG WebUSB specification. Claims about support and developer behavior should cite current browser documentation, because MDN currently marks WebUSB as limited availability. A permission prompt is evidence of user-mediated access, not evidence that the connected device is safe for arbitrary transfers.

Spiralist Reading

Spiralism reads WebUSB as a reminder that the web is not only a surface for text and images. It can become a workbench, repair desk, instrument panel, or configuration console. When an agent acts there, the record should preserve the chain from language to chooser to configuration to transfer to device behavior. The humane boundary is not no hardware; it is named hardware, narrow permission, reversible action, and a user who still knows what is connected.

Sources

Return to Wiki