Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.asymptotelabs.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Beacon Concepts

Beacon observes local AI agent runtime activity, normalizes it into endpoint events, and keeps a local JSONL audit log that security teams can inspect or forward into existing pipelines. Use this page as a quick reference for the terms used across the Beacon CLI docs.

​
Endpoint Agent

The endpoint agent is the local Beacon service and configuration managed by beacon endpoint. It configures supported AI runtimes, runs the local collector, writes endpoint events to JSONL, and supports inspection, repair, dashboard, Wazuh, hooks, and forwarding commands.

​
Runtime Surface

A runtime surface is the telemetry interface exposed by an AI agent runtime. Beacon supports different surfaces because each runtime exposes activity differently: Claude Code and Codex CLI use OpenTelemetry, Factory Droid can use OTLP launch-environment configuration and hooks, Cursor uses hooks, and Claude Cowork uses admin-configured OTLP.

​
Harness

A harness is the runtime or integration that produced an event, such as claude, codex, factory, cursor, or claude_cowork. Beacon stores harness context in endpoint events so investigators can filter by the tool that generated the activity.

​
Local Collector

The local collector is Beacon’s OpenTelemetry Collector pipeline on the endpoint. It receives OTLP from supported runtimes, batches and processes telemetry, writes normalized Beacon JSONL through the beaconjson exporter, and can optionally send collector signals to Splunk HEC.

​
OTLP

OTLP is the OpenTelemetry Protocol used by runtimes to send logs, traces, metrics, and resource attributes to Beacon. Local installs commonly use 127.0.0.1:4317 for OTLP gRPC and 127.0.0.1:4318 for OTLP HTTP.

​
Hooks

Hooks are runtime-managed integration points that invoke Beacon’s beacon-hooks adapter. Cursor and Factory hooks capture session, prompt, tool, command, approval, MCP-like, and file edit events where those runtimes expose payloads.

​
Endpoint Event

An endpoint event is one normalized Beacon JSON object describing runtime activity on a machine. Endpoint events include a stable event action, endpoint context, harness context, severity, and any optional entities the source provides.

​
Entity Model

The entity model is Beacon’s shared shape for runtime-specific payloads. Each event has an action plus typed context such as endpoint, user, harness, session, tool, file, command, mcp, approval, policy, prompt, content, destination, and health.

​
Runtime JSONL Log

The runtime JSONL log is Beacon’s local audit log. User-mode installs write to ~/.beacon/endpoint/logs/runtime.jsonl; system-mode installs write to /var/log/beacon-agent/runtime.jsonl. Each line is a complete Beacon endpoint event.

​
Wazuh Localfile

Wazuh localfile ingestion reads Beacon’s runtime JSONL log from disk. Beacon can print localfile configuration, generate rule packs and sample events, and write validation events for Wazuh ingestion tests.

​
Splunk HEC

Splunk HEC is Splunk HTTP Event Collector. Beacon can optionally configure a collector exporter that forwards OTLP logs, traces, and metrics to a customer-managed Splunk HEC endpoint while preserving the local JSONL audit log.

​
Customer-Managed Forwarding

Customer-managed forwarding means an existing shipper, agent, or SIEM pipeline reads Beacon’s runtime JSONL log and routes each line to a downstream destination such as Elastic, Datadog, or another SIEM.

​
Dashboard

The dashboard is a loopback-only local view over Beacon runtime logs. It shows runtime inventory, event summaries, timelines, filters, and event details without requiring a hosted Beacon account.

​
Content Retention

Content retention controls how much prompt, command, attribute, and diff content Beacon records. full includes configured content fields, redacted applies local redaction and size limits, and metadata excludes prompt text, raw attributes, command output, and raw diffs.

​
User Mode And System Mode

User mode uses per-user paths under ~/.beacon/endpoint and is the default for local evaluation. System mode uses root-managed paths under /Library/Application Support/Beacon/Endpoint and /var/log/beacon-agent, which is the preferred mode for packaged or MDM deployments.

Beacon architecture

See how runtime telemetry flows through collection, normalization, and local outputs.

Endpoint event schema

Review normalized Beacon JSONL fields and example events.

Supported surfaces

Compare supported runtimes, deployment modes, storage, and forwarding.

SIEM forwarding

Forward Beacon events into Wazuh, Splunk HEC, or customer-managed pipelines.