Mistral Audit Logs Record Who Changed the Account, Not Who Called the Model

Mistral's audit logging turns on by itself. The documentation states that audit logs are "available on Enterprise plans" and "enabled by default for all Workspaces," with the follow-up that "no setup is needed." Administrators read them in the Admin Panel. I want to walk through the five fields each entry carries and the event list Mistral publishes, because the shape of that list decides what an incident reconstruction can and cannot establish.

TL;DR

• Mistral audit logs are Enterprise-plan only and enabled by default for every workspace, with no configuration step.
• Each entry holds five fields: CreatedAt, an actor that can be a human user, an API key, or the system, an event, a target resource, and metadata.
• The documented events cover authentication and SSO flows, credential creation and deletion, organization and workspace changes, user management, settings modifications, and Vibe conversation lifecycle.
• Log export is not supported, so the Admin Panel is the read surface, and per-inference-request records are absent from the published event list.

The five fields in an entry

Mistral's audit logs documentation describes a chronological record of actions performed within an organization across Studio and Le Chat, covering user activity, credential usage, and security events.

Each log entry carries a timestamp in CreatedAt, an actor identifying who performed the action, an event naming the specific action, a target naming the resource affected, and a metadata field holding additional context.

The actor field is the interesting one. Mistral is explicit that audit logs "capture actions performed by both users and API keys," so an entry can name a human who signed in through SSO or an API credential that created another credential. Modeling a credential as a first-class actor is the correct design and more platforms should copy it, since it removes the pretence that every logged action traces back to a person.

What the event list covers

The documented event categories are administrative:

• Authentication events: sign-ins and SSO flows.
• API usage and credential management: credential creation and deletion.
• Organization changes: organization and workspace modifications.
• User management: invitations, role changes, and removals.
• Settings: configuration modifications.
• Vibe interactions: conversation creation and deletion.

Read that list against an incident. A workspace credential is created on a Monday. On Tuesday that credential issues forty thousand requests against mistral-large, several of them carrying customer records into the prompt. On Wednesday the credential is deleted.

The audit log holds two entries: creation and deletion. Between those points, forty thousand calls produced administrative history at the endpoints of the credential's life and nothing along its span. Vibe interaction events cover conversation creation and deletion rather than the content or the authorization of each turn.

Export is not supported

The documentation states plainly that "log export is not supported." Administrators access logs through the Admin Panel at the Audit Logs section.

That constraint carries weight for anyone building a compliance pipeline. Feeding Mistral administrative events into a SIEM alongside identity provider logs and gateway records means no native export path, so the correlation has to happen elsewhere or through manual retrieval. Retention length is not stated in the audit-log documentation either, which is a question worth putting to a Mistral account team in writing before a control gets designed around a retention assumption.

For teams that need audit records with defined retention windows and a defined transport into a SIEM, the requirements are laid out in AI audit log SIEM formats.

The admin API sits on the same identity model

Mistral exposes an Admin API to automate organization and workspace management, user invitations and role assignments, seat provisioning and access control, and billing and usage queries. Admin API requests require an API key belonging to a user with the Admin role in the organization.

That binding is worth noticing. An Admin-role credential inherits the authority of the human it belongs to, and every action it takes lands in the audit log as a credential actor. Reconstructing which human stood behind an automated administrative change means correlating the credential back to its owner through a separate lookup, which is the general problem described in non-human identity for AI agents.

What an inference request leaves behind

Trace a single production call to La Plateforme. An application authenticates its user through the enterprise identity provider. The application then calls Mistral with a workspace credential that belongs to the application. Mistral authenticates the credential, serves the completion, and bills the tokens.

The identity provider recorded a login. Mistral's usage metering recorded token counts. The audit log recorded nothing, because no administrative event occurred. The authenticated human never appeared in any record Mistral holds, since the credential is the only identity the API ever sees.

That is the post-authentication gap in its plainest form, and it is the same shape whether the endpoint is Mistral, an OpenAI-compatible server, or a self-hosted deployment. The gateway patterns that address it are covered in Mistral API gateway patterns.

The four fields a compliance record needs

An audit record that satisfies a regulator reviewing an AI system needs four things a workspace-scoped credential cannot supply on its own: the authenticated principal asserted by the identity provider rather than inferred from a shared credential, the role that principal held when the request was made, the classification of the data that entered the prompt, and the policy decision that permitted the call together with the version of the policy that produced it.

Mistral's audit log supplies none of those for an inference request, and that is a reasonable division of responsibility rather than a defect. The model provider records what happens to the account. Something on the request path has to record what happens to the traffic. The data-side half of that problem is covered in Mistral DLP.

DeepInspect

This is the gap DeepInspect closes. DeepInspect runs inline as a stateless proxy in front of HTTP-based LLM endpoints, including La Plateforme and self-deployed Mistral models, verifying the authenticated caller against the identity provider on every request before it reaches the model.

Because the check happens on the request path rather than inside the application or after the fact in a billing report, each record carries the named principal, the role, the classification of the prompt content, and the allow-or-block decision with the policy version that produced it, signed per decision and exportable to a SIEM. Mistral's audit log keeps doing what it does well, recording who created a credential and who changed a workspace setting. DeepInspect records what that credential did with every request it made. Book a technical deep dive at deepinspect.ai.