Agent Security
The SparkLogs Agent makes only outbound connections to the SparkLogs cloud. This page covers data flow, network boundaries, and the controls that protect each endpoint. For how these fit the wider platform security model, see the Trust Center agent section.
Data flow
Network and credentials
No inbound ports
The agent only initiates outbound connections over TLS 443. There is no inbound listening port on the endpoint, so the agent does not widen your attack surface.
Per-agent credential
Each agent receives its own credential, scoped to one workspace. Cloned or duplicated agents are detected so a copied machine image cannot silently impersonate another endpoint.
No remote execution
The agent collects and ships data. It has no remote shell, no arbitrary command channel, and no mechanism for the cloud to push code or scripts to your endpoints. It does run a fixed set of built-in diagnostic commands to gather system information; policy controls which ones run, but the set is baked into the signed agent and cannot be extended remotely. There is no inbound listener of any kind: no open ports, no pipes accepting external commands. All connections are outbound HTTPS on port 443, initiated by the agent. A compromise of the SparkLogs cloud cannot be turned into code execution on your machines, because the primitive does not exist.
What protects each endpoint
Pure Rust
The agent and its entire data pipeline are written in Rust, a memory-safe language. The classic agent vulnerabilities (buffer overflows, use-after-free) that turn endpoint software into an attack surface are excluded by the language itself. Native code is forbidden by policy across the codebase, with audited, documented exceptions only where the Windows API demands it.
Signed, verified, staged updates
Updates are protected by two independent signature chains: Windows Authenticode on every binary, and The Update Framework (TUF), an open standard for securing software update systems. The agent verifies both before staging an update. Signing keys live in cloud HSMs; no developer holds a production signing key. Releases roll out through canary, early-access, and stable rings, and an updated agent monitors its own health after install with automatic recovery if anything fails. Downgrade attacks and frozen-update attacks are blocked by the metadata design, not by policy.
Transparent supply chain
Reproducible builds: two independent build machines must produce byte-identical binaries before release. Every dependency is pinned and scanned for known vulnerabilities on every build; a CVE in any dependency fails the pipeline. A software bill of materials (SBOM) is published with every release.
Bounded footprint
Steady state: 1 to 3 percent CPU and under 100 MB of memory. The agent runs at the lowest OS scheduling priority: your workloads always take priority. On a full disk it sheds its own data rather than crashing or filling the volume, and reports when it has done so.
Service privilege
The agent service runs as LocalSystem on Windows. This is required to read the Security event log and collect system-wide state. What we do about it: no inbound attack surface, strict ACLs on the agent's files and credentials re-asserted at every start, per-agent credentials that are useless in any other workspace, and clone detection so a copied machine image cannot silently impersonate another endpoint.
Bounded collection
The agent reads event logs, system state snapshots (services, processes, network interfaces, installed software), and the text log files you approve by policy. It does not read user documents, browser data, application secrets, or credential stores. What it collects is controlled by workspace policy that you can inspect and change.
See the Trust Center agent section for how these controls fit the wider platform security model.