> ## Documentation Index
> Fetch the complete documentation index at: https://docs.garnet.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Trust & security
> What Garnet accesses, why eBPF in CI is safe by design, and how the Run Profile is handled.
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](https://jibril.garnet.ai), 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](/reference/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 |
The action does **not** require `contents: write`, `actions: write`, or access to any repository secret beyond the token you explicitly pass.
## Overhead & footprint
* 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](https://app.vanta.com/garnet.ai/trust).