Mistral API Key Rotation: Zero-Downtime Rotation and the Leaked-Key Runbook

Getting your first Mistral key working is a five-minute job, and there is asetup guidefor it. This page is about the part nobody writes down: the credential you already have is a liability with an age, and at some point it has to be replaced — on a schedule, when someone leaves, or at 2am because it turned up in a public repository.

Almost every painful key rotation fails for the same structural reason: the team treats it as editing a secret rather than running two credentials in parallel. Editing in place guarantees a window where the deployed configuration and the set of valid keys disagree, and the length of that window is however long your slowest deploy target takes to pick up the change. Overlap eliminates the window entirely.

Rotation Is a Four-Phase Overlap, Not an Edit

The whole technique is that two Mistral keys are valid at the same time for as long as it takes every consumer to move. Nothing clever happens in any individual step; the safety comes entirely from the order.

Phase 3 is where the discipline lives. "I updated the secret" is not evidence; zero usage on the old key is. A long-running process that read MISTRAL_API_KEY at startup will happily keep using the old credential for days after the secret store was updated, and you will discover this at the exact moment you revoke.

The Mistral-Specific Trap: "The Mistral Key" Is Ambiguous in a Hybrid Stack

Mistral models are reachable through more than one commercial surface. A first-party La Plateforme key authenticates against Mistral's own API. A Mistral deployment running on a cloud marketplace — Azure AI Foundry being the common one — authenticates with a credential issued and rotated by that cloud, in that cloud's portal, on that cloud's identity model. They are different secrets with different lifecycles and different revocation paths.

In a hybrid stack the instruction "rotate the Mistral key" therefore resolves to at least two different procedures, and rotating the La Plateforme key does absolutely nothing to a workload that is calling a cloud-hosted deployment. Worse, it looks like it worked: the first-party traffic keeps flowing on the new key, the cloud-hosted traffic keeps flowing on the old one, and nobody notices the second credential was never touched until an audit or a breach forces the question.

Record the surface alongside every credential in your inventory — first-party or cloud-hosted, and which subscription or workspace issued it. Mistral's first-party keys are workspace-scoped, so the same discipline applies internally: a key issued in one workspace cannot be rotated from another, and a service that was onboarded through a colleague's workspace becomes unrotatable the day that colleague's access is removed.

Reading the Credential So Rotation Is a Config Change

A rotation is only as fast as the slowest consumer, and the slowest consumer is always the one that read the key once, at import time, into a module-level constant. Build every Mistral client from one place, read the credential at call time, and a rotation becomes a config change rather than a redeploy.

// ONE module constructs every Mistral client for the whole codebase.
// Nothing else in the repo reads MISTRAL_API_KEY directly.

function credential() {
  // Read at call time, not at import time — a process that has been
  // running for a week must be able to pick up a rotated key.
  const key = process.env.MISTRAL_API_KEY;
  if (!key) throw new Error('MISTRAL_API_KEY is not set');
  return key;
}

export async function callMistral(path, body) {
  const res = await fetch(`https://api.mistral.ai/v1${path}`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${credential()}`,
      'Content-Type': 'application/json',
      // Tag every request with which key issued it. During a rotation
      // this is how you prove the old credential has actually drained.
      'X-Key-Id': process.env.MISTRAL_API_KEY_ID ?? 'unlabelled',
    },
    body: JSON.stringify(body),
  });

  // 401 is fatal. Retrying it during a revocation turns a clean
  // cutover into a retry storm against a dead credential.
  if (res.status === 401) {
    throw new Error('Mistral: credential rejected — rotated or revoked, do not retry');
  }
  return res;
}

The X-Key-Id line is the cheap trick worth stealing. Emit the key identifier — never the key itself — into your own logs, and phase 3 stops being a guess: you can watch traffic on the old identifier fall to zero across every service before you revoke anything.

The Leaked-Key Runbook: First Ten Minutes

A leaked Mistral key is not primarily a security incident with a fixed cost. It is a metered credential that somebody else is now spending, and every minute of deliberation has a price. Work the list in order.

1. Decide whether to revoke first or rotate first. Visible abuse — usage you cannot attribute, a spend curve that is not yours — means revoke now and accept the outage. No evidence of abuse means rotate first and revoke a few minutes later with no downtime at all.
2. Issue the replacement in the Mistral La Plateforme console and push it through the same four-phase overlap. Do not shortcut the inventory step just because you are in a hurry; a half-rotated stack under incident pressure is how a ten-minute problem becomes a two-day one.
3. Delete the exposed key once traffic on it is zero. Delete rather than disable.
4. Pull the usage record for the entire window the key was exposed — not since you noticed. The exposure started when the secret was written, not when it was found.
5. Purge the secret from history. A key committed to git is still in the reflog, in forks, in CI caches, and in any build log that echoed the environment. Rewriting the commit is not sufficient on its own, which is precisely why revocation comes first.
6. Close the process gap. Ask how a credential reached a location your secret store does not control, and fix that. A rotation that does not end in a changed process is a rotation you will be repeating.

How a Compromised Key Actually Presents

This is the part that makes credential incidents hard to spot: almost none of the symptoms look like a security event. Five of the six rows below return a perfectly ordinary HTTP status.

The through-line: with a single shared key, every one of these is indistinguishable from an ordinary engineering problem, and teams reliably spend days debugging the wrong layer. Split keys per workload and the same anomalies become attributable in the first hour, because the usage that does not belong is sitting on a credential with a name.

A Rotation Schedule Worth Actually Keeping

• Every 90 days for production credentials, calendared, with an owner. An unowned schedule is a decoration.
• On offboarding, for every key the departing person could read — which, if you have a shared secret store, is a bigger list than the one they personally created.
• On exposure, immediately — including "probably fine" exposure like a screenshot, a support ticket, a pasted log, or a shared no-code workflow. Probability is not a control.
• Before an audit or a security questionnaire, because the first question is always the age of the credential and the second is when you last practised the procedure.
• After any incident in which the key was read out of a running environment by a human, even a trusted one.

One more discipline that costs nothing: rotate on a boring Tuesday when nothing is on fire. A rotation procedure that has only ever been executed during an incident is a procedure you are testing in production at the worst possible moment.

Where to Send Traffic If a Revocation Goes Wrong

A botched rotation is an outage you caused, and it deserves the same fallback path as one the provider caused. Each of these runs on separate infrastructure and a separate credential, so a Mistral key problem does not follow you there.

Choosing a destination is its own problem — see thefallback ranking guidefor how to decide whether the answer you get back is worth the same, and thefailover guidefor the cutover mechanics.

Frequently Asked Questions

Related Mistral Guides

• Mistral API Key Setup Guide
• Mistral API Error Codes Explained
• Mistral API Rate Limits Explained
• Mistral API Cost Attribution Guide
• Mistral API Data Privacy & Retention
• Mistral API Monitoring Guide
• API Authentication & Security: The Complete Guide