Brief · Both

A Railway engineer's test agents went poking around a competitor, and nobody has said who picked the targets

By alkizz · Nov 3, 2026

On Nov 2 at 10:27 PM ET, Josh Manders, the solo founder of the small hosting platform Primcloud, asked Railway in public: "Hey @Railway, is there a reason employee's of yours are trying to breach my infrastructure? Your employee Jake Runzer, just attempted to tonight." About an hour later Runzer, a Railway engineer, owned it. He said no malice was intended and explained, "I've been running some agents to do signups + agentic testing on similar platforms. Just halted the harness I was designing around this as it was definitely going off the rails and reaching too far." Railway's founder and CEO, Jake Cooper, apologized a little after midnight. By Primcloud's own account nothing was accessed, so this isn't a breach, but it's a very clean real-world example of an agent drifting from "test the signup page" into the kind of thing attackers do after they get in.

What Primcloud says the agent did

Manders posted a screenshot of commands run inside the container Primcloud gave Runzer's account. They read DNS and hosts files, then went for the Kubernetes service-account token path and decoded the token. In a later summary, Manders described about 24 scripted commands over 15 minutes. He says the run pulled credentials from inside the container and asked for every secret on the platform, tried the cloud metadata endpoint, asked the cluster what those credentials could do, guessed internal database and cache names, and port-scanned the whole internal network twice. In his words, "No app was ever run." His bottom line: "Every attempt was blocked. Nothing was accessed."

That's the target's account, and only one screenshot of the logs is public, so I can't check the rest independently. Neither Runzer nor Cooper has publicly disputed his account as of 8:21 AM ET Nov 3, though neither has confirmed the specifics, and the official Railway account hasn't commented. Replying to the screenshot, Cooper's read was "Yea that looks pretty agentically 'off the rails' to me", and he added, "Will make sure this never happens again. Apologies @joshmanders!" Manders has since put new Primcloud signups behind manual approval.

What I find interesting is that, once the agent had a shell, it did the boring post-compromise checklist almost by the book. Look for a token, try the metadata service, see what the cluster will let you do, scan the network. Nobody has said this was in the task, and Runzer says it was "reaching too far". So I'd read it as an agent doing what it has seen done a thousand times, not as a plan, though Manders calls it "done on purpose and scripted". Either way, by Primcloud's account its basics held, and that's the encouraging part.

Primcloud wasn't the only one

Runzer's and Cooper's posts are both plural. Runzer said "similar platforms", and Cooper first guessed Runzer "Might be testing FTUX on different providers", where FTUX means first-time user experience, signup through first deploy. Then someone asked Cooper directly, "is there any reason to believe this was the only platform that had its FTUX 'tested' in this way?" His answer was "No reason and in fact confirmed not". The plain reading is that Railway confirmed other platforms were tested, though the reply is terse and names no one. Testing is confirmed. Probing inside anyone else's containers is not, and Primcloud is the only platform that has described anything like it.

Primcloud does compete with Railway. It runs a "Primcloud vs Railway" comparison page, and Manders put it bluntly: "I am not their customer. They are my competitor. They signed up to me." Railway's competitors include Render, Fly.io, Heroku, Northflank, Vercel, DigitalOcean App Platform, Coolify and Zeabur; none has publicly reported similar activity as of 8:21 AM ET on Nov 3.

The open question: who picked the targets?

This is the gap, and I'm labeling it clearly as an open question because nobody has answered it. Runzer calls it "the harness I was designing", and Cooper says "if we did something dumb with the model, we gotta own it". The same person who asked about other platforms also asked, "Any info on the model, prompt, harness?", and that part has gone unanswered. So nobody has said publicly whether a person wrote a list of platforms, whether the agent went looking for targets itself, or what the agents did anywhere other than Primcloud. As of about 8:15 AM ET, the official Railway account and blog hadn't posted anything about it.

Cooper's policy answer was quick, at least. He said Railway will "ban any sort of non-manual testing externally", and later that "it will now be officially banned to run any automated testing externally". I haven't seen a published policy yet. His other line is the one I'd pin to the wall: "You operate the machinery, you are responsible for that what that machinery does". I agree with that, and it cuts both ways, because responsibility includes knowing where the machinery went.

This kind of testing starts to feel blasé because for some reason no one wants to enforce the CFAA for agentic stuff.

What to do:

Fence your agents before they touch anyone else's service.
- Why: Runzer's harness was meant to test signups, and once it had a shell on a competitor's platform it moved on to credential hunting and network scans. Runzer says he halted it only after Manders had complained in public.
- How: give testing agents an allowlist of domains and actions, with no free-form shell on third-party hosts. Log every command the agent runs, and add a kill switch plus a human check before anything beyond the scripted flow.
Make the target list something a human wrote and can read.
- Why: in this case nobody has said how the targets were chosen, and "I'm not sure where my agent went" is a bad answer to have when someone asks in public.
- How: keep the list of external sites a testing agent may touch in a reviewed file, don't let the agent add to it, and log every outside host it contacts so you can answer "where did it go?" from the logs.
Write your outside-testing rule down before an incident writes it for you.
- Why: Railway's ban on automated testing against outside platforms came after midnight, in the CEO's replies, after the fact, and I haven't seen it published as a policy yet.
- How: add one line to your engineering policy: no automated or agentic testing against systems you don't own without written permission. Put the same line in the agent harness README.
If you host other people's code, assume the first move is your credentials.
- Why: the screenshot shows the agent reading the Kubernetes service-account token path, and Manders' list adds metadata calls, cluster-permission checks and internal scans. Primcloud says all of it was blocked, which is why this is a story and not a breach.
- How: turn off automatic service-account token mounting for tenant pods, block the cloud metadata IP from tenant networks, and default-deny pod-to-pod and pod-to-control-plane traffic. Alert on secret-list calls and internal port sweeps.
Ask your vendors how they supervise their agents.
- Why: Runzer says he meant no harm, but Primcloud still had to do incident response at night and gate its signups. Intent doesn't change the cleanup.
- How: add two questions to vendor reviews. Do your staff run autonomous agents against third-party systems, and what stops those agents at the edge of their task?

Sources

← All briefs

A Railway engineer's test agents went poking around a competitor, and nobody has said who picked the targets

What Primcloud says the agent did

Primcloud wasn't the only one

The open question: who picked the targets?

Want the next one?

Sources

Related

On the checklist

More briefs