---
title: 'eBPF and security'
sidebarTitle: 'eBPF and security'
description: 'How Tracer observes execution safely and securely'
---

Tracer uses eBPF (extended Berkeley Packet Filter) to observe execution behavior directly from the Linux kernel. This approach enables high-fidelity visibility with minimal overhead, while maintaining strong safety and security guarantees.

This page explains why eBPF is used, what Tracer observes, what it does not observe, and how security is enforced.

## Why Tracer uses eBPF

Traditional observability approaches depend on logs, metrics exporters, or application-level instrumentation. These methods rely on what software chooses to expose and often miss behavior in short-lived processes, external binaries, or between metric collection intervals.

eBPF allows Tracer to observe execution where it actually happens, at the boundary between user processes and the operating system.

Using eBPF, Tracer can:

- Observe syscalls, scheduling events, and I/O activity
- Track process lifecycles across containers and hosts
- Capture execution behavior without modifying application code
- Work across languages, frameworks, and binaries

This makes eBPF well suited for scientific and ML workloads that rely on many heterogeneous tools.

<Frame>
  <img src="/images/howTracerWorks.webp" alt="How Tracer works: observing execution at the kernel level using eBPF" />
</Frame>

## Safety model

eBPF programs are subject to strict safety constraints enforced by the Linux kernel.

Tracer's use of eBPF follows these principles:

<AccordionGroup>
  <Accordion title="Verified bytecode">
    All eBPF programs are validated by the kernel verifier before execution. Programs that fail verification cannot run.
  </Accordion>
  <Accordion title="Sandboxed execution">
    eBPF programs run in a restricted environment and cannot access arbitrary memory or crash the kernel.
  </Accordion>
  <Accordion title="No kernel modifications">
    Tracer does not load kernel modules or modify kernel code.
  </Accordion>
  <Accordion title="Controlled attachment points">
    Tracer attaches only to well-defined kernel hooks such as system call boundaries and scheduler events.
  </Accordion>
</AccordionGroup>

These guarantees are provided by the kernel itself and apply regardless of how Tracer is configured.

## What Tracer observes

Tracer observes execution metadata, not application data.

<CardGroup cols={3}>
  <Card title="CPU & scheduling" icon="microchip">
    CPU usage and scheduling behavior
  </Card>
  <Card title="Memory" icon="memory">
    Memory usage and peak memory
  </Card>
  <Card title="I/O activity" icon="hard-drive">
    Disk and network I/O activity
  </Card>
  <Card title="Process lifecycle" icon="diagram-project">
    Process start, stop, and parent–child relationships
  </Card>
  <Card title="Container context" icon="cube">
    Container, namespace, and cgroup context
  </Card>
</CardGroup>

This data is used to reconstruct execution timelines and resource usage patterns.

## What Tracer does not observe

<Warning>
**Tracer explicitly does not collect:**
- Application payloads or scientific input/output data
- File contents or data values
- Source code or function-level execution traces
- Environment variables or secrets
- Application- or domain-level interpretation of what a command does
</Warning>

While Tracer can observe which binaries and commands were executed, it does not inspect the data those commands operate on or infer application semantics.

## Data handling and isolation

Tracer separates data collection from analysis.

- Execution signals are captured locally and processed into structured telemetry
- Only metadata required for analysis is transmitted
- Payload data is never inspected or exported
- Correlation is based on operating system identifiers (PIDs, cgroups, namespaces)

This design minimizes data exposure while preserving execution insight.

## Performance considerations

Tracer's eBPF-based collection is designed to minimize overhead:

<CardGroup cols={2}>
  <Card title="Low latency" icon="bolt">
    eBPF probes execute in kernel space with low latency
  </Card>
  <Card title="Efficient filtering" icon="filter">
    Event filtering reduces data volume at the source
  </Card>
  <Card title="Scales well" icon="chart-line">
    Collection overhead remains low even with many short-lived processes
  </Card>
  <Card title="No re-runs" icon="rotate">
    No pipeline re-runs are required to obtain telemetry
  </Card>
</CardGroup>

<Note>Measured overhead depends on workload characteristics but is typically low enough for continuous use in production environments.</Note>

## Security boundaries

Tracer is intentionally scoped.

<Warning>
**It does not:**
- Modify application behavior
- Control execution or scheduling
- Start, stop, or change resources
- Replace IAM, RBAC, or cloud security controls
</Warning>

Security ownership remains with the operating system, container runtime, and cloud provider. Tracer observes execution behavior within those boundaries.

## When to read this page

This page is most relevant if you:

- Need to understand how Tracer observes execution safely
- Operate in regulated or security-sensitive environments
- Evaluate eBPF-based tooling for production systems
- Want clarity on what data Tracer does and does not collect

<CardGroup cols={3}>
  <Card href="/technology/tracer-collect">
    <span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
      <span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #FB68E1, #953E96)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>collect</span>
    </span>
    <br />
    Implementation details
  </Card>
  <Card href="/technology/tracer-tune">
    <span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
      <span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #38BDA4, #76E9D3)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>tune</span>
    </span>
    <br />
    Execution analysis and optimization
  </Card>
  <Card href="/technology/tracer-sweep">
    <span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
      <span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #4436BD, #5646E2)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>sweep</span>
    </span>
    <br />
    Cloud waste discovery
  </Card>
</CardGroup>

<div style={{ height: '50vh' }}></div>

