How SecureExec Agents Work

The SecureExec agent is a lightweight, single-binary process that runs on your endpoints and streams security telemetry to the ingestion server in real time. This post explains the architecture behind the agent, how it collects events, and why we chose the approach we did.

The Agent's Core Loop

The agent subscribes to kernel events through the operating system's auditing and tracing interfaces. On Linux, this means hooking into the audit subsystem and procfs for process events, inotify for file operations, and netlink for network activity.

Events are serialized using Protocol Buffers and streamed to the SecureExec server over a persistent gRPC connection. The agent implements two transport modes:

• Streaming (send_events) — a long-lived bidirectional stream, ideal for high-throughput endpoints
• Batch (send_event_batch) — collects events over a short window and sends a single bulk request, better for endpoints with intermittent connectivity

Event Schema

Every event carries a common envelope:

message AgentEvent {
  string id = 1;
  uint64 seqno = 2;
  string timestamp = 3;
  string agent_id = 4;
  string hostname = 5;
  string os = 6;
  string content_hash = 7;
  string process_uid = 8;
  oneof kind { ... }
}

The process_uid field is a stable identifier for a process across reboots, combining PID, start time, and hostname. This lets detection rules follow process lineage even across short-lived processes.

Spool and Retry

The agent maintains a local spool on disk. If the connection to the ingestion server drops, events are written to the spool and retried in order once the connection is restored. This guarantees no telemetry is lost during network interruptions or server restarts.

The heartbeat event (AgentHeartbeat) reports spool_pending — the number of queued events — so operators can monitor backlog from the console.

Why Rust?

Rust gives us memory safety and predictable, low-latency performance without a garbage collector. The agent binary is statically linked and has zero runtime dependencies, making deployment as simple as copying a single file to the host.

On a busy production server generating 50,000 events per minute, the SecureExec agent consistently uses less than 1% CPU and around 20 MB of resident memory.

What's Next

We're working on eBPF-based event collection for Linux, which will allow us to capture kernel-level events with even lower overhead and without requiring root privileges. Watch this space.