Mistral Security: What Workspaces, SCIM, and Admin-Role API Keys Cover
Mistral organizes access around an organization containing workspaces, with roles, groups, SCIM provisioning, and SAML single sign-on managed from the Admin Panel. Workspaces carry their own usage limits and rate tiers, and Admin API calls require a key held by an Admin-role user. All of that governs who joins the account and which workspace they land in. The inference request itself authenticates with a bearer key that names no human.
Mistral's administrative model has three layers stacked on top of each other. An organization holds workspaces. Workspaces hold members, per-workspace usage and rate limits, and their own governance boundary across Studio and Vibe. Identity and access management inside the organization covers "users, roles and permissions, groups, and automated provisioning with SCIM," per Mistral's admin documentation. I want to walk through what each layer secures, then the request that passes through all three without being evaluated by any of them.
TL;DR
- Mistral scopes access through an organization containing workspaces, each with its own membership, usage tracking, and rate tiers.
- SAML single sign-on and SCIM provisioning connect the organization to an enterprise identity provider, so joiners and leavers flow from the IdP.
- Admin API requests must authenticate with a credential belonging to a user holding the Admin role in the organization.
- Audit logs are Enterprise-plan only and record administrative events. An inference call authenticates with a workspace bearer token that carries no user identity into the request.
Workspaces are the governance boundary
The workspace is where Mistral puts the blast radius. Mistral describes workspaces as the way to "structure and govern work across workspaces in Studio and Vibe, with per-workspace usage and limits," and billing controls let an administrator "set limits and rate tiers per workspace."
That gives a security architect two real levers. Separating a customer-support workload from an engineering workload into distinct workspaces means a leaked credential from one cannot address the other, and a spend cap on the workspace bounds the cost of a runaway agent loop. Rate tiers per workspace act as a crude but genuine denial-of-service control.
The lever workspaces do not give you is content scope. A workspace is a container for members, keys, and quota. It carries no notion of which data classifications may enter a prompt sent from inside it, so two engineers in the same workspace have identical model access regardless of what either one is about to paste.
SSO and SCIM connect the account to the IdP
Mistral supports SAML single sign-on with a documented quickstart, plus SCIM for automated provisioning. Both matter more than they usually get credit for. SCIM means a deprovisioned employee loses Mistral access when the identity provider says so, rather than when someone remembers to open the Admin Panel, and that closes the single most common access-review finding in an AI tooling audit.
Roles, permissions, and groups are managed in the same place. The Admin API exposes users, workspaces, groups, and roles programmatically, and Mistral requires that "Admin API requests require an API key that belongs to a user with the Admin role in the Organization."
Binding an administrative credential to a human's role is a stronger design than a free-floating org-level token, and it is the right default. It also means that credential inherits the human's authority for as long as it exists, so rotation discipline and role reviews are the same control rather than two separate ones.
Audit logs cover the account, on Enterprise only
Mistral's audit logs are "available on Enterprise plans" and "enabled by default for all Workspaces," with entries carrying a timestamp, an actor that can be a user or an API key, an event, a target, and metadata. The documented events cover authentication and SSO flows, API credential creation and deletion, organization and workspace changes, user management, settings changes, and Vibe conversation lifecycle.
Two operational facts belong in any control design. Log export is not supported, so the Admin Panel is the read surface. And the published event list is administrative, so the inference traffic itself sits outside it. I walk through what that means for incident reconstruction in what Mistral audit logs record.
The credential is the identity the API sees
Follow a request from a production application. A user signs in through Okta or Entra ID. The application resolves their identity, checks their entitlements, assembles a prompt containing an account record, and calls Mistral. What goes on the wire is a POST to the chat completions path on api.mistral.ai, with an Authorization header carrying a bearer token that is the workspace API key, a model name such as mistral-large-latest, and the message array holding the assembled prompt.
Nothing in that request names the human. Mistral authenticates the credential, confirms the workspace has quota, and serves the completion. Whether the caller was a support agent authorized to see one customer's record or a contractor whose access was revoked an hour ago produces an identical request on the wire.
That is the post-authentication gap stated in a header. Identity was verified once at the application's front door and never consulted again on the traffic that carried the sensitive payload. Some teams try to close it by adding a user field to the request body, which is application-asserted metadata rather than a verified claim, and the same weakness applies there as anywhere else the application vouches for itself.
What the deployment choice does and does not change
Mistral offers hosted access through La Plateforme, cloud-partner deployments, and self-deployment of open-weight models. Moving from the hosted API to a self-hosted server changes the network path, the data residency position, and who patches the serving stack. The authorization model on the request stays the same, because an OpenAI-compatible inference server accepts a bearer token and answers.
Self-deployment also inherits the serving-layer exposure that the hosted service absorbs on your behalf, which is the theme running through prompt injection risk in Mistral deployments and the gateway shapes described in Mistral API gateway patterns.
What a request-level control has to evaluate
Closing the gap means something on the request path that resolves the authenticated principal independently of the calling application, reads the role and group membership that principal holds in the identity provider, classifies the content about to enter the prompt, evaluates all three against a versioned policy, and writes a signed record of the decision. Workspaces, SCIM, and role-scoped admin keys are the inputs to that evaluation. They cannot perform it, because none of them sits on the inference request.
DeepInspect
This is exactly what DeepInspect does. DeepInspect is a stateless proxy that sits inline between authenticated users or agents and any HTTP LLM endpoint, including La Plateforme and self-deployed Mistral models behind a single policy.
Every request gets an identity check against the identity provider, a classification pass over the prompt content, and a policy decision that allows or blocks before the model is reached, with a signed audit record per decision that exports into a SIEM. Mistral's workspaces keep bounding quota and membership, SCIM keeps deprovisioning departed staff, and the Enterprise audit log keeps recording who changed the account. DeepInspect covers the layer none of them reach, the individual request and the data inside it. Book a technical deep dive at deepinspect.ai.