Skip to main content

​
Overview

Beacon CI telemetry is written as normalized JSONL for a single ephemeral CI job. The completed runtime.jsonl file is the durable handoff artifact: upload it as a workflow artifact, copy it to object storage, or route it into the same SIEM and log pipelines that consume Beacon endpoint JSONL.
This page covers export workflows for beacon ci. For persistent laptop or workstation forwarding, use Log Forwarding.

​
Export Contract

By default, beacon ci exec writes the CI runtime log to $RUNNER_TEMP/beacon/runtime.jsonl when RUNNER_TEMP is set. Otherwise it uses the system temp directory. Use --log-path when your workflow needs a stable artifact path.
ArtifactDefault pathExport guidance
Runtime log$RUNNER_TEMP/beacon/runtime.jsonlUpload or forward this JSONL file
Collector config$RUNNER_TEMP/beacon/otelcol.yamlKeep out of shared artifacts when it may contain environment references
Collector spool$RUNNER_TEMP/beacon/spool/otlp.jsonlOperational buffer for troubleshooting
Each line in runtime.jsonl is one complete Beacon event using the Endpoint Event Schema. Beacon applies redaction, sanitization, truncation, and event-size limits before events are written, so downstream artifacts receive the same normalized JSONL contract as local endpoint logs.

​
Export Paths

​
Workflow Artifact

The Agent Beacon CI Telemetry GitHub Action uploads the CI runtime log as a workflow artifact by default: 
- name: Run Claude with Beacon telemetry
  uses: asymptote-labs/agent-beacon@v0.0.50
  with:
    command: claude --print "Review this pull request"
    upload-artifact: "true"
    artifact-name: beacon-runtime-log
Use the workflow artifact path when a security team or downstream job will retrieve the completed JSONL file after the run. Artifact access, retention, and download permissions stay under GitHub Actions controls.

​
Object Storage Upload

For CI runners that should hand off telemetry through object storage, beacon ci exec can upload the completed runtime.jsonl after telemetry validation. Upload to Amazon S3: 
export BEACON_CI_S3_BUCKET="my-beacon-telemetry"
export BEACON_CI_S3_PREFIX="github-actions"

beacon ci exec --upload s3 -- claude --print "Summarize this repository"
Upload to Google Cloud Storage: 
export BEACON_CI_GCS_BUCKET="my-beacon-telemetry"
export BEACON_CI_GCS_PREFIX="github-actions"

beacon ci exec --upload gcs -- claude --print "Summarize this repository"
--upload is repeatable, so a job can upload to both destinations when required: 
beacon ci exec --upload s3 --upload gcs -- claude --print "Review this repository"
--upload requires Beacon v0.0.44 or newer. S3 upload uses aws s3 cp and the standard AWS credential provider chain. GCS upload uses gcloud storage cp when available, falling back to gsutil cp.

​
GitHub Actions Object Storage

Configure cloud credentials at the job level, then pass the upload destination to the Agent Beacon action: 
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.BEACON_TELEMETRY_ROLE_ARN }}
    aws-region: us-east-1

- name: Run Claude with Beacon telemetry
  uses: asymptote-labs/agent-beacon@v0.0.50
  env:
    BEACON_CI_S3_BUCKET: my-beacon-telemetry
    BEACON_CI_S3_PREFIX: github-actions
  with:
    command: claude --print "Review this pull request"
    upload: s3
For GCS, authenticate with your normal Google Cloud CI mechanism and set BEACON_CI_GCS_BUCKET plus optional BEACON_CI_GCS_PREFIX: 
- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: ${{ secrets.BEACON_GCP_WORKLOAD_IDENTITY_PROVIDER }}
    service_account: ${{ secrets.BEACON_GCP_SERVICE_ACCOUNT }}

- name: Run Claude with Beacon telemetry
  uses: asymptote-labs/agent-beacon@v0.0.50
  env:
    BEACON_CI_GCS_BUCKET: my-beacon-telemetry
    BEACON_CI_GCS_PREFIX: github-actions
  with:
    command: claude --print "Review this pull request"
    upload: gcs

​
Object Layout

In GitHub Actions, object keys use this shape: 
<prefix>/<owner>/<repo>/<run_id>/<run_attempt>/runtime.jsonl
Outside GitHub Actions, Beacon falls back to: 
<prefix>/ci/<timestamp>/runtime.jsonl
Prefixes are optional. Beacon trims empty path parts and normalizes path separators before building the upload key.

​
Destination Mapping

The JSONL artifact is the universal CI export contract. Existing destination packs and forwarding patterns can consume the same file after it is downloaded, copied, or routed into the customer-managed handoff path.
DestinationCI export path
WazuhDownload the artifact and ingest it with the Wazuh localfile pack or an equivalent JSONL import path
ElasticDownload the artifact and ingest it with Filebeat or Elastic Agent pack assets
DatadogDownload the artifact and ingest it with Datadog Agent log collection or a customer-managed log pipeline
Sumo LogicDownload the artifact for Vector-based forwarding, or use --upload when object storage is the handoff point
Rapid7Download the artifact for Vector or webhook forwarding
AWS S3Use --upload s3 in CI, or upload the workflow artifact manually
AWS CloudWatch LogsDownload the artifact and forward it with the Vector CloudWatch pack
Google Cloud StorageUse --upload gcs in CI, or upload the workflow artifact manually
Microsoft SentinelDownload the artifact and ingest it with Azure Monitor Agent or a Data Collection Rule path
SplunkUse direct --forward splunk, or ingest the JSONL artifact with an existing Splunk pipeline
Falcon LogScaleUse direct --forward falcon, or ingest the JSONL artifact with an existing pipeline

​
Security Notes

Keep cloud credentials in CI secret stores, OIDC roles, workload identity, or job-level credential actions. Do not pass cloud credentials through prompt text, action inputs, or committed workflow files. When object storage upload is configured, Beacon strips common AWS and Google credential environment variables from the child agent process while keeping them available to the post-run uploader. This reduces credential exposure to the command being observed. Review artifact access before rollout. CI runtime JSONL can contain prompt, tool, file, command, and run context where supported runtimes emit it. Beacon applies redaction, sanitization, truncation, and event-size limits before writing the artifact, but artifact retention, access, and downstream routing remain controlled by GitHub Actions, object storage, and your customer-managed pipeline.

​
Failure Behavior

By default, beacon ci exec fails the step when telemetry validation fails. Set --require-telemetry=false or the action input require-telemetry: "false" when telemetry health should warn but not gate the build. Object storage upload runs after telemetry validation. Upload failures fail the CI step so broken export paths are visible. If the child command exits non-zero, that child exit code still takes precedence.

beacon ci

Run and validate ephemeral Beacon telemetry collection in CI.

Log Forwarding

Compare endpoint SIEM, log aggregation, object storage, and local forwarding paths.

Retention and Redaction

Choose how much content Beacon writes before export.

Endpoint Event Schema

Review normalized JSONL event fields.