> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Capability profiles
> Three named privilege levels for the zero-code agent, what each buys and costs, and why the default is designed to be enough on its own.
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
| | **A — network** | **B — application** *(default)* | **C — tracing** |
| :----------------------- | :-------------- | :------------------------------ | :-------------- |
| RED metrics | — | ✅ | ✅ |
| Per-service spans | — | ✅ | ✅ |
| Service inventory | — | ✅ | ✅ |
| Kubernetes decoration | — | ✅ | ✅ |
| Network flow metrics | ✅ | — | — |
| Trace-context **read** | — | ✅ | ✅ |
| Trace-context **inject** | — | — | ✅ |
| Reads decrypted payloads | No | Metadata only | Metadata only |
| Host networking | — | — | Required |
| Available on Kubernetes | **No** | ✅ | ✅ |
| Capabilities | 3 | 6 | 7 |
## The capabilities, measured
```text theme={null}
A cap_bpf cap_net_raw cap_perfmon
B cap_bpf cap_checkpoint_restore cap_dac_read_search cap_net_raw cap_perfmon cap_sys_ptrace
C … B, plus cap_net_admin
```
**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](/zero-code/security#privilege) for
the managed-Kubernetes trap that makes this matter in practice.
## Choosing
The default, and the right answer for most estates.
You lose spans and the service inventory and keep network flow metrics.
Linux and Docker only.
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
The full statement for a security review.
Preflight, install, verify.
The chart, its values, and what it renders.