Security

Overview

Causely integrates seamlessly with your existing observability stack. You can use your existing telemetry sources—metrics, traces, and logs—as data sources for causal analysis. Optional lightweight automatic instrumentation is available, but Causely works equally well with bring-your-own-data approaches. Most telemetry data is processed locally in your environment.

Causely is designed to protect sensitive data and ensure privacy. The system processes telemetry data locally and primarily transmits minimal, high-level information to its SaaS backend, such as service topology and observed symptoms (for example high latency or CPU usage). All data is encrypted in transit and at rest.

To provide context around inferred root causes, Causely sends a targeted subset of telemetry, such as relevant metrics, traces, and log-derived errors/events, to the backend after a root cause is identified. This data is used solely to enhance the clarity and usefulness of the root cause view. Personally Identifiable Information (PII) is filtered out to the extent possible, and customer data is never used to train any shared or foundational models.

Causely's infrastructure is strictly access-controlled. Only a small, authorized operations team has access, and customer data is never used to train any shared or foundational models. Each customer's causal graph is built and maintained independently, based on their specific service topology and behaviors, ensuring both privacy and accuracy.

Our approach is rooted in abstraction: modeling cause-and-effect relationships in complex systems. The causal graph is dynamically created by combining the abstract causal model with the discovered topology uniquely for each customer and maintained automatically and continuously. It enables us to cut through complexity, deliver precise insights, and build trust through transparency and actionable outcomes.

For information about Causely's deployment architecture, see the Architecture documentation.

Mediation Layer Components

The mediation layer consists of components deployed locally in your infrastructure. By default, all components operate with the minimum privileges required for their function. We will discuss the deployment details for Kubernetes, Docker, and Nomad environments in this overview. For specific setup steps, please refer to our installation instructions. Causely can also be deployed in other environments not listed here; if you'd like more information or guidance on those deployments, please contact us directly.

Agents

Agents are deployed across your infrastructure to gather node and container level metrics. The deployment method varies depending on your environment:

• Kubernetes: Agents are deployed as a DaemonSet across all nodes in the cluster
• Docker: Agents run as containers on standalone Docker hosts
• Nomad: Agents are deployed as Nomad jobs across the cluster

Agents require privileged access to the host system because they leverage eBPF technology. The specific permissions required depend on your deployment environment:

Kubernetes deployments:

• The container runs as privileged (securityContext.privileged=true)
• The container runs as root (securityContext.runAsUser: 0)
• The container readonly mounts the host filesystem into the container, granting access to the host directly (volumeMounts.readOnly: true)
• Additional Kubernetes API permissions are required to collect specific metrics about the node and containers

Docker deployments:

• The container runs with --privileged flag
• The container uses pid: host mode
• The container readonly mounts the host filesystem

Nomad deployments:

• Similar privileged access requirements as Docker deployments

Agents don't establish any outbound connections to the internet or any other service apart from the Mediator and VictoriaMetrics. The agents periodically forward the topology and manifestation data to the Mediator, which, in turn, sends it to the Causely SaaS backend for analysis.

Mediator

The Mediator is responsible for collecting infrastructure-level metrics and transmitting the data to the SaaS backend. The Mediator listens for OpenTelemetry signals (port: 4317) and updates from the agents (port: 50051).

The Mediator has only the minimal permissions necessary to discover the local infrastructure configuration and collect metrics. The specific permissions depend on your deployment environment:

• Kubernetes: The Mediator requires minimal Kubernetes API permissions to discover cluster configuration
• Docker/Nomad: The Mediator requires appropriate permissions to discover and monitor the local environment

The Mediator can also be optionally configured to get metrics from Prometheus or discover and monitor managed cloud services from cloud providers.

Executor

The Executor is responsible for executing remediation actions within your infrastructure. The Executor is an optional component and can be enabled as part of the deployment process.

The specific permissions required depend on your deployment environment:

• Kubernetes: The Executor's ServiceAccount is granted the cluster-admin role
• Docker/Nomad: The Executor requires appropriate permissions to execute remediation actions in your environment

VictoriaMetrics

VictoriaMetrics is a timeseries database used by the agents and mediator (port: 8428) to store additional timeseries data locally in your environment.