Is the Mistral La Plateforme API OpenAI-compatible?

Mistral's chat completions endpoint follows the familiar OpenAI request shape closely enough that clients built on the OpenAI SDK point their base URL at it with a model-name change. For gateway purposes that means the client points at the gateway instead, and the gateway forwards to api.mistral.ai with a key it holds. Because the compatibility makes a direct call just as simple, egress control matters: the gateway is only the enforcement point if the network blocks the application tier from reaching the Mistral host on its own.

Does a gateway matter if I self-host Mistral in my own VPC?

Yes. Self-hosting keeps the model inside your network, which removes the third-party provider from the picture, but it does not answer who among your own users is sending what to the model. The data still moves over HTTP to an inference endpoint, and the authorization and audit questions are unchanged. A model-agnostic gateway sits in front of the internal endpoint, binds identity, classifies the prompt, and records the decision, so an internal model gets the same governance a hosted one does.

How do you govern Codestral traffic differently?

Codestral is Mistral's code model, and code assistants assemble prompts from repository content, which frequently contains secrets, credentials, and proprietary logic. A per-model policy binds Codestral traffic to a rule that classifies for secrets and proprietary code before the prompt leaves, and scopes it to the engineering roles that are permitted to use it. Binding the policy to the model name means the code model carries controls suited to what it actually receives, rather than the same generic rule as a chat model.

Can one gateway cover both hosted and self-hosted Mistral?

Yes, and that is the point of a model-agnostic design. The hosted La Plateforme API and a self-hosted vLLM or TGI endpoint are both HTTP endpoints, so a single gateway terminates the client connection, applies the same identity binding and classification, and forwards to whichever upstream the request targets. The audit record captures which upstream served the call, so a review reads one schema across both deployments instead of stitching together two separate logs.

Mistral API Gateway Patterns: One Policy Layer for Hosted and Self-Hosted

Mistral is two deployment stories that a security architect has to govern as one. The hosted path is La Plateforme, an OpenAI-shaped API at https://api.mistral.ai/v1/chat/completions with a Bearer key, serving models like Mistral Large, Mistral Small, and Codestral. The self-hosted path is the open-weight models a team downloads and runs itself behind vLLM, Text Generation Inference, or Ollama, on its own hardware. Same model family, two very different network footprints.

The reason to care about both in one design is that policy should not depend on where the model runs. A gateway that governs the hosted API and ignores the self-hosted endpoint leaves a hole the size of your on-prem inference cluster. Both are HTTP endpoints, so one identity-bound layer can cover both.

The hosted case: govern api.mistral.ai

For La Plateforme, the pattern is the familiar one. Mistral authenticates a Bearer API key that identifies the application, not the person. Point the client at the gateway, and let the gateway hold the Mistral key:

The gateway verifies the user-scoped token, binds the call to the natural-person identity, applies policy, and forwards to api.mistral.ai with the real MISTRAL_API_KEY. The client never holds the Mistral credential, and egress control keeps it from reaching the provider directly.

The self-hosted case: govern your own inference endpoint

When you run Mistral open-weight models yourself, the model answers on an internal address, something like http://mistral-vllm.internal:8000/v1/chat/completions. There is no provider key and no external host, which teams sometimes read as "no exposure." The data leaving the application still moves over HTTP to an endpoint, and the same questions apply: who is calling, what data is in the prompt, and what record proves the decision.

A model-agnostic gateway sits in front of the internal endpoint the same way it sits in front of the hosted one:

The identity binding, prompt classification, per-model policy, and audit record are identical. The only thing that changed is the upstream host. That is the payoff of a model-agnostic design: self-hosting a model to keep data in your environment does not remove the need to authorize and record what your own users send it.

Bind identity and apply per-model policy across both

Whether the upstream is api.mistral.ai or an internal vLLM server, the gateway binds each call to the natural-person identity and applies policy per model. Mistral's estate mixes general models with a code model, and code assistants pull in repository content that carries its own sensitivity:

Binding policy to the model name keeps the code model's repository-heavy prompts under a rule that looks for secrets, and keeps the self-hosted model under the same classification the hosted models get.

Constrain egress for the hosted path

For the hosted case, restrict egress so the only route to api.mistral.ai is through the gateway:

The self-hosted case does not cross the internet, but the same principle applies inside the network: the internal inference endpoint should accept traffic only from the gateway, so a service cannot skip the policy layer by calling the vLLM server directly. Egress control is what makes the gateway a chokepoint rather than a convention in both cases.

Record every decision the same way

Each decision writes a record naming the person, the model, whether the upstream was hosted or self-hosted, the data class, the outcome, and the policy version, committed before the response returns and on a write path the application cannot alter. A review can then reconstruct what left through La Plateforme and what moved to the internal endpoint, under one audit schema rather than two.

DeepInspect

This is exactly what DeepInspect does. Mistral runs hosted and self-hosted, and DeepInspect governs both from one identity-bound layer at the AI request boundary.

For every request, whether the upstream is api.mistral.ai or an internal vLLM or TGI endpoint, DeepInspect binds the call to the natural-person identity, classifies the prompt against regulated data types, applies per-model policy, and returns a deterministic, fail-closed decision in under 50 ms in internal testing. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the application never controls. DeepInspect is model-agnostic by design, so a self-hosted Mistral endpoint is governed with the same policy and the same evidence as the hosted API. If you are running Mistral in either shape and need identity-bound authorization and audit across both, book a demo today.