Agent architecture and security model

Kaseya MDR uses a lightweight endpoint agent and secure cloud services to collect security‑relevant telemetry, correlate activity across environments, and support managed detection and response.

This article provides a high‑level view of the Kaseya MDR agent architecture and security model, including how data flows, how trust boundaries are enforced, and what the agent can—and cannot—do on monitored systems.

It is intended to help you understand how Kaseya MDR is designed, not to troubleshoot individual devices or response actions.

The Kaseya MDR agent is shared across Kaseya MDR and Kaseya SIEM and represents the continued evolution of the RocketCyber agent. The same agent is used across these platforms; differences in behavior and capabilities are determined by the platform and configuration, not by deploying separate agents.

Architectural principles

The Kaseya MDR architecture is built around the following core principles:

  • Least privilege and minimal footprint: The agent is designed to collect security telemetry without exposing systems to unnecessary risk.

  • Outbound‑only communication: All agent communication is initiated from the monitored system to the Kaseya MDR platform, reducing attack surface and eliminating the need for inbound access.

  • Resilience over constant connectivity: Monitoring continues even during temporary network interruptions, with activity preserved and delivered when connectivity is restored.

  • Separation of detection and response: Detection does not depend on real‑time command execution. Response actions are executed only when reachability is available and appropriate.

Agent communication model

The Kaseya MDR agent communicates securely with the Kaseya MDR platform to support detection, investigation, and response.

At a conceptual level:

  • The agent continuously monitors the system for security‑relevant activity.

  • Telemetry and detections are sent to the platform for correlation and analysis.

    How telemetry is evaluated and correlated once it reaches the platform is described in Detection and correlation model.

  • Response and control actions are received only when the agent is reachable.

  • Activity is queued or cached locally if communication is temporarily unavailable.

The agent does not accept inbound connections from the network, which helps limit exposure and reduces the risk of unauthorized access.

Security boundaries and safeguards

The Kaseya MDR agent is intentionally constrained in what it can do on a monitored system.

Key safeguards include:

  • No inbound network listeners exposed by the agent

  • No remote desktop, screen sharing, or interactive control capabilities

  • No execution of arbitrary user‑supplied code

  • No reliance on customer‑initiated inbound access for monitoring

These boundaries ensure that the agent functions as a telemetry and response mechanism, not as a general‑purpose management or remote‑access tool. These boundaries exist to support the staged Detect > Investigate > Respond lifecycle, rather than enabling direct or reactive control.

Data collection and visibility (high level)

Kaseya MDR collects security‑relevant telemetry from multiple sources to support detection and investigation, including:

  • Endpoint activity from supported operating systems

  • Network‑related security signals

  • Cloud and SaaS security events through supported integrations

The platform correlates this data to generate alerts, investigations, and response workflows. Customers interact primarily with alerts and investigations, rather than raw logs or individual telemetry events.

Detailed information about supported data sources and integrations is covered in Integrations and data sources.

Role of the managed SOC

Kaseya MDR includes a managed Security Operations Center (SOC) that:

  • Reviews and triages alerts

  • Correlates activity across environments

  • Works with customers when actionable threats are identified

The SOC operates within defined responsibilities and escalation boundaries. Understanding these roles helps set expectations for how detection, investigation, and response are coordinated.

How this fits with connectivity and response behavior

This architecture supports the behavior described in Agent connectivity and response availability:

  • Detection continues even during temporary connectivity interruptions.

  • Alerts remain valid regardless of agent reachability.

  • Response execution depends on the ability to communicate with the agent or integrated service at the time the action is performed.

Together, these models explain how Kaseya MDR maintains visibility while enforcing strong security boundaries.

Key takeaways

  • The Kaseya MDR agent uses an outbound‑only communication model.

  • Monitoring and detection are designed to be resilient to connectivity interruptions.

  • Security boundaries limit exposure and prevent unintended access.

  • Customers interact primarily with alerts and investigations, not raw telemetry.

Related articles

  • Detect > Investigate > Respond flow: Understand how detection, investigation, and response progress through the MDR lifecycle and how architectural boundaries shape decision‑making.

  • Detection and correlation model: See how telemetry collected by the agent is evaluated and correlated to produce alerts and investigations.

  • Deploying agents: Explains how the MDR agent is installed on supported systems as part of initial setup, without changing the architectural boundaries described here

  • Advanced agent settings: Describes agent‑level configuration options that adjust behavior within the boundaries of the MDR architecture.

  • Using Kaseya MDR: Apply these architectural concepts while reviewing alerts, investigations, and response actions in day‑to‑day use.