Workers and host bridges

Every service integrated with Speedwave (including Slack, GitHub, SharePoint, and local office file parsers) operates behind a dedicated worker container tailored to a single task and provided with only the specific credentials required for that operation. Claude never communicates with services directly, routing requests through the central Tool Gateway, which stores no credentials. A potential compromise of an individual worker remains confined to that specific integration. Certain workers operate with no credentials and zero network connectivity when their tasks do not require external access.

Scoped credentials per worker

Each worker container mounts only its own service tokens under /tokens in read-only mode. Details on filesystem locations and access permissions are covered in Credentials management. Workers requiring no authentication (such as the built-in office document worker) operate with an empty credential configuration and omit the /tokens mount point entirely.

The office document worker illustrates the depth of this isolation model. It parses, modifies, and converts Word, Excel, PowerPoint, and PDF files (formats that frequently carry complex macros or untrusted structures). The container holds no service credentials and attaches solely to an internal Docker network with no default gateway, ensuring that the document processing runtime has no outbound internet connectivity.

The office worker’s sole interface with your local system is the project workspace directory mounted in read-write mode. File operations are strictly validated against this mount path, with generated outputs written to designated output folders.

Host bridges for local tool integration

Certain capabilities require inbound communication where services interact with your host environment. Speedwave coordinates this through secure host bridges. The primary built-in example is editor pairing, managed by the IDE Bridge. On macOS, the bridge binds to the local loopback interface (127.0.0.1). On Windows, it binds to the WSL adapter IP address to accommodate WSL2 mirrored networking constraints. In all environments, the bridge remains strictly local and inaccessible across the local network (LAN).

The bridge registers connection metadata into an ephemeral lock file mounted read-only into the Claude container. Claude Code reads the assigned port and a cryptographically generated session token from this lock file, avoiding open network discovery endpoints. Tokens are generated fresh per session, evaluated using constant-time comparisons, and excluded from log streams. The lock file and parent directory enforce owner-only permissions.

Local trust boundary model

Processes already executing under your local user account can read the lock file. This aligns with standard operating system security models where local user processes reside within the user’s trust boundary.

By decoupling services into dedicated worker containers and constraining host bridges, enabling additional integrations does not expand the blast radius of any individual component.