> ## 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 overview
> How aiAxonIQ authenticates people and telemetry, authorizes actions by role, separates organizations, stores credentials, records changes and protects traffic in transit.
This page summarises the security controls aiAxonIQ implements today, for a
security reviewer or an administrator deciding how to roll it out. Each section
links to the page with the detail.
**This page describes behaviour, not certifications.** aiAxonIQ makes no
compliance attestation in this documentation. Where a control depends on
your release or on how your deployment is configured, the section says so.
## Authentication
aiAxonIQ has two credentials, and they are not interchangeable.
| | License key | Session |
| :----------------- | :---------------------------------------------------- | :-------------------------------------------------------- |
| Represents | Your organization, for sending telemetry | One person, at their role |
| Used for | Ingest only | The dashboard and the API |
| Can read your data | No | Yes, within the person's role |
| Lifetime | Until revoked; newer releases give new keys an expiry | 30-minute access token, within a session of up to 14 days |
**Sessions.** Signing in issues a short-lived access token — 30 minutes — and a
refresh token. The browser refreshes the access token while you are active; a
session can be refreshed for at most 14 days before you must sign in again. In
the browser both are held in `HttpOnly` cookies, so page scripts cannot read
them, and marked `Secure`, so they are sent only over HTTPS. Tokens are signed
with HS256 using a secret held by the server.
A token is not accepted on its signature alone. Every request is also checked
against a live session record, so these take effect on the next request rather
than when the token expires:
* **Sign out everywhere**, which invalidates every session you hold.
* **A role change or a removal** by an Admin or Owner, which ends that member's
sessions.
* **A deactivated account.**
If that check cannot be made — for example, if the session store is
unreachable — the request is refused rather than admitted.
Passwords are stored as bcrypt hashes. One-time email codes are available as an
alternative to a password; their failure responses are deliberately
indistinguishable, so they cannot be used to discover who has an account.
**License keys** are organization-wide ingest credentials. A leaked key can
send telemetry into your organization; it cannot read data, change
configuration or see your users. Depending on your release, new keys carry an
expiry — one year by default — and can be rotated. Keys created before that
remain valid until revoked.
The full comparison, and how to use each, is on
[Authentication](/get-started/authentication).
## Authorization
Every membership carries one of five roles — Viewer, Editor, Admin, Owner, and
Auditor, which can read the audit log and change nothing. The role is read from
your signed session, never from a header or the request body, and every
permission is checked by the API rather than only hidden in the interface.
* You can grant a role no higher than your own; only an Owner can grant Owner.
* An Admin cannot demote an Owner.
* Roles control what you can **do**, not what you can **see**: every member of
an organization can read all of its telemetry. If some data must be hidden
from some people, the boundary is a separate organization.
See [Roles and permissions](/concepts/roles).
## Tenant isolation
Each organization is a tenant. Your organization is determined from your
license key at ingest and from your session in the product — never from a
value in the telemetry itself or in a request. Telemetry for all organizations
is stored in shared tables, and reads are filtered by organization in the API
layer.
The mechanism, and what it means for how you structure your organizations, is
on [Tenant isolation](/security/tenant-isolation).
## Credential handling
| Credential | How it is stored |
| :------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Passwords | bcrypt hash |
| License keys | bcrypt hash, used to verify every ingest request. A separately sealed copy lets an Admin reveal a key again; a key minted without that copy can only be rotated, not re-shown. |
| Refresh tokens | SHA-256 hash |
| Service-account tokens | Hash only. The token is shown once and never logged. |
| Notification channel credentials — webhook URLs, routing keys, API keys, SMTP details | Sealed with authenticated encryption when saved, under a key the server holds. The channel list never returns them. |
Revealing a license key, creating one, revoking one and changing a channel all
require Admin, and are recorded in the audit log.
**Channels saved by an older release may be stored unsealed until they are
next saved.** Saving a channel again seals it.
## Audit log
Changes to your organization are recorded: invitations, removals and role
changes; license keys created, rotated and revoked; configuration such as alert
rules and notification channels; and support access. Auditor, Admin and Owner
can read and export it.
The audit log records control-plane changes, not every search or dashboard
view. It is subject to retention, so export it if you need records for longer.
See [Audit log](/guides/audit).
## Support access
aiAxonIQ support can be granted access to your organization to investigate a
problem. Each grant:
* requires the staff member to record a **reason** before the access link
exists;
* is **read-only** unless write access is explicitly requested for that grant;
* uses a single-use link valid for 15 minutes, which opens a session lasting
at most 30 minutes;
* is recorded in **your** audit log, with the access level and the reason.
## Transport
* The product and the ingest endpoint on aiAxonIQ Cloud are served over HTTPS
only — TLS 1.2 or 1.3 — and plain HTTP is redirected to HTTPS. Responses carry
a Strict-Transport-Security header.
* External ingest is **OTLP over HTTP, over TLS**. On aiAxonIQ Cloud the OTLP
gRPC listener is bound to the host's loopback interface and is not reachable
from outside; send OTLP/HTTP. See [Endpoints and errors](/send-data/endpoints).
* Traffic between aiAxonIQ's internal services stays on the deployment's
private network, and the AI service is reachable only from the API with a
service credential.
## What happens to detected credentials
In current releases the ingest receiver scans incoming telemetry for
credentials — bearer tokens, private-key blocks, URL-embedded passwords, known
token formats, and attributes named like `authorization`, `password` or
`token` — and replaces them before the data is queued for storage. This is
pattern-based and does not catch everything; see
[Data handling](/security/data-handling#credentials-in-your-telemetry).
## Reporting a security issue
Report a suspected vulnerability or a leaked credential to your account contact
or through support. If a license key has leaked, revoke it first — see
[Create a license key](/get-started/license-keys) — and then tell us.
## Next
How one organization's data is kept from another's.
What is collected, how long it is kept, and how it is deleted.
For operators running aiAxonIQ themselves.
What the eBPF agent can see and what it sends.