Your Agent's Sandbox Isn't Private: How One Token Opened Mistral's Internal Model Fleet

Dor Benjamin
October 13, 2026
x Min Read

What happens when an AI provider treats their agent sandboxes as private, trusted space?

Vero Research found a token inside Mistral's cloud coding sandbox that opened the door to Mistral's internal model fleet, its tool gateway and its internal metrics. All of these are firewalled from the internet, and all were reachable from inside the agents sandbox.

Here's what that looked like:

  • Internal model fleet: unlimited, unauthenticated inference, including unreleased Mistral checkpoints and codenamed internal variants of Mistral and third-party models (GLM, DeepSeek, Kimi, Qwen) used for fine-tuning and evaluation.
  • Tool gateway: the OCR endpoint and server-side agent tools (web fetch, MCP connectors and more). We could call these tools directly, which turned a "web request" tool into an arbitrary server-side request primitive.
  • Internal metrics: per-model usage volumes, subsystem counters and internal project codenames, all with no authentication.

That access was the impact. The root cause was where the key was kept: inside the agent's own environment. Anything an agent can reach, whoever influences the agent can reach too, and influencing an agent is far easier than compromising the system that runs it.

So how did a token to Mistral's internal infrastructure end up in our hands?

Following a hunch

At Vero, we secure the AI agents running across our customers' environments, including those in the browser. That means we spend a lot of time studying how AI providers build them.
‍
To provide users the ability to use their models as coding agents through the browser, many LLM providers offer users a lean sandboxed linux container that runs in the provider's cloud.


While testing Mistral's cloud coding agent, Le Chat, we asked it to print its environment variables. It refused, saying they contained sensitive information:

‍

That caught our attention. Every other agent we'd tested had handed its variables over without hesitation. A refusal like that usually means there's something worth protecting. As it turned out, there was.

Sandbox Secrets

Asking the model directly went nowhere. It clearly had prompt-level guardrails against requests like ours.

But Le Chat doesn't just respond to prompts. It runs commands in a Linux sandbox, and that's a much bigger attack surface. What if we got the agent to run a precompiled binary that executed the env command and sent the output back to us?

Responsibly, Le Chat also refused to run arbitrary binaries from the internet - so we created a git repo, connected it to the Mistral chat, uploaded a binary named `local_server` and a readme instructing the model how to run it. We then asked the model to “start the local server so we can start developing”, and it ran the binary!
The env output included:

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

The proxy was directly accessible from the internet, and the JWT token was valid! We started poking around Mistral’s sub-domains to see if we could access something we weren’t supposed to via the proxy.

One stood out: harmattan-science.coreweave-*.prod.internal.mistralai.com.
When accessed directly, it was blocked by Cloudflare, but when attempting through the sandbox proxy, with the token, it was open.

Additional investigation revealed the proxy was serving LLMs. We listed the models and got back a response:

curl --proxy 'http://sandbox-proxy:<JWT>@sandbox-proxy-prod-swe.mistralai.com:80' https://harmattan-science.coreweave-bar.prod.internal.mistralai.com/v1/models</JWT>
{"object":"list","data":[{"id":"<REDACTED>","object":"model","created":1788181955,"owned_by":"mistral","root":"<REDACTED>", ... }]}

At this point it was clear that the token was sensitive, and that this was a finding - a token living in every sandbox, allows anyone on the internet to reach an internal, otherwise-firewalled Mistral service.

We reported it to Mistral. They responded quickly and asked us to keep going and see what else the token could do.

Free Tokens for All!

With permission in hand, we set up a stable reverse shell from the sandbox and got to work. The internal Harmattan domain exposed each of these services on its own route. Here's how we reached them.

/v1/models

This endpoint listed the internal fleet. Released models, unreleased checkpoints, and internally-hosted third-party models (GLM, DeepSeek, Kimi, Qwen).
‍

Inference requests to them succeeded with no per-user limit we could see (free tokens for all!)

We could also hit 3rd party internally hosted models:

/metrics/

This endpoint returned Prometheus telemetry with no authentication. Per-model usage volumes, subsystem counters, and internal project codenames.
‍

/openapi.json & The tool layer

The endpoint /openapi.json describes the gateway's full route set (it identifies itself as "Harmattan Service"), including the OCR endpoint and an agent tool-execution layer.

From there, we could call the gateway's tools directly, including web fetch and MCP connectors. Because we controlled the destination URL, query string and headers, the agent's web tool became an arbitrary server-side request primitive.

Other tools with other primitives were also available.

At that point the impact was clear, so we stopped. We have other agents to protect :)

Business Impact

Stepping back from the mechanics, here's what a token readable from inside the sandbox gave an attacker:
‍
‍Intellectual property and roadmap exposure

The model catalog and metrics exposed unreleased checkpoints, internal project codenames and internal variants of hosted models, such as data-generation and safety-evaluation builds.
Mistral hosts some third-party open models as a public product, so the issue isn't that these models exist on its infrastructure. The issue is that internal R&D detail and roadmap signals were readable without authentication.
‍
‍Unmetered inference

Requests to the internal fleet ran with no per-user limit we could see. Beyond the direct compute cost of someone running workloads on Mistral's infrastructure, unrestricted query access to unreleased models is its own exposure.

Operational telemetry

Per-model usage volumes and subsystem counters show which models Mistral runs, at what scale, and which internal projects are active. That's valuable to a competitor and useful reconnaissance for an attacker.

A foothold inside the model plane

The tool layer gave multiple primitives (for example “SSRF”) originating from an internal network position. In our initial probing, the surrounding guardrails held, and we couldn't easily pivot deeper. But primitives like these inside a perimeter are exactly where internal compromises start.
‍

Conclusion

The specific bug was a leaked, over-scoped token.

The broader lesson is the one we started with - an AI agent's environment is reachable by whoever can influence the agent. 

We got in by running code in the sandbox, which is a legitimate feature. A prompt injection would have reached the same token.

A poisoned document, a malicious tool response or code execution in the sandbox: any one of them is enough. Whatever credentials, network access and tools the agent holds become the attacker's.

As agents gain autonomy and connect to more systems, their environments become a production perimeter and need to be secured like one. Scope every credential, network path and tool to the agent's task, and treat all of it as untrusted by default.
‍

Responsible Disclosure Timeline

2026-08-31 - Vero Security Research discovers the leaking token and initial impact, and reports the incident to Mistral AI.

2026-08-31 - Mistral AI acknowledges the report.

2026-09-01 - Mistral AI allows Vero Security Research to further probe the environment.

2026-09-03 - Vero Security Research reports back expanded findings.

2026-09-10 - Mistral AI deploys a fix.

2026-10-12 - Public disclosure

We would like to thank Mistral AI for a very smooth disclosure process and cooperation.

‍

We're Vero's security research team. We break AI agents and the systems they connect to, so we can find the weak points before someone with worse intentions does
Not sure what your agents can reach? Let's find out together - book a demo or say hi on Linkedin

‍