Skip to main content
Three named privilege levels. The point is that the choice is made, with the trade-off stated where it is made, rather than defaulting to whatever is most permissive.
Availability. The zero-code agent is an early-access distribution. It is installable, upgradable and tested, and it is not yet an integrated part of the product: there is no dashboard page for it, no in-product installer and no self-service download. Ask your account contact for access.Its telemetry, once flowing, is ordinary OTLP and needs nothing special — it appears in Services, Traces and Metrics exactly like SDK telemetry does. That is the design rather than a shortcut.
The short version: use profile B. It is the default, it needs neither CAP_SYS_ADMIN nor CAP_NET_ADMIN, and it gives you RED metrics, per-service spans and a service inventory.Move to C only when you have uninstrumented services whose traces must stitch into one, and a security review that approved CAP_NET_ADMIN on every node.

​
Comparison

​
The capabilities, measured

These correct upstream’s published documentation, and the correction was established by running the binary.Application observability. Upstream documents five capabilities. The agent refuses to start without CAP_CHECKPOINT_RESTORE as well — and because it names its requirements incrementally, the omission stays invisible until the first five are granted.Network metrics. Upstream documents two. With exactly those two, the agent’s own gate passes and the kernel then rejects the socket-filter program. CAP_PERFMON is required in practice.The second is the more dangerous, because it is not a refusal to start: the agent comes up, reports healthy and produces nothing. An operator carefully following upstream’s least-privilege line lands exactly there.

​
Profile A — network

Network flow metrics from a socket filter. No process introspection, no executable scanning, no access to decrypted payloads. Choose it when an operator wants traffic visibility and will not grant more. It is the profile that gets approved where nothing else would.
Profile A is not available on Kubernetes. The upstream Helm chart hardcodes a six-capability floor for unprivileged mode and ignores the security context when the container is not privileged, so a three-capability profile cannot be expressed through it without forking.Both the configuration generator and the chart refuse it by name rather than quietly widening the grant to six and still calling it “network only”. On Kubernetes your choice is B or C.

​
Profile B — application (default)

Designed to be genuinely useful on its own, not a teaser for C. That is a deliberate product decision. At a security-conscious customer, B is the only profile that will be approved — so if it were crippled, those customers would either grant near-root or not deploy at all. B is where the value is. You get: RED metrics, per-service server and client spans, protocol decoding across HTTP/S, gRPC, SQL, Redis, Kafka and more, a service inventory including services nobody instrumented, and Kubernetes decoration. You give up: outbound trace-context injection. The agent reads an incoming W3C traceparent and joins that trace, but cannot add one on the way out.
Whether that matters depends on your estate. If your services already propagate traceparent — most modern frameworks do, even without an observability SDK — profile B produces joined, end-to-end traces.If nothing propagates today, B gives you excellent per-service telemetry and traces that do not stitch across service boundaries. Check one request path before assuming which case you are in; it is usually the first.

​
Profile C — tracing

Adds CAP_NET_ADMIN, which lets the agent inject trace context via TC programs so chains through uninstrumented services become a single trace. What it costs:
  • CAP_NET_ADMIN on every node — network administration, including interface and routing changes.
  • Host networking — the pod shares the node’s network namespace.
  • A kernel tracing filesystem mount.
Do not choose C because “tracing” sounds more complete than “application”. Choose it because you have uninstrumented services whose traces must join, and you have weighed granting network administration on every node against that.If the services that need joined traces are ones you can change, adding the OpenTelemetry SDK to those few is a smaller privilege grant than C across the fleet.

​
CAP_SYS_ADMIN is never a default

CAP_SYS_ADMIN is near-equivalent to root. In the agent it would additionally enable Go-level trace-context propagation by writing into process memory. It is in no profile. It is refused outright on A and B, and on C it requires an explicit opt-in flag. See Security model for the managed-Kubernetes trap that makes this matter in practice.

​
Choosing

1

Start at B

The default, and the right answer for most estates.
2

Drop to A only if B will not be approved

You lose spans and the service inventory and keep network flow metrics. Linux and Docker only.
3

Move to C only on evidence

Install B first. If your traces already join, you are done. If they do not and the services involved cannot be instrumented, C is the answer.

​
Verifying what you actually got

Intent and reality are different things, and the gap is the point of the audit tool: it reports the privilege the running agent actually holds. Run it after any install, and after any upgrade — a chart default that changed underneath you is exactly the kind of thing nobody notices.

​
Next

Security model

The full statement for a security review.

Install on Linux

Preflight, install, verify.

Install on Kubernetes

The chart, its values, and what it renders.