Skip to main content

Broker and Network Controls

Worka does not give every runtime component the same network model.

That is deliberate. Packs, persistent services, local browser control, desktop computer control, and shared network contribution all have different risk profiles. Operators need to understand those differences because network policy is one of the main ways Worka stays safe without becoming useless.

The broker's role​

For pack execution, the broker is the controlled path between pack logic and the outside world.

In practical terms, the broker is where Worka can:

  • enforce outbound rules
  • resolve connection-backed credentials
  • inject approved authentication material
  • mediate privileged host capabilities
  • audit cross-boundary activity

That is why pack docs talk about declared outbound domains and connection-backed requests. The broker is how those declarations become enforceable.

Packs and services do not have the same network shape​

Treat these as separate cases:

Packs​

Packs are capability units. They are invoked through the platform and are expected to stay within declared capability and network boundaries.

Persistent services​

Services are long-running HTTP processes. They may need inbound traffic, predictable domains, health checks, and broader outbound reach than a pack tool call would need.

Local capabilities​

Browser automation, desktop control, and local CLI access live on trusted user devices or hosts. Those capabilities are governed through device registration, local enablement, and consent rather than through the pack broker alone.

What you should control​

At minimum, you should be able to answer:

  • which packs may call external systems
  • which destinations are allowed
  • which connections back those calls
  • which services are allowed to expose public routes
  • which local capabilities are enabled on which devices
  • whether a device may contribute to the shared network or remain local-only

Those controls should be visible to both users and operators. Hidden network reach is hard to govern.

Browser and computer-use controls​

Treat browser persistence and desktop computer control as elevated capabilities.

They require stronger review because they expand what Worka can observe and manipulate on a real device. The operational expectations should be clear:

  • isolated browser mode is the safer default
  • persistent browser mode should be explicit
  • desktop control requires local permission state to be visible and reviewable
  • these capabilities should be easy to disable centrally or locally

Shared network contribution​

Running your own tasks on your own device is a different decision from letting Worka route third-party work to that device.

If you allow shared network contribution, make sure users can control:

  • whether contribution is enabled at all
  • which capability classes are shareable
  • what capacity is reserved for their own work
  • when contribution is paused or disabled

This is a product and trust issue as much as a technical one.