Reference
Connecting resources without the Agent
Connection model for Linux servers, network devices, terminal targets, Kubernetes endpoints, and existing RDP/SSH/VNC resources that enter CerberusD decisions, sessions, and records without the Windows Agent.
Not every CerberusD resource starts with the Windows Agent. The current agent scope is Windows machines. Linux servers, network devices, terminal targets, Kubernetes endpoints, and other resources where the Windows Agent is not installed can become governed resources through a private network gateway, an approved existing network path, or a manual resource definition.
Connecting a resource without the Agent attaches the target to the CerberusD decision and record plane. Work opens through person, role, resource assignment, duration, policy, and session gateway behavior. Because no agent runs inside the endpoint, machine-side health, preparation, and cleanup signals stay more limited.
Connection models
Windows Agent + secure network connector
- Creates private networking?
- Setup can prepare the Tailscale client and apply Headscale/Tailscale-compatible connection settings.
- Best fit
- Windows machines that need health signals, RDP readiness, managed local accounts, or endpoint-side cleanup.
- Security boundary
- Agent heartbeat, service state, local preparation, and private connectivity signals can inform the session decision.
Private network gateway
- Creates private networking?
- The gateway joins the private network and reaches the target on behalf of CerberusD. This model can rely on Headscale/Tailscale-compatible private networking.
- Best fit
- Non-Windows resources where private reachability is needed without installing an endpoint agent.
- Security boundary
- The resource does not emit agent signals; authority remains in CerberusD assignment and session decisions.
Manual resource
- Creates private networking?
- Not by itself. The target is already reachable through a defined and approved access path.
- Best fit
- Existing RDP, SSH, VNC, terminal, or Kubernetes targets that need to become governed resources quickly.
- Security boundary
- CerberusD governs the session and evidence; network exposure remains a deployment responsibility.
Existing network path or external target
- Creates private networking?
- No. CerberusD does not turn this path into a private network boundary.
- Best fit
- A resource is reachable through public DNS/IP or an existing network path.
- Security boundary
- The person is not normally handed a raw target, but open-port risk is not the same as a CerberusD private network boundary.
These models can coexist. The same workspace can manage Windows Agent machines, resources behind a private network gateway, and manually defined targets.
Prerequisite table
| Work surface | Portal-visible fields | Readiness and ownership |
|---|---|---|
| RDP | Display name, target, port, credential type, assignment, duration | RDP is ready on the target; network/gateway reachability stays with the deployment owner |
| SSH / terminal | Display name, target, port, credential type, assignment, duration | SSH or terminal reachability is verified through the gateway |
| VNC | Display name, target, port, credential type, assignment, duration | VNC service and reachability stay with the deployment owner |
| Kubernetes | Display name, target, port or gateway path, credential type, assignment, duration | The Kubernetes endpoint and authorized path are ready before setup; kubeconfig and token provisioning remain with the deployment owner |
Visible records
Resources connected without the Agent can expose:
- resource name, protocol, and target information,
- port and connection parameters,
- private network gateway or node state when that connection model is used,
- resource assignment,
- session request and decision result,
- session lifecycle and closure record,
- gateway or connection-path health when the deployment provides that signal.
Those records make the access operation reviewable. The record shows which decision used the resource and which session path opened the work.
Endpoint signals that stay limited
Because no agent runs inside the endpoint, these signals are less rich than in the Windows Agent model:
- local service health,
- Windows DPAPI-backed agent identity,
- agent heartbeat,
- RDP readiness checks,
- managed local account preparation,
- endpoint-side cleanup result.
This distinction clarifies the evidence scope. CerberusD governs the session decision and record flow; machine-side preparation evidence is stronger on agent-managed resources.
Security boundary
Manual resource entry is not target scanning. The target is known to the deployment owner, allowed for the work model, and attached to CerberusD as a governed resource.
Even when a target is externally reachable, the person does not receive a raw connection target as the normal work path. CerberusD opens work through person, role, resource assignment, duration, policy, and session gateway behavior. Evidence shows which decision used the resource.
A private network claim only applies when a private network gateway or Windows Agent secure connector is actually in the path. Manual resources and existing-network paths enter the CerberusD decision and evidence flow; open ports, firewall posture, and network exposure remain deployment responsibilities.
Agent-managed and without-Agent model differences
Windows Agent
- Turns a Windows machine into a governed resource through enrollment and claim flow.
- Can create private reachability through Tailscale client setup and Headscale/Tailscale-compatible configuration.
- Emits heartbeat, service state, RDP readiness, managed local account, and endpoint-side cleanup signals.
- Opens work through CerberusD decision, session gateway, and agent readiness.
Private network gateway
- Fits non-Windows servers, terminals, network targets, or resources behind a gateway.
- Can provide private reachability when the gateway or node joins the private network.
- The resource does not emit agent signals; gateway or node state and session records remain visible.
- Authority still stays in CerberusD assignment, duration, policy, and session decisions.
Manual or direct target
- Defines an existing RDP, SSH, VNC, terminal, or Kubernetes target as a resource.
- Private reachability is not produced by CerberusD; the target network posture depends on deployment.
- The person is not normally handed a raw target; work is visible through the session gateway and evidence flow.
- Last-seen and closure information is usually limited to session attempts, resource definition, or deployment signals.
The practical distinction is clear: resources connected without the Agent enter the CerberusD session and evidence model; agent-managed resources add machine-side readiness and local preparation.
When non-Windows agent support arrives, this comparison can expand. Until then, the secure model for non-Windows resources is a private network gateway or a deployment-managed manual resource path.
Choosing a model
- For Windows machines, the Windows Agent gives the richest preparation and health signal.
- For Linux servers, network devices, terminal targets, or Kubernetes endpoints reached through a private network, use the private network gateway.
- For targets already reachable through an approved network path and ready to enter CerberusD decision/record flow quickly, use manual resource definition.
- For targets reachable through open ports, CerberusD governs the session and record; firewall, allowlist, gateway design, and network exposure remain deployment responsibilities.