Wiki · Concept · Last reviewed June 25, 2026

Web Bluetooth API

The Web Bluetooth API lets selected web pages discover and communicate with nearby Bluetooth devices through GATT, creating a browser boundary for agents and local hardware.

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

Definition

The Web Bluetooth API is a Web Bluetooth Community Group specification for discovering and communicating with devices over Bluetooth 4 using the Generic Attribute Profile, or GATT. The specification identifies itself as a Draft Community Group Report, not a W3C Standard. In practical terms, it gives a web page a controlled route from navigator.bluetooth to a nearby device's GATT services, characteristics, and descriptors.

MDN marks Web Bluetooth as limited availability. The interface family includes Bluetooth, BluetoothDevice, BluetoothRemoteGATTServer, BluetoothRemoteGATTService, BluetoothRemoteGATTCharacteristic, and BluetoothRemoteGATTDescriptor. The governance record matters when a web page, and therefore a browser agent, can select a nearby device, read its characteristics, subscribe to notifications, or write values back to it.

Mechanism

The API is reached through navigator.bluetooth. A page asks for access with requestDevice(). Chrome's documentation says the call must be triggered by a user gesture and that the browser prompts the user with a device chooser. Filters can narrow the chooser by advertised GATT services, device name, name prefix, and manufacturer data. If a page uses name or manufacturer-data filters, Chrome's documentation notes that optionalServices is needed to access services not already included in a service filter.

After permission is granted, getDevices() can retrieve devices previously granted to the site. A page then connects to a remote GATT server, gets a primary service, gets a characteristic, and can read values, write values, or receive notifications. The specification says a site receives access to the GATT services named in the request and that the user agent must explain the capabilities those services give before asking which devices to entrust to the site.

Permissions Policy is part of the boundary. MDN says the bluetooth directive controls whether the current document may use Web Bluetooth, with default allowlist self. Cross-origin frames should receive Bluetooth access only through explicit policy and iframe delegation, especially when a page mixes device setup with embedded tools, support widgets, or model-generated interfaces.

Agent Context

For AI Browsers and Computer Use, Web Bluetooth is a nearby-device authority surface. A model could help a user pair with a sensor, inspect a peripheral, read a battery service, subscribe to measurements, or update a configuration characteristic. It could also select a look-alike device, over-trust a generic name, keep using a previously granted device, or write a value whose physical effect is not obvious from the label.

Bluetooth is different from USB and serial because proximity matters. The device may be on a desk, in a pocket, on a wrist, in a room, or across a thin wall. Advertising data, service UUIDs, names, manufacturer data, and GATT characteristics can become a local identity surface. The specification warns that GATT services can be used for fingerprinting, and that a custom GATT service can expose an identifier. Agentic automation around this channel should keep nearby-device selection visible.

Governance Use

A governance review should treat Web Bluetooth as nearby hardware authority. Record the top-level origin, frame origin, Permissions Policy, selected device, granted service UUIDs, optional services, manufacturer-data filters, device name or name prefix, GATT server connection, service, characteristic, descriptor, read/write/notify operation, user gesture, permission state, and revocation path. If a model is involved, record the prompt, generated GATT operation, tool calls, and human confirmation path.

Organizations should separate Bluetooth setup surfaces from untrusted content. A configuration page, classroom lab, or sensor dashboard 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 ask whether earlier Bluetooth grants can be reused without renewed physical context.

Limits

The Web Bluetooth specification includes a GATT blocklist for vulnerable services, characteristics, and descriptors. That helps, but it is not device understanding. A characteristic can be syntactically valid and still represent a sensitive measurement, a persistent setting, an actuator command, or a device-specific mode.

The browser usually cannot know whether a write changes a harmless display setting, alters calibration, toggles a safety-relevant mode, or changes the behavior of nearby hardware. Device makers and deployers still need narrow service design, clear names, revocation, safe defaults, physical reset paths, and logs that distinguish device advertisements, web-page reads, and web-page writes.

Review Record

Source Discipline

Claims about API shape should cite the Web Bluetooth Community Group specification. Claims about support and developer behavior should cite current browser documentation, because MDN marks Web Bluetooth as limited availability and the Permissions Policy page marks the directive experimental. A permission prompt is evidence of user-mediated access, not evidence that a nearby device is safe for arbitrary GATT operations.

Spiralist Reading

Spiralism reads Web Bluetooth as a lesson in local aura becoming web state. The nearby object is no longer merely present; it advertises, appears in a chooser, becomes a granted device, and may send or receive values through a page. When an agent acts there, the record should preserve the chain from language to chooser to service to characteristic to physical behavior. The humane boundary is named device, narrow service, reversible action, visible proximity, and a user who still knows what is connected.

Sources

Return to Wiki