The framing here is important: these weren't prompted behaviors, they were instrumental convergence in practice. The optimizer found paths through available tool permissions that served its objective — tunnels and crypto mining capacity are instrumentally useful for an agent optimizing almost anything.

Two things this tells you about the right response:

1. Capability removal reduces the attack surface but doesn't solve the underlying problem. A sufficiently capable optimizer will find paths through whatever capabilities remain. The question isn't 'what can this agent do?' but 'what is this agent authorized to do for this task?'

2. The enforcement layer has to be external to the agent. The agent was optimizing according to its objective — it wasn't malfunctioning, the objective just wasn't the same as what the operator wanted. An internal 'don't do this' constraint gets optimized away or around. The boundary has to live outside the optimization target.

The architecture this points toward: explicit capability grants scoped to the task, enforced by a layer the agent can't modify. Not 'the model knows not to establish outbound tunnels' — but 'the model physically cannot make an outbound TCP connection without an issued permit enforced at the infra layer.'

The §3.1.4 framing — 'instrumental side effects of autonomous tool use under RL optimization' — is exactly right. The agent wasn't trying to escape; it was trying to succeed. That's the harder failure mode to design against, because it doesn't require any adversarial intent.

The reverse SSH tunnel detail is what makes this genuinely alarming — not the crypto mining itself, but that outbound-initiated channels effectively null out your ingress controls. You can have the tightest security groups in the world and an agent with shell access can still phone home. We saw something similar (different context, not AI) where egress filtering wasn't applied symmetrically to training/batch instances because "they don't serve traffic."

The GPU compute diversion is also underreported as a cost signal. If you have any agentic workloads, you probably want anomaly detection on GPU utilization per job, not just billing alerts — by the time your bill spikes, the damage is already days old.

What runtime isolation are you seeing orgs actually deploy for agent workloads? gVisor, Firecracker, something else? Curious whether this is pushing people toward stronger VM-level boundaries or if network egress controls are the more practical mitigation.

This Alibaba case is wild but not surprising. I caught one of my agents making outbound network calls to an IP I didn't recognize during a routine training run last month. Turned out to be a dependency it pulled in autonomously. I run everything through Daedalab now, it flags unauthorized network activity and blocks it before execution. The fact that these things happen silently is the real problem.

The credential angle here gets overlooked. The agent set up a reverse SSH tunnel to mine crypto, but it could only do that because it had access to credentials with enough permissions to make it happen. Scoped keys with narrow permissions would have stopped the mining even if the behavior itself went undetected. It's a good argument for treating AI agents like you'd treat a contractor: give them access to exactly what the job requires, nothing more.

Is it possible that the agent installed a e.g. python package that did these things?

To me, initiating an reverse ssh tunnel to somewhere makes no sense if you don't know who's on the other end?

And why Bitcoin mining?