Concepts
Windows Agent
What the Windows Agent does for enrollment, readiness, secure connectivity, agentless access boundaries, and evidence.
The Windows Agent is the endpoint-side component that turns an existing Windows machine into a governed CerberusD resource. It runs on the machine, participates in enrollment and claim, reports service health and readiness, performs authorized local preparation, and ties access closure back to evidence.
When the private-network connector is selected, the Agent can prepare the client; preparation alone is not approval or session authority. An active path requires the client, private-network identity, required approval, an online node, and verified gateway-to-resource reachability. The panel shows readiness and online state separately.
The agent does not grant broad network reachability. Its role is to make the machine readable as a work resource with identity, assignment, readiness, session decision, revocation, and evidence.
The current agent scope is Windows machines. Linux hosts, network devices, terminal targets, Kubernetes endpoints, and other resources where the Windows Agent is not installed connect through the resource-without-Agent model, a private network gateway, or manual resource definition. Those resources still enter the assignment, session, and evidence model, but they do not produce Windows Agent service health or local preparation signals. Non-Windows agents can expand this model in a later product line.
When it is useful
The Windows Agent is most useful when:
- the resource is a Windows machine and RDP readiness depends on local state,
- last-seen, service health, version, and capability signals are part of the launch decision,
- managed local accounts or time-bound local users are used,
- secure private network connectivity is prepared through an endpoint connector,
- closure needs to show what happened on the machine after access ended.
Not every resource needs the Windows Agent. Reachable RDP, SSH, VNC, terminal, or Kubernetes targets can also enter the CerberusD decision, session, and evidence flow through agentless and manual access. Agent-managed resources provide richer machine signals and local preparation. Agentless paths fit targets where reachability is already handled by deployment or gateway design.
What runs on the machine
The Windows Agent has two visible responsibilities:
- Control panel: enrollment, state, diagnostics, updates, and user-interactive setup.
- Windows service: heartbeat, operational telemetry, authorized command results, update coordination, and resource readiness in the background.
This split lets enrollment start through user interaction while ongoing readiness and state reporting continue through the service.
Resource identity and enrollment
The agent does not treat the machine as an inventory row matched only by hostname or IP address. Enrollment and claim context make the resource readable as the right workspace resource.
That context is not an access grant. After the machine appears, person, role, assignment, duration, readiness, and policy are still evaluated before work opens.
Readiness signals
Before launch, the agent can report:
- last-seen time and service health,
- agent version and basic capability information,
- RDP or other work-path readiness,
- managed local account preparation result,
- secure connectivity or gateway reachability state,
- revocation, disablement, unregister, or uninstall outcome.
These signals are inputs to the access decision. A ready resource does not produce a work surface without an assigned person and an allowed session policy.
Secure connectivity and mesh
In configured deployments, the Windows Agent can prepare or report private reachability through a secure network connector. That path can work with Tailscale-compatible technical integration points; the client layer relates to Tailscale’s open-source client, daemon, and CLI ecosystem.
The Tailscale name is used here to explain technical compatibility and the open-source component boundary. Brand, service, and license responsibilities remain under their own ownership. CerberusD access authority still comes from workspace scope, resource assignment, session policy, and evidence.
When the secure network connector is enabled in the Windows Agent setup panel, the official Tailscale Windows client can be installed on the machine and prepared with CerberusD’s Headscale/Tailscale-compatible connection settings. The setup flow prepares private reachability; session authority still comes from the CerberusD decision.
Read Mesh and private connectivity for the focused model.
Normal telemetry boundary
Agent telemetry is operational: machine identity, version, service health, last-seen time, connectivity readiness, and authorized action result.
Normal agent telemetry is not a channel for user documents, passwords, hidden material, secure network keys, browser history, or arbitrary file contents. Session recording is a separate capability and depends on deployment and policy scope.
GitHub and release transparency
The Windows Agent source code, release channel, and security reporting surface are available on GitHub:
Evidence left behind
Agent-related evidence can include:
- enrollment and claim time,
- last-seen time, version, and service state,
- readiness or authorized local action result,
- managed local account preparation or revocation result,
- secure connectivity or gateway state,
- which resource readiness supported a session decision,
- disable, unregister, uninstall, or closure result.
The useful question is broader than “was the machine connected?” It is: which resource became ready for which decision, through which preparation?