Architecture

Mesh and Private Connectivity

How the Windows Agent, gateway paths, and Tailscale-compatible private connectivity keep reachability separate from session authority.

Page type: ArchitectureMesh and private networkStatus: CurrentCurrent product behaviorLast reviewed: 2026-07-01

Mesh and private connectivity make a resource reachable and evaluable by CerberusD. Authority still comes from workspace scope, resource assignment, role, duration, session policy, and evidence.

That separation is the core security model: reachability is not authority. The resource stays in its operating environment, and the normal work path does not hand the person a raw address, port, or broad network membership.

Connection models

CerberusD can use multiple resource paths in the same product model:

  • Windows Agent: reports machine-side health, readiness, local action, and secure connectivity signals.
  • Gateway path: a controlled deployment-side gateway reaches the target; for non-Windows resources, this is the main private-access model without installing an endpoint agent.
  • Manual resource: an externally reachable or deployment-reachable target is defined as a governed resource.
  • Tailscale-compatible private network: the resource stays private while reachability is carried by mesh connectivity.

These paths do not replace session authority. They let the session gateway reach the target for an approved session.

Tailscale compatibility and open-source boundary

In configured deployments, the CerberusD private network connector can work with Tailscale-compatible technical integration points. The integration targets the technical surface associated with Tailscale’s open-source client, daemon, and CLI ecosystem.

CerberusD uses the Tailscale name for technical compatibility and third-party boundary clarity. The intended meaning is:

  • the connectivity path can understand a Tailscale-compatible mesh model,
  • the client layer works with open-source Tailscale components,
  • the Windows Agent setup panel can download the official Tailscale Windows client, verify its signature, and install it on the machine,
  • deployments that use Tailscale services or an organization-managed Tailscale account also follow the applicable Tailscale terms.

This boundary is explicit so readers can separate network reachability from product authority. CerberusD does not delegate access authority to Tailscale; the Tailscale-compatible path is the private reachability layer.

For non-Windows resources, the current model is not to install a Cerberus endpoint agent. Those resources join through a Headscale/Tailscale-compatible node or gateway path, or they are defined as deployment-reachable manual resources. Later non-Windows agent support can broaden that distinction.

State verified after setup

When the private-network connector is selected, verify connectivity in this order:

  1. The Tailscale-compatible client is installed and its service is running.
  2. If the deployment requires node approval, approve the correct node in the authorized administration surface.
  3. The node or gateway appears with the expected private-network identity.
  4. Connectivity reaches the online state.
  5. The gateway or session gateway confirms reachability to the resource over the private network.

These checks prove resource reachability. A session still requires a positive person-resource assignment, duration, role, and policy decision.

Why the resource is not an open target

Directly exposed ports detach address, port, connection file, or password material from the access decision. That makes it harder to explain who worked under which scope and how access closed after the work ended.

CerberusD ties resource access to this sequence:

  1. The resource becomes visible through agent, gateway, manual definition, or private network path.
  2. The resource is accepted into the workspace.
  3. Readiness and reachability are read.
  4. The person-resource assignment is created.
  5. The session request is evaluated with identity, role, duration, and policy.
  6. Approved work opens through the session gateway.
  7. Closure, revocation, and evidence stay in the same operation chain.

Agent-managed and without-Agent mesh behavior

With the Windows Agent, the machine can report service health, version, last-seen time, secure connectivity, and local preparation results. When the secure network connector is selected during setup, the Tailscale client can be installed on the machine and prepared with Headscale/Tailscale-compatible connection settings. Those signals make the session decision more concrete.

Without the Agent, reachability is provided by the deployment gateway, Headscale/Tailscale-compatible private network, manual resource definition, or existing network path. CerberusD still governs session, assignment, and evidence; machine-side local preparation signals are more limited.

A direct/external target is a separate case: CerberusD can govern the session decision and evidence flow, but if the target is reachable through public ports or an existing network path, that is not the same security boundary as private mesh access. A private-access claim only applies when gateway, private network, or agent secure connector is actually in the path.

Read Connecting resources without the Agent for the detailed comparison.

Offline and revocation behavior

When the resource is offline, its connectivity signal is stale, or the resource is revoked, new work does not open. The resource can remain visible in inventory, but the work surface needs a current positive decision.

After revocation, the record can answer:

  • when the resource was last seen,
  • which readiness or connectivity state was present,
  • why the session opened, closed, or was denied,
  • which result was produced when access was revoked.