Overview
Beacon runs on the endpoint and keeps the default telemetry path local. Supported agent harnesses emit activity through OpenTelemetry or native hook payloads. Beacon collects those runtime-specific signals, normalizes them into shared endpoint events, writes them to the local runtime JSONL log, and supports local inspection or customer-controlled forwarding. The architecture is local-first: endpoint telemetry can be inspected and forwarded without sending it to a hosted Beacon backend.
System Architecture
- Runtime surfaces: Supported agent harnesses expose different telemetry surfaces. Beacon uses the strongest surface available for each runtime instead of forcing every tool through one adapter.
- Local collection: Beacon receives OTLP gRPC, OTLP HTTP, or native hook payloads on the endpoint, depending on the runtime.
- Normalization: Logs, traces, metrics, resource attributes, and hook payloads are mapped into one endpoint event model with consistent event, endpoint, harness, session, tool, command, file, approval, policy, content, and destination context.
- Local storage and inspection: Beacon writes one JSON object per line to
runtime.jsonl. The local dashboard reads recent runtime logs over a loopback-only service for rollout validation and investigation. - Forwarding: External SIEM, log, and storage destinations consume the same normalized JSONL stream, or receive events directly from optional collector exporters.
End-to-End Flow
- A supported runtime emits activity through OTLP or hooks.
- Beacon receives the signal locally and attaches endpoint and harness context.
- Beacon normalizes runtime-specific payloads into the endpoint event schema.
- Beacon writes the event to the active
runtime.jsonlfile. - Operators inspect local activity in the dashboard or forward the JSONL stream to their security stack.
Architecture Details
Beacon writes an OpenTelemetry Collector configuration with localhost receivers:| Receiver | Default endpoint |
|---|---|
| OTLP gRPC | 127.0.0.1:4317 |
| OTLP HTTP | 127.0.0.1:4318 |
launchd in user mode or system mode.
- The generated pipeline receives logs, traces, and metrics locally.
- It batches data, applies memory limits, and exports normalized Beacon events through the
beaconjsonexporter. - Packaged deployments use the bundled Beacon collector distribution.
- Local installs can point at another
beacon-otelcolbinary with--collector.
runtime.jsonl is the stable handoff boundary.
- Beacon rotates the active file at 10 MiB and keeps five numbered local archives.
- Most downstream integrations read from that preserved JSONL output so the local audit trail stays intact.
- See SIEM forwarding for destination-specific forwarding options and setup.
Vector forwarding
Use Vector when you want a customer-managed host agent to tailruntime.jsonl and forward Beacon events without storing destination secrets in Beacon endpoint configuration.
- Beacon remains the local JSONL producer.
- Vector tails the active log path, checkpoints offsets, batches events, and retries delivery.
- Each JSONL line is parsed back into the original Beacon event so downstream systems receive Beacon’s event shape rather than a Vector wrapper.
- See SIEM forwarding for the supported Vector-based forwarding paths and destination-specific setup.
--include-runtime-metrics when low-level process, runtime, or harness metrics are required.
Related
Agent harness integration model
See how Beacon discovers and configures supported agent harnesses.
Data flow and threat model
Review the security boundaries, local collection path, and optional forwarding behavior.
Endpoint event schema
Review normalized Beacon JSONL event fields.
SIEM forwarding
Configure forwarding to SIEM, log aggregation, and storage destinations.

