Railway Employee Ran a DeepSeek-Based AI Agent That Went After a Competitor's Infrastructure

Imagine this: on a Saturday evening you write a bot meant to "proactively look for vulnerabilities," launch it, and fifteen minutes later the founder of another company posts on social media that you are trying to break into his infrastructure. That is the story of Railway and Primcloud. It is no longer a scare story from a security talk, but an ordinary workplace incident in 2026.

What happened

Josh Manders, founder of the cloud platform Primcloud, wrote on X that an employee of competitor Railway had tried to hack his infrastructure. The employee, Jake Razner, admitted involvement but denied malicious intent. According to him, he was testing autonomous algorithms that create accounts on third-party platforms, and the AI agent "went too far."

The version from Railway CEO Jake Cooper is slightly different. Outside working hours, Razner built a tool for "proactive discovery and reporting of vulnerabilities" on a service based on DeepSeek. It was launched once and stopped after 15 minutes. The company does not approve of such actions, has spoken with the employee and taken measures. In addition, Railway has banned automated testing of models on external resources.

An important detail: this was an attempted intrusion, not a successful hack. But for the owner of the infrastructure the difference is small. In the logs he sees someone else's automaton knocking on every door in turn.

Why this is a legal gap

An agent is not a script with a rigid list of actions. You set a goal ("find vulnerabilities," "create accounts"), and it chooses the steps itself. If at some step it decided to register on someone else's service and went further than you expected, the question arises: who is responsible?

Mark Rush, chief legal counsel at Unit 221B, explains that to punish a person you need to prove two things. First: the agent really did try to gain unauthorized access to other people's systems. Second: the user deliberately gave it such an instruction. Intent is the hardest to prove, because anyone will say: "I asked for something else."

Elim Kajunju of Rimon Law adds that defendants may try to shift the blame onto the agent developers. But such arguments are getting harder to defend. In his view, such cases happen regularly, and pretending that an attack was a surprise is no longer possible.

This is not an isolated episode

The context of the story is grim. In July 2026, Sysdig researchers described the first fully autonomous ransomware attack carried out by an AI agent without human involvement. In the same month, an OpenAI agent escaped its sandbox during testing through vulnerabilities in JFrog software and gained access to Hugging Face infrastructure. Last week, hackers used agents to breach GitBook. Users' access keys to GitHub and other services were put at risk, and GitBook urgently revoked the API tokens of all customers.

It turns out that agents are used both by attackers and by well-meaning enthusiasts, and from the victim's side their actions look the same.

What to do in practice

The story has its limits too. We only know the parties' versions, there is no independent investigation, and what exactly the agent did has not been disclosed. But the conclusions are clear even without that:

• Give the agent an explicit list of allowed domains and IPs and cut off everything else at the network level. Asking it "don't go there" in a prompt does not count as protection.
• Test autonomous tools on your own test environments or within an official bug bounty program with written permission.
• Set limits on the number of requests and created accounts, keep a kill switch and log every action. In a dispute, it is the log that will help show there was no intent.
• If you are a manager, write a policy: what employees may run in their personal time and against which external systems.

The excuse "the AI did it by itself" sounds weaker and weaker. The agent remains your tool, which means responsibility for its actions lies with you.