Mistral Large 4 opens a preview for security investigations

Mistral opened a public preview of Mistral Large 4 on October 6. The model is available through Mistral Studio's API today. Publicly downloadable weights are promised by the end of the month. The company emphasizes cybersecurity and tool-using workflows.

For a security team investigating software failures, that creates an immediate way to compare the model's assistance with its existing workflow. It also makes the first deployment choice straightforward: this is a hosted trial. A team that requires local inference needs the forthcoming weights before it can evaluate that arrangement.

From a request to an investigation

The model page lists function calling and structured outputs for mistral-large-4. Function calling lets an application offer operations such as reading a source file or retrieving an approved log excerpt. For a custom function, the model chooses the operation and supplies its arguments; the application executes it and returns the result. Mistral's function-calling guide explains that exchange.

Consider a hypothetical orders API that starts returning internal-server errors for malformed JSON after a dependency update. Its expected behavior is to reject an invalid request with HTTP 400 while continuing to accept valid orders. The investigator supplies a synthetic failing request, the dependency diff and a sanitized stack trace, then asks the assistant to locate the error-handling change.

A read-only function could let the assistant inspect the relevant handler instead of guessing from the exception name. If it identifies an exception that now escapes the handler, its useful output would include the file location, the supporting trace and a candidate correction. Those references give an engineer something specific to inspect. They also keep an unanswered question visible: would the proposed change restore the API's expected behavior?

Checking the affected request

A separate check can answer that question on a disposable copy of the service. It would run the malformed request against the candidate change and check for the expected rejection, then send a valid order to check that the ordinary path still works. The assistant's statement that it has fixed the problem cannot establish either result. This is the distinction developed in our incident-agent evaluation guide: service behavior must be checked independently of the agent's completion claim.

A read-only assistant can complete its task by supplying a supported finding and the next test. A repair claim needs separate observations from the service. Without them, the repair remains unverified, however useful the explanation. This example also leaves production recovery outside its scope.

Tracing what the preview actually did

Mistral's current observability documentation recommends recording model configuration, inputs, outputs, tool calls, errors and retries. It describes tracing individual model calls and tool steps through an agent workflow. Those records make an investigation's result easier to explain.

In the orders example, a refusal to analyze the supplied material, a failed file-read function and a completed finding followed by a failing service check are different outcomes. The first leaves the requested analysis undone. The second points to a problem in the tool path. The third preserves potentially useful reasoning while showing that the proposed correction did not satisfy the check. Reporting only whether the model returned a final answer would lose those distinctions.

Today's useful comparison is therefore modest and concrete: does the assistant produce a finding an engineer can verify, and can the team identify where an unsuccessful investigation stopped? A trial through the hosted preview can supply that evidence. A later local deployment will add a different serving environment to examine; the same affected-request check gives the team a way to compare the result without relying on the model's declaration of success.