---
icon: material/key-outline
title: "Authentication & Access"
---

How the agent authenticates, how API keys are issued and rotated, vulnerability handling, security review, internal access, and analytics-tool credentials.

??? tenx-auth "How does authentication work"

    **The agent and apps** use a scoped, rotatable account API key (the `X-10X-Auth` header), never a shared master credential. The same key authenticates any edge or cloud app sending metrics. The key authenticates the control surface only; it is not what the engine checks to run, which is the [license token](https://doc.log10x.com/manage/license/){target="_blank"} it verifies offline.

    **Getting a key** runs through the [MCP sign-in](https://doc.log10x.com/apps/mcp/tools/account/signin/){target="_blank"}, an [Auth0](https://auth0.com/){target="_blank"} device flow: authorize in the browser, and the key is written to `~/.log10x/credentials` at mode 0600. The scopes requested are the standard OIDC set (`openid profile email offline_access`), identity claims only. The [REST path](https://doc.log10x.com/api/manage/){target="_blank"} mints the same key for automation.

    **Rotation** replaces a key on demand, and the previous one stops working immediately: nothing caches an authorization decision. See [API keys](https://doc.log10x.com/manage/api-keys/){target="_blank"}.

    **Access scoping:** the key belongs to the account and reaches every [environment](https://doc.log10x.com/manage/environments/){target="_blank"} that account can see. The header decides the target: bare for the default environment, `<API_KEY>/<ENV_ID>` to name one. Permission level (`OWNER`, `WRITE`, `READ`) resolves per environment, so one key can own one and only read another. Separate dev, staging and prod into their own environments to separate the data; the credential stays one, and rotating it is account-wide.

??? tenx-auth "How are vulnerabilities handled"

    Reports go to [security@log10x.com](mailto:security@log10x.com) and get a first response within 24 hours, with remediation targets of 48 hours for CVSS 9 and above and 30 days for everything else. [Report a vulnerability](../../security/index.md#report-a-vulnerability) holds the full statement.

    Fixes ship as a new engine release, so applying one is an upgrade on your side. Every release from 1.1.73 onward carries a [CycloneDX SBOM](../../security/sbom.md) per engine flavor, which is what lets you scan the artifact you run against your own advisory feed rather than waiting on ours.

    **Attack surface context:** the Reporter tails logs as a DaemonSet and listens for nothing. The Receiver takes events from the forwarder beside it: with Fluentd, Fluent Bit, Logstash, the OpenTelemetry Collector and Vector it accepts them on a TCP port, bound on all interfaces in the pod's network namespace, so anything able to route to the pod IP can reach it and a NetworkPolicy is the control that narrows it; with Filebeat it runs as a child process of the forwarder over stdin, stdout and a unix socket, with no TCP port at all. Outbound connections are the metrics push to the backend the pipeline configures, plus, on a licensed deployment that names an endpoint, a best-effort startup license check and engine telemetry to the log10x gateway. None carry log content, and [Telemetry](../../security/telemetry.md) names every field each one sends.

    **Container security:** Deployment model varies by forwarder. OTel Collector, Logstash, Vector, Fluentd, and Fluent Bit run the Receiver as a separate [sidecar container](https://doc.log10x.com/engine/launcher/sidecar/#sidecar-container){target="_blank"} (non-root, read-only root filesystem, independent resource limits). Filebeat [embeds](https://doc.log10x.com/engine/launcher/sidecar/#embedded-process){target="_blank"} 10x as a child process within the forwarder container, inheriting its security context. The Reporter always deploys as a standalone DaemonSet pod, independent of the forwarder container. See [Deployment Models](https://doc.log10x.com/engine/launcher/sidecar/#deployment-models){target="_blank"} for details.

??? tenx-auth "Can we do a security review before purchasing"

    Most of a review can be done without asking, which is faster than scheduling one. The evaluation needs no account and no signup, so the cheapest review is to run the engine and packet-capture it: [Verifying](../../security/verifying.md) is that test written out.

    Published, no request needed:

    - [Security pages](../../security/index.md), the product answers a SIG Lite or CAIQ asks for
    - [Telemetry](../../security/telemetry.md), every field that can leave a deployed engine, with a JSON companion
    - [SBOM](../../security/sbom.md), CycloneDX JSON per engine flavor on every release from 1.1.73 onward
    - [Helm charts](https://github.com/log-10x/helm-charts){target="_blank"}, the deployment as it actually ships

    Assessing the container images yourself needs no permission from us. For an architecture conversation, or a questionnaire on your own paper, write to [security@log10x.com](mailto:security@log10x.com).

??? tenx-auth "Who at Log10x can access my metrics data"

    **Evaluation on the hosted backend:** it holds aggregated metrics only, never log content, and it is not a production destination. Questions about it go to [security@log10x.com](mailto:security@log10x.com).

    **By default (your own TSDB):** Log10x has zero access to your infrastructure, metrics, or dashboards.

??? tenx-auth "How are analytics tool credentials managed"

    API keys for Splunk, Datadog, GitHub, etc. remain in your infrastructure, never transmitted to log10x.

    10x runs within your environment and connects to analytics tools using your existing network access.