Skip to main content
aiAxonIQ is multi-tenant. Each organization is a tenant, and many tenants share the same ingest path and the same data stores. This page explains how one organization’s data is kept apart from another’s, and what that means for how you set up yours.
The short version. Your organization is decided by the credential you present — your license key when sending, your session when reading — and never by anything inside the data or the request. Telemetry is stored in shared tables, and every read the product makes is scoped to one organization by the API.

​
Two ends of one rule

Isolation rests on one rule applied at both ends of the pipeline: the tenant comes from a credential the platform verified, not from a value the caller supplied.
1

At ingest: the license key decides

The receiver validates the license key on every request and looks up the organization it belongs to. That organization is attached to the data before it is queued for storage, and every record written carries it.Nothing downstream reads tenancy from the payload. A resource attribute, a header or a field in the telemetry that names a different organization has no effect on where the data lands.
2

In the product: the session decides

When you read data, your organization is taken from your signed session. Many API endpoints accept a tenantId parameter for historical reasons; it is always overwritten from the session, and naming an organization other than your own returns 403 rather than being silently corrected.

​
How reads are scoped

Telemetry for every organization is stored in shared tables, so isolation does not come from each tenant having its own database. It comes from the API:
  • Telemetry queries — logs, metrics, traces and the rest — go through a single query layer in the API that requires an organization and applies a tenant filter to the query. Queries the product builds for you, such as dashboard panels built from the query builder, carry that filter as part of how they are generated. The build checks that telemetry is read only through that layer.
  • Log full-text search runs against shared search indices, with a filter on your organization’s id applied to every search.
  • The AI knowledge base stores documents in a shared vector collection, and every lookup is filtered by organization. The AI service takes the organization from a binding issued by the API, and refuses a request that tries to name its own.
  • The control plane — users, keys, dashboards, alert rules — is looked up by the organization in your session.
Isolation is enforced in the API layer. It is a property of the software that reads the data, not of separate storage per tenant. If your requirement is that your telemetry is stored physically apart from every other customer’s, that is a deployment question — a self-hosted deployment is the answer available today. See Onboarding: self-hosted.

​
The AI assistant cannot change your tenant

AI features that read telemetry do so through the same scoped query path as the rest of the product. A model can only ask for data through a fixed set of tools, and the organization those tools read is set by the API from your session. Text in your logs that tries to instruct a model to read another organization’s data fails on that scope, not on the model’s judgement.

​
What this means for you

Data sent with a key lands in the key’s organization, always. You cannot route some services to a second organization by tagging them — use that organization’s key. And if a key leaks, whoever holds it can send data into your organization, but cannot read anything from it. Revoke it; see Create a license key.
Every member of an organization can read all of its telemetry. Isolation is between organizations, not between people or services inside one. If some telemetry must not be visible to some members, put it in a separate organization. See Roles and permissions.
A user account can hold memberships in several organizations, with a different role in each. A session is scoped to one organization at a time; switching issues a new session, so a token from one cannot be used in another. See Organizations and multi-tenancy.
When aiAxonIQ support is granted access to your organization, it is to your organization only, read-only unless write access is requested for that grant, time-limited, and recorded in your audit log. See Security overview.

​
Choosing between one organization and several

Creating another organization requires the Owner role; during the private beta it is arranged with your account contact.

​
Next

Organizations

Memberships, switching, and separating environments.

Data handling

Retention, deletion and what leaves the platform.

Security overview

Authentication, credentials, audit and transport.