> ## 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.

# Tenant isolation

> How aiAxonIQ keeps one organization's telemetry away from another's: the tenant is set from your license key at ingest, and every read is filtered by organization in the API layer.

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.

<Info>
  **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.
</Info>

## 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.**

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.

<Note>
  **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](/onboarding/self-hosted).
</Note>

## 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

<AccordionGroup>
  <Accordion title="The license key is the boundary" icon="key">
    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](/get-started/license-keys).
  </Accordion>

  <Accordion title="Roles do not restrict telemetry within an organization" icon="user-shield">
    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](/concepts/roles).
  </Accordion>

  <Accordion title="One account, several organizations" icon="users">
    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](/concepts/organizations).
  </Accordion>

  <Accordion title="Support access is scoped and recorded" icon="headset">
    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](/security/overview#support-access).
  </Accordion>
</AccordionGroup>

## Choosing between one organization and several

| Requirement                                               | Use                                                                  |
| :-------------------------------------------------------- | :------------------------------------------------------------------- |
| Tell staging apart from production on the same dashboards | One organization, with a `deployment.environment` resource attribute |
| Some people must not see some telemetry                   | Separate organizations                                               |
| A customer of yours must not see another customer's data  | Separate organizations                                               |
| Separate plans, allowances or retention                   | Separate organizations                                               |

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

## Next

<CardGroup cols={3}>
  <Card title="Organizations" icon="building" href="/concepts/organizations">
    Memberships, switching, and separating environments.
  </Card>

  <Card title="Data handling" icon="database" href="/security/data-handling">
    Retention, deletion and what leaves the platform.
  </Card>

  <Card title="Security overview" icon="shield-halved" href="/security/overview">
    Authentication, credentials, audit and transport.
  </Card>
</CardGroup>