Garnet asks for kernel-level access in your CI to record what runs. Here’s exactly what that means, why it’s safe, and what it can and can’t touch.
The short version
Garnet runs Jibril, a lightweight eBPF sensor, alongside your workflow. Its programs are kernel-verified and sandboxed, it adds under 2% CPU overhead, and it needs no proxy and no code changes. The only secret it uses is the API token you pass it — it never reads your other secrets, and never writes to your repo.
Jibril observes syscall-level network, process, and file activity with lineage and timing. The control plane ingests that telemetry, evaluates runtime checks, and publishes the Run Profile to the PR, the dashboard, and any webhooks.
eBPF safety model
Jibril needs privileged access to attach eBPF programs. That access is narrower than it sounds:
- Kernel-verified — every eBPF program is checked by the kernel verifier before it loads.
- Sandboxed — programs run in a restricted execution environment and cannot perform arbitrary writes.
- Observe-only — Jibril reads syscall-level events; host isolation is preserved.
Why sudo
Attaching eBPF programs at the kernel level requires sudo during install. ubuntu-latest GitHub runners include it by default. That’s the extent of the elevated access — it’s used to load the sensor, not to modify your build.
Permissions
The GitHub Action requests only what it needs to record a run and post the result:
| Permission | Required | Why |
|---|
contents: read | Yes | Access workflow context and repository metadata |
pull-requests: write | Recommended | Post the Run Profile as a PR comment |
contents: write, actions: write, or access to any repository secret beyond the token you explicitly pass.
- Under 2% CPU overhead.
- No sidecars, no proxies, no build-time dependencies.
- Runs in the background and profiles subsequent steps — no reordering of your pipeline.
Data handling
A Run Profile contains process, network, and file metadata — process lineage, outbound domains and IPs, and file paths — tied to the commit, actor, and workflow. It does not capture the contents of your source or your secrets.
Store your GARNET_API_TOKEN in CI secrets or a vault — never commit or log it in plain text.
Compliance
Garnet is SOC 2 Type II. Current controls, subprocessors, and security documentation are available in the Trust Center. 
