The Sandbox Worked. Mistral's Token Boundary Did Not.

A sandbox can isolate a process and still hand that process the keys to something valuable.

That is the uncomfortable lesson from new research published by Vero Security. Vero says its researchers found a proxy credential inside a Mistral cloud coding-agent sandbox. According to their report, that token could reach an internal model fleet, a tool gateway, and operational metrics that were otherwise blocked from the public internet.

This article is based on Vero's testing and disclosure. I did not find a matching Mistral security advisory that independently describes the affected architecture or the deployed fix. Vero's timeline says Mistral acknowledged the report on August 31, allowed more testing, and deployed a fix on September 10.

That distinction matters. The technical findings below are what Vero says it observed, not an independent reproduction.

The path started with a normal agent feature

Vero was testing the coding environment available through Mistral's Le Chat. The researchers first asked the agent to print its environment variables. The model refused because they could contain sensitive information.

The guardrail stopped the direct request, but it did not remove the sensitive value from the environment.

The researchers connected a Git repository containing a precompiled binary called local_server, plus instructions describing it as part of the project. They then asked the agent to start the local server. The agent ran the binary inside its Linux sandbox.

The binary printed and returned the environment. Vero says it exposed a variable shaped like this:

SANDBOX_PROXY_GITHUB_PROXY=http://sandbox-proxy:<JWT>@sandbox-proxy-prod-swe.mistralai.com:80

The important part was not the variable name. It was the reusable JWT inside it.

Vero reports that the proxy itself was reachable from the internet. With the token, the researchers could send requests through the proxy to internal Mistral hostnames that were not directly reachable.

No container escape was required. The code ran exactly where the product allowed it to run.

What Vero says the token opened

After reporting the initial issue, Vero says Mistral gave the team permission to continue testing.

The researchers report reaching three useful surfaces:

1. An internal model fleet. Vero says a model-list endpoint exposed released models, unreleased checkpoints, internal variants, and internally hosted third-party models. The team says inference requests worked without a per-user limit it could observe.
2. A tool gateway. An OpenAPI document reportedly exposed OCR and agent-tool routes, including web fetch and MCP connectors. Vero says direct control over URL, query, and headers turned the web tool into a server-side request primitive.
3. Operational metrics. Vero says an unauthenticated Prometheus endpoint exposed per-model usage, subsystem counters, and internal project names.

Vero stopped after demonstrating the impact. It says the surrounding controls prevented an easy deeper pivot during its testing.

This is not the same as saying Mistral's whole network was compromised. It is a report of access to specific internal services through an over-scoped sandbox credential.

Why the sandbox was not enough

Mistral's sandbox documentation describes isolated, temporary environments for coding sessions. That is useful protection. It separates sessions, limits access to the user's local machine, and gives disposable execution space.

But a sandbox answers one question:

What can this process reach on the machine that hosts it?

It does not automatically answer another:

What authority and network access have we intentionally placed inside the process?

If a credential is available as an environment variable, readable file, command argument, or local metadata response, code inside the sandbox may be able to copy it. If the sandbox also has outbound network access, the code may be able to send it elsewhere.

The agent's prompt guardrail was therefore the weakest possible place to protect the secret. The model refused to print the environment, but it could run code that read the same environment.

A malicious repository could do this during installation. A poisoned README could persuade the agent to execute a helper. A prompt injection in an issue, web page, or tool response could ask for the same action without mentioning credentials at all.

Credential isolation should be a separate layer

The strongest design is not to give the sandbox a reusable credential in the first place.

For an outbound API call, use a trusted broker outside the agent environment:

agent sandbox -> policy broker -> approved destination
                         |
                         +-> inject short-lived credential

The sandbox sends a request to a narrow broker. The broker checks the destination, method, tenant, repository, model, and action. Only then does it attach a credential that the sandbox never sees.

If a token must enter the sandbox, reduce its value:

• Issue it for one task or one session
• Expire it in minutes, not days
• Limit it to one service and a small route set
• Bind it to the sandbox identity or network path
• Enforce quotas and concurrency limits
• Make it useless from the public internet

Short lifetime alone is not enough. A five-minute token with broad internal access is still powerful during those five minutes.

Least privilege includes the network

Teams often discuss least privilege as an IAM problem. Agents also need network least privilege.

A coding sandbox usually needs package registries, source control, and a few model or tool endpoints. It rarely needs general access to internal service discovery, metrics endpoints, or every model-serving host.

Useful controls include:

• Default-deny egress with an explicit destination allowlist
• DNS and redirect validation at the enforcing proxy
• Separate network segments for agent sandboxes and internal control planes
• Authentication on every internal service, even behind a firewall
• Per-sandbox identity and audit logs
• Alerts when one session enumerates models, reads metrics, or scans internal hosts

The phrase "internal only" is not an authorization policy. Agent sandboxes are already inside some part of your infrastructure, and untrusted content can influence what runs there.

What is confirmed, and what remains unclear

Vero published a detailed reproduction path, sample environment data, endpoint classes, an impact analysis, and a disclosure timeline. Its report says Mistral cooperated and fixed the issue before publication.

I could not find a public Mistral advisory confirming the exact token permissions, affected session population, whether the token was unique per sandbox, or what changed in the fix. I also could not independently verify Vero's statements about unlimited inference or unreleased models.

That does not make the report unimportant. It tells us how to read it: as a specific, responsibly disclosed researcher finding, not as a complete vendor postmortem.

The practical checklist

If you build coding agents, browser agents, or remote execution sandboxes, test these questions directly:

1. Can arbitrary sandbox code list environment variables?
2. Can it read mounted credentials, shell history, config files, or local metadata?
3. Can it reuse a credential outside the sandbox?
4. Does the credential reach more services than the task requires?
5. Can the sandbox contact internal hosts that do not authenticate requests?
6. Can one session consume unlimited inference or tool capacity?
7. Will you detect token enumeration, internal scanning, or unusual tool calls?
8. Can you revoke one sandbox identity without disrupting every other session?

Do not stop after proving that the container boundary holds. Assume code execution inside the container is available to an attacker, because for a coding agent it is often a product feature.

The real security boundary is the combination of identity, token scope, network policy, tool authorization, and monitoring around that execution environment.

Sources

• Vero Security Research: Your Agent's Sandbox Isn't Private
• Mistral Docs: Sandbox environment
• Mistral Docs: Security
• Mistral Docs: GitHub repositories and permissions

Hero photo: Datacenter Server Racks, photographed by Carl Lender on November 4, 2015. Creative Commons Attribution 2.0. Resized from 6000 x 4000 to 1920 x 1280 pixels and JPEG-compressed; no other edits. This is an illustrative photograph of data-center infrastructure. It does not show Mistral's systems, Vero's test environment, or the reported services. No endorsement is implied.