At a glance
- What you get: workloads isolated by Tenant, access by role, and every change and refusal on an append-only record.
- What you control: who is in your Organization, what each role and API key can do, and when your data is deleted.
- What we don't claim: that any model is free of hidden behaviour, or that its outputs are always right. We say where our claims stop.
Organizations and Tenants: how isolation works
Your company is an Organization in rackAI. Each Organization has its own sign-in realm, its own users and roles, and its own usage and activity records.
Inside an Organization you create Tenants. A Tenant is the unit of isolation: a team, an application or an environment. Each Tenant has its own:
- models, deployments, datasets, fine-tuned adapters and API keys;
- network boundary on the GPU cluster, closed by default, so its workloads can't reach other Tenants or the internet;
- GPU quota;
- prompt cache, keyed to the Tenant. Another Tenant can't use cache timing to learn what you sent, even within your own Organization.
Every API call and every inference request is checked against the Tenant it targets. If you don't have access to a Tenant, rackAI responds as if it doesn't exist.
Model deployments run on GPU capacity assigned to your Organization.
Identity and access
- Sign-in. Users sign in to their own Organization's realm with OpenID Connect.
- Roles. Built-in roles (admin, ML engineer, developer, viewer, billing admin and inference-only) apply at Organization or Tenant level. Every operation is denied unless a role you hold allows it.
- API keys. Each key belongs to one Tenant and carries a role, inference-only by default. You can't create a key with more access than you have. The secret is shown once, and we store only a keyed hash of it. Revoke a key and it stops working on the next request. Keys can be given an expiry date.
Activity and audit trail
Every change to your resources is recorded in the same transaction as the change itself. That covers deployments, models, datasets, fine-tuning jobs, API keys, credentials, Tenants and role assignments. Refused requests are recorded too. Each record says who acted, on what, when, from which request and with what result.
The record is append-only: the application can add and read entries but can't edit or delete them. Only retention removes them, after the period your Organization sets.
In the console, Activity shows your Tenant's records. You can filter them, open any event, and follow a single request across the change it made, the work it started and the usage it produced.
Your data
- Prompts and responses. Usage records hold token counts, timings and IDs, not the text of your prompts or responses.
- Training data and adapters. Datasets and fine-tuned adapters belong to the Tenant that created them and are used only for that Tenant's jobs and deployments. More on Your data and fine-tuning.
- Secrets you give us. Credentials such as model-hub tokens are encrypted with their own key, and the value is never shown back to you.
- Deletion. You can delete datasets, adapters, fine-tuning jobs and deployments at any time, and deleting a Tenant removes its workloads and stored files.
Models and the software supply chain
- Pinned versions. When a model is added, rackAI resolves it to an exact revision and records a digest of every file. Where the publisher provides digests, the files are checked against them.
- Read-only, offline weights. Model servers mount weights read-only. They have no route to the internet, and runtime usage telemetry is switched off.
- Fine-tuning in a closed room. Training jobs run with no network access, from a pre-installed, hash-pinned training runtime. They never execute code shipped with a model.
The rackAI FDE: an assistant that stays inside your permissions
The rackAI FDE answers questions about your deployments, usage and activity from your own platform data. It works through the same public API you use. It never has more access than the person using it, and it can't reach outside that person's Tenant and Organization. Its reads are read-only by construction, and checks run on what goes in, what comes back from tools, and what it says before it replies.
When it can make changes, it is limited to a short list of deployment actions. Each action is shown to you as a plan, and nothing runs until you confirm. Every step is recorded. More on the rackAI FDE.
Compliance and shared responsibility
rackAI's controls are designed to support the requirements a security or compliance programme sets. They don't make a customer compliant with any framework, and this page makes no certification claim.
What we don't claim
We don't claim that a model is free of undiscovered backdoors, that a model's publisher is trustworthy, or that outputs are correct or safe for any purpose. Our boundaries are checked at the platform level; they are not a claim against a compromised host, network or cluster. A security claim on rackAI should be something the platform derives and evidences, not a sentence someone wrote. We'll keep this page to that standard.