Leaked Mistral API Key: what to do in the first hour

• Hardcoded in a script. A quick client call with api_key="…" committed as it is.
• Environment files. .env files, Docker compose files and notebook configs copied into a repository, under a name like MISTRAL_API_KEY.
• Agent and tool configs. Coding agents, editor plugins and MCP configuration files that store the key in plain text, then land in a public dotfiles repository.
• Browser code. A key placed in front-end JavaScript so a web page can call the API directly, where every visitor can read it.
• Tutorials and shared notebooks. A key pasted in a Colab notebook, a gist, an issue or a screenshot while asking for help.

1. Find the key in the console. In Mistral’s admin panel, open the API Keys page. The list shows each key’s type, its workspace, when it expires and when it was last used. A key that was used recently, or from a workspace you did not expect, tells you where to look first.
2. Create a new key in the same workspace, with an expiry date if your policy sets one. Mistral does not let you change a key’s workspace, scope or expiry after creation, so create a new one rather than editing the old one.
3. Deploy the new key to the application or secret store that used the old one, and confirm that it still works.
4. Delete the exposed key. From the same key list, delete the leaked one. In Studio, developers can do the same from their profile, with the trash icon. Requests made with a deleted key are rejected.
5. Check usage. Look at the usage reports of the workspace for the period since the exposure: volume you cannot explain, models you do not use. Usage is tracked per workspace, so check each workspace the key could belong to.
6. Check who else can create keys. In an organization, admins and members can create keys. Review the member list and the keys listed under each member for ones you do not recognise.
7. Look for other keys in the same place. A repository that held a Mistral key often holds other providers’ keys in the same file. Rotate each of them at its own provider, then move the key out of the code. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

Mistral keys are managed from the API Keys page of the Mistral console, after you sign in with the account of the organization that owns them. Organization admins see every key across workspaces; developers see their own from the profile in Studio. Find the exposed key and delete it. Mistral’s documentation describes rotation as creating a new key and then deleting the old one. If you cannot find the key, check the other workspaces and organizations your account belongs to, since keys are scoped to the workspace where they were created. The page can change over time, so if the wording differs from this guide, look for the section where keys are created and listed.

The rule is called Mistral API Key (contextual). Because the key has no prefix, the rule does not match a bare string: it requires a label such as MISTRAL_API_KEY, followed by = or : and exactly 32 letters and digits, with or without quotes. Strings found without that label are not reported, which keeps false alerts down but means a Mistral key pasted without its variable name will be missed. The severity is high. This type is checked live: LeakWatch sends the smallest possible chat request, limited to a single output token, to see whether Mistral still accepts the key. It reads none of your data.