> ## 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.
# Known limitations
> Everything the zero-code agent does not do, why, and what to use instead — so you stop looking for something that was never there.
Stated plainly, so an evaluation does not spend a week discovering these one at
a time. Each says what to use instead.
**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.
## No in-process detail
**This is the boundary of the technique, not a gap to be closed in a later
version.** eBPF observes syscalls and library calls. It has no view inside
your functions, so it cannot produce:
* custom spans around your own operations
* business attributes — order id, customer tier, feature flag
* exception types and stack traces
* anything about work that never crosses a socket
**Use instead:** the OpenTelemetry SDK, in the services where you need it.
The two compose — the agent reads an incoming `traceparent` and joins the
same trace. See [Zero-code and the SDK together](/zero-code/why#use-both).
## Linux only
eBPF is a Linux kernel facility. No Windows, no macOS, and no serverless
platform where there is no node to install on.
**Use instead:** the OpenTelemetry SDK, or a Collector you run somewhere you do
control. See [Compatibility](/zero-code/compatibility).
## Profile A is unavailable 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 — which
would cost more than the profile is worth.
Both the generator and the chart **refuse it by name** rather than widening the
grant to six and still calling it "network only".
**Use instead:** profile B on Kubernetes; profile A remains available on Linux
and Docker. See [Capability profiles](/zero-code/profiles).
## TLS library coverage is unmeasured
The agent hooks OpenSSL. Statically linked TLS, BoringSSL, `rustls`, GnuTLS and
NSS are each a potential gap, and the full matrix has not been measured.
**This is the largest untested claim surface in the product.** Node.js
bundles its own OpenSSL; Rust's `rustls` is not OpenSSL. Both are known
risks rather than known failures.
It presents as **"some services are missing"** and never as an error — which
makes it easy to misdiagnose as a broken install. If a service you expected
is absent while its neighbours are present, suspect this first.
**Use instead:** the OpenTelemetry SDK in the affected services.
## One release per namespace
The agent ConfigMap has a fixed name, because the upstream chart consumes it as
a plain value rather than a template. Two releases in one namespace collide,
and Helm fails loudly.
This is a constraint you would want regardless: two DaemonSets both
instrumenting every process on every node would double the overhead and the
telemetry.
## `perf_event_paranoid` must be 1 or lower
Above that, the kernel denies perf-event access even with the right capability,
and the agent starts, holds every capability, reports healthy and **collects
nothing**.
Preflight treats it as a blocking failure. On managed Kubernetes it is a
node-level change, and on OpenShift a machine-config one — arrange it before
the rollout rather than after. See
[How eBPF works](/zero-code/ebpf#the-setting-that-catches-everyone).
## No published overhead figure
**We do not publish an overhead number, because one has not been measured on
a representative host.** The benchmark tool exists, and it refuses to present
numbers when it detects that probes did not attach — so the only figures
currently available describe an idle process, and publishing them would be
worse than publishing nothing.
**Use instead:** measure on your own hardware. See
[Performance](/zero-code/performance).
## No external security review
The agent holds kernel capabilities on every node it runs on. The distribution
ships least-privilege defaults, an automated audit tool and a security document
written for a reviewer — and nobody outside the 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 met today. See
[Security model](/zero-code/security#what-has-not-been-reviewed).
## Validated at single-node scale only
Behaviour has been exercised on a real cluster, Docker, Compose and Helm — but
not across a large fleet and not under a soak test. Large rollouts should be
staged.
## Not integrated with the product
There is no dashboard page for the agent, no in-product installer, no
onboarding step and no self-service download. Its telemetry appears in the
ordinary surfaces because it is ordinary OTLP, and everything else about
operating it happens outside the product.
## Coexistence with the AI-agent eBPF agent is unmeasured
aiAxonIQ also has an eBPF agent for LLM and AI-agent observability. **Both
attach probes to the same TLS library symbols**, and the zero-code agent
additionally decodes several GenAI APIs natively — a real overlap.
**Running both on one host is untested and not recommended** until the
convergence decision is made. If you are evaluating both, run them on
separate hosts. Talk to your account contact.
## Next
The questions an evaluation actually asks.
What drives overhead, and measuring it yourself.
Where it runs, and where it never will.