> ## 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.
# Security model
> Written to be handed to a security team: what the zero-code agent can see, what it sends, what privilege it holds, and what it never does.
This page is written to be forwarded to a security reviewer without editing.
It states what the agent can see, what it sends, what privilege it holds and
why, and what it never does.
The agent is upstream OpenTelemetry eBPF Instrumentation, unmodified,
Apache-2.0.
**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.
## Summary for a reviewer
| Question | Answer |
| :------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Does it run as root? | **Not required.** It runs with an explicit Linux capability set. On Kubernetes the container is **not** privileged. |
| Does it need `CAP_SYS_ADMIN`? | **No.** It is in no profile, and is reachable only through an explicit opt-in flag on the highest profile. |
| Can it crash the kernel? | eBPF programs are checked by the in-kernel verifier before loading. A program that could crash or loop unbounded is rejected and never runs. |
| Does it modify traffic or processes? | **No**, on the lower two profiles — they are read-only observers. The highest profile injects W3C trace-context headers into outbound requests, and nothing else. |
| Can it see decrypted TLS payloads? | **Technically yes.** It hooks `SSL_read` / `SSL_write`. It is configured to extract **metadata only**; payload capture is off and this distribution offers no supported way to turn it on. |
| Where does data go? | **One destination**: your aiAxonIQ endpoint, over TLS, authenticated with your license key. |
| Does it phone home? | **No.** No analytics, no usage telemetry, no update check. |
| What does it leave behind on removal? | Nothing in the kernel. eBPF programs are released when the process exits. |
## Privilege
The agent holds a named **capability profile** rather than root. Full detail,
including what each capability is for, is on
[Capability profiles](/zero-code/profiles).
| Profile | Capabilities | Purpose |
| :------------------------------ | :--------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------- |
| **A — network** | `cap_bpf`, `cap_net_raw`, `cap_perfmon` | Network flow metrics. No process introspection, no payload access. |
| **B — application** *(default)* | `cap_bpf`, `cap_checkpoint_restore`, `cap_dac_read_search`, `cap_net_raw`, `cap_perfmon`, `cap_sys_ptrace` | RED metrics, spans, service inventory. |
| **C — tracing** | B plus `cap_net_admin` | Adds outbound trace-context injection. |
**`CAP_SYS_ADMIN` is near-equivalent to root, and is in no profile.** It is
refused outright for A and B, and on C requires an explicit opt-in flag. A
flag that appeared to be accepted and quietly did nothing is how an operator
comes to believe they granted less than they did, so refusal is loud.
**There is one trap worth naming.** Upstream documents that on **AKS and
EKS**, the straightforward path requires `CAP_SYS_ADMIN` *unless* the node
sets `kernel.perf_event_paranoid=1`. That means the easy path on the two
largest managed Kubernetes platforms grants near-root on every node.
**Set the sysctl instead.** Preflight reports which situation you are in.
## What the agent can see
It hooks TLS library functions, so at that boundary it observes **plaintext**:
HTTP headers including `Authorization`, cookies, request and response bodies,
and SQL statement text.
This is the sharpest question in any review and it deserves a direct answer:
**the agent's position lets it see credentials in flight.** What follows is
what stops that becoming data anyone holds.
## What the agent sends
Metadata only.
| Setting | Value | Effect |
| :------------------- | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------- |
| Payload capture | **Off** | Request and response bodies are never exported. |
| Unmatched routes | Reduced to patterns | An identifier in a path becomes a route shape, so it never leaves the host. |
| Ignored patterns | Health and metrics endpoints | Dropped entirely. |
| Exported per request | Method, route pattern, status, duration, peer service, and host or Kubernetes resource attributes | — |
**Payload capture is off and there is no supported way to enable it here.**
That is a property of this distribution's configuration, not of the upstream
agent — which is exactly why the distribution exists. A reviewer should
verify it rather than take it on faith: the generated configuration is a
plain file, and the audit tool reports the running agent's effective
settings.
## Where the credential lives
The license key is a bearer credential for your ingest surface, and is handled
as one:
* **Never** written into any generated configuration file, systemd unit,
Compose file or Helm values file. This is asserted by tests, not by policy.
* On Kubernetes it is a **Secret**, injected as an environment variable. It is
never in the ConfigMap — so inspecting the ConfigMap remains a safe debugging
step, which is also asserted by a test.
* On Linux it is in a root-owned environment file with mode `0600`.
* **Redacted** in every diagnostic the tooling prints, including support
bundles.
* You can supply your own pre-existing Kubernetes Secret, in which case the
chart never sees the value at all.
This is partly inherited from upstream: OBI reads OTLP headers **only** from
the environment, and its configuration structure explicitly cannot carry them.
There is no config path that could leak the credential even by mistake.
### Scope the key
**A DaemonSet places the credential on every node.** That is a materially
broader exposure than one application's configuration, and it deserves its
own key.
Issue a license key restricted to **traces and metrics**, and revoke it
independently of your primary ingest key. The receiver enforces the allowed
signals per key, so a leaked agent key cannot be used to write logs or to
read anything. See [Create a license key](/get-started/license-keys).
## Kubernetes posture
The rendered DaemonSet:
* `privileged: false`
* `capabilities: drop: [ALL]`, then adds exactly the profile's set
* `readOnlyRootFilesystem: true`
* `hostPID: true` — **required**. Without it the agent shares no PID namespace
with the workloads it observes, sees only itself, and silently reports
nothing.
* `hostNetwork` — **only** on profile C
* RBAC: `list` and `watch` on pods, services, nodes and replicasets.
Read-only, cluster-scoped, used solely to decorate telemetry.
Everything above is inspectable before you install anything — see
[Inspect before you install](/zero-code/kubernetes#inspect-before-you-install).
**OpenShift.** A minimal `SecurityContextConstraints` ships with the chart. It
grants host PID access and the capability set, sets
`allowPrivilegedContainer: false`, and is bound to that release's ServiceAccount
by name rather than to a group. The alternative — which is what happens without
it — is attaching the workload to the cluster's `privileged` SCC. See
[OpenShift](/zero-code/openshift).
## Network
* Exactly **one** outbound destination: your configured OTLP endpoint, over
TLS.
* **No inbound listeners** are opened by this distribution's configuration.
* Egress-restricted networks need that one host allowed, plus one-time access
to the upstream release host at install time.
## What has not been reviewed
**No external security review has been performed.** The agent holds kernel
capabilities on every node it runs on. This distribution ships least-privilege
defaults, an automated audit tool and this document — and nobody outside the
engineering team that built it has reviewed the result.
If your process requires third-party assurance before granting kernel
capabilities in production, that requirement is not yet met. Raise it with
your account contact rather than inferring an answer from this page's
thoroughness.
Two further limits worth stating to a reviewer:
* **TLS library coverage is unmeasured.** The agent hooks OpenSSL. Statically
linked TLS, BoringSSL, rustls, GnuTLS and NSS are each a potential gap. The
consequence is not exposure but *absence* — those services are simply not
observed. See [Known limitations](/zero-code/limitations).
* **Scale validation is single-node.** Behaviour has been exercised on a real
cluster, but not across a large fleet or under a soak test.
## Verifying it yourself
A reviewer should not have to take this page's word for any of it:
The preflight tool reads the host. It installs nothing, sends nothing and
loads no eBPF program — it reports kernel, BTF, architecture, capabilities
and the perf-event setting.
The audit tool reports the privilege the agent is *actually* running at, so
"we intended profile B" can be checked rather than assumed.
On Kubernetes, render the chart and read the security context before applying
anything. Nothing about the deployment is opaque.
## Next
The three levels and how to choose.
Everything the agent does not do, stated plainly.
Where it is validated, expected, limited and unsupported.