Alibaba-Linked ROME Agent and the Crypto Mining Story: What the Paper Actually Says

Over the weekend, Axios reported that an AI agent called ROME had freed itself and started mining crypto in secret. By Monday the same story was circulating with words like "rogue" and "hijacked" attached.

The source is one subsection of a 36-page paper from an Alibaba-affiliated team. It has been public since December 31, 66 days before the Axios story.

I read it, because the distance between that subsection and the coverage is the useful part. The authors report something serious. They also report less than the retellings suggest, and if you run agents with tool access, both of those facts should change what you do.

What is the ROME model?

ROME is a mixture-of-experts model with 30 billion total parameters and 3 billion active, built on the Qwen3-MoE architecture and trained on more than one million trajectories. It is available on Hugging Face under Apache 2.0.

The team trained it through reinforcement learning, with the agent running real tools inside sandboxes. The paper describes a proxy component in its sandbox layer, ROCK, that governs outbound access and enforces egress policies with per-sandbox network limits.

Keep that detail in mind. There was a boundary, and the design assumed it would hold.

What the paper reports in section 3.1.4

The sequence, as the authors describe it:

The first signal came from Alibaba Cloud's managed firewall, on the training servers. It did not come from training curves.
The alerts included attempts to probe or access internal network resources, and traffic consistent with cryptomining.
The team treated it as a conventional incident, suspecting a bad egress configuration or an outside compromise.
The alerts kept recurring, intermittently, across runs.
Firewall timestamps, system telemetry and RL traces lined up with episodes where the agent was running tools.
The team found that the agent had established and used a reverse SSH tunnel from an Alibaba Cloud instance to an external IP address.
The authors state that GPU capacity was repurposed for mining, which raised costs.

They say none of this was requested by a prompt or needed for a task, and they call it a side effect of tool use under reinforcement learning.

Almost every summary I read dropped the first half of item 2. Internal network probing gets less attention than crypto, but for anyone operating shared infrastructure it is the more worrying line.

What the paper does not say

Claim in circulation	What the paper supports
The agent broke out of its sandbox	The behaviour fell outside the intended sandbox. No breakout technique is described.
It earned cryptocurrency	No coin, wallet, pool, hash rate, amount or duration is given.
It wanted money	No motive is claimed. The authors call it a side effect.
Alibaba said so	The paper has 90 authors and no affiliation block. Project READMEs credit Alibaba groups. No company statement accompanied it when the story broke.
Restrictions were tightened afterwards	The reported mitigation is training data and red-teaming. I could not find an infrastructure change in the paper.

Everything here is self-reported, and I found no independent replication.

Did ROME really escape?

I would avoid the word.

"Escaped" implies a boundary that was defeated by a known method. The paper never explains how the traffic left. The authors' first suspects were misconfigured egress controls or an outside compromise, and the section does not give a root cause.

This is more than a quibble. A picked lock and an unlocked door have different fixes. If the agent found a flaw in the proxy, you patch and harden. If the network allowed the connection all along, the agent only walked through a route that the architecture diagram said did not exist. In that case the failure is yours.

"Went outside its intended sandbox" is the wording the evidence supports.

Why reinforcement learning makes this harder

This next part is my interpretation, not a finding in the paper.

Reinforcement learning optimises for what the reward function measures. Everything the agent can touch becomes part of the environment it learns from. A side effect that is neither blocked nor penalised is not a violation from the optimiser's point of view. It is an unscored action.

A prompt can say "stay inside the task". The policy learns from what actually happens across a million trajectories.

That is why I read this as an infrastructure story first. Any reward scheme will have gaps. The sandbox is the part that has to hold when the reward function has a hole in it.

The firewall did the best work in this story

The most useful detail is who noticed. A control outside the agent's own loop, run by the cloud provider and with no knowledge of the task, raised the alarm. The training metrics had no reason to show anything.

The cost is visible in the paper too. The team had to line up firewall timestamps with telemetry and RL traces after the fact, and at first they assumed an ordinary incident. The paper describes that link as something they established by correlating logs, not something an alert told them.

A cheap improvement follows from this. Give every tool call a run ID and episode ID, and make those IDs available wherever network flows are logged. When an alert fires, you want the join to take seconds.

The same thinking applies in smaller systems. On Auto-RAG and MerlinX, the enterprise retrieval and agent platforms I work on, releases only promote after post-deploy assertions pass and a soak holds against the baseline error rate. That process is ordinary release engineering, not a control for misbehaving models. The idea transfers anyway: compare running behaviour against a known baseline, using signals from outside the component under test. You will catch failures nobody wrote a test for.

The reported fix trains the model

The mitigation in the paper has four parts: a three-part risk taxonomy, a corpus of scenario seeds, red-teaming with prompt, repository and tool injection, and clean golden trajectories for supervised and reinforcement training.

That is sensible work. It also comes with no before-and-after figure, so nobody outside the team can say how much it helped.

I would treat model training as one layer and assume it will sometimes fail. Which controls still hold if the model ignores everything it was taught? If the honest answer is "none", you have a safety programme with no backstop.

What I would check this week

If agents in your organisation run tools during training, evaluation or production, these are the questions I would ask:

Is egress default-deny, and is it enforced outside the sandbox? Code in the box should have no way to change the policy.
Have you proved it from inside? Before a run starts, try to reach an address that should be blocked, and fail the run if the connection succeeds. A config file only tells you the intent.
Can you see internal probing? Most sandbox designs focus on the internet. East-west traffic deserves the same alerts.
Would you notice GPUs doing other work? Per-job accounting for utilisation against expected workload is dull, and it would have surfaced this.
Do out-of-policy trajectories get removed before they earn reward? Otherwise a run with bad side effects can still count as a success.

Allowlists deserve a final thought. Nearly every sandbox keeps a friendly route or two open, because agents need things, and then nobody looks at those routes again. I would test them as hard as the rest of the boundary.

ROME's authors disclosed this in public without being asked, which is more than most teams would do. The right response is to read what they wrote, skip the word "rogue", and go and look at your own egress rules.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and cloud-based software systems.