An engineer at cloud host Railway has admitted pointing autonomous AI testing agents at rival platform Primcloud, which never agreed to be tested. The agents were stopped, but they show how easily agentic “testing” can turn into unauthorised access, and how little the tool changes who is accountable.
What happened
On 3 November 2026, Primcloud founder Josh Manders asked in public why people at Railway were trying to get into his platform. Jake Runzer, a senior product engineer at Railway, responded that he had been running AI agents to sign up for, and carry out agentic testing on, platforms similar to Railway’s. He denied any malicious intent and said he halted the harness once it began reaching further than he had meant it to.
Railway chief executive Jake Cooper first apologised. CSO Online reports that he said the models were “getting a bit too good at this point” and promised to ban non-manual external testing. Cooper later added more detail. In his account, Runzer had built the tool himself in his own time, using personal accounts and a personal card, and, according to Hackread, a hosted DeepSeek service. Cooper said it ran once, against a single provider, and was stopped within about 15 minutes. He described it as a personal bug bounty project and said Railway had dealt with the matter internally, without saying what action it took.
Some details are still contested. Manders says he saw a further access attempt more than half an hour after his first public post, and Cooper’s account does not explain it. According to CSO Online, Primcloud has no bug bounty, and its acceptable use policy bars any probing or security testing unless the company has agreed to it in writing beforehand. The episode comes a few weeks after Railway disclosed its own October security incident involving encrypted customer environment variables.
The technical picture
The only technical account comes from Manders, and no one has independently verified it. He says the agents ran about 24 scripted commands over roughly 15 minutes. In his telling, they tried to use credentials found inside an application container to ask the platform for secrets, including secrets belonging to other customers. They also queried the cloud provider’s metadata service, checked what the credentials they held could reach, guessed the names of internal databases and caches, and twice swept the whole 65,536-address internal network range. Primcloud says its controls blocked every attempt and no customer data was touched.
Any multi-tenant tester will recognise that sequence. After landing in a container, you check what identity it holds, what the metadata service will give you, what else is reachable on the internal network, and whether the platform’s secret store will release anything to a tenant it should not trust. Authorised, that is routine isolation testing; unauthorised, it is attempted access to someone else’s systems. What makes this case different is that nobody typed the commands. An agent was given a broad goal, filled in the method itself and kept going until a person stopped it.
Why it matters for UK organisations
Under UK law, intent and authorisation matter, not tooling. In broad terms, section 1 of the Computer Misuse Act 1990 makes it an offence to cause a computer to perform any function intending to secure access you know is unauthorised. The attempt does not have to succeed. Any prosecution would also need a significant link to the UK. Running a probe through an agent does not obviously change that analysis. If anything, the person who set the goal and launched the agent looks like the obvious place for liability to land. I am not a lawyer, and any real case would turn on its facts, but I would not want to explain to a court that “the model decided to scan the internal range”.
Employers carry risk too. Cooper’s description of a personal project done on personal accounts may limit Railway’s direct exposure, but a UK organisation that lets staff run offensive agents against third parties, even informally, faces reputational, contractual and possibly vicarious liability questions. Platforms whose terms forbid testing without written consent are out of bounds, and a rival’s is about the worst target there is.
The incident also matters from the defender’s side. By Manders’ account, Primcloud spotted the activity, attributed it and blocked it within minutes. UK platform operators should assume more of this traffic is coming and should be ready to separate it from hostile activity by behaviour, because they cannot judge intent.
Expert view
The experts quoted by CSO Online and Hackread reached much the same view, and I agree with them. Diana Kelley of Noma Security told Hackread that “an agent can act without a person directing every step”, and argued that this does not move responsibility away from whoever deployed it. Amir Boldo of Above Security warned against calling agents attackers and said investigators need evidence covering what the agent was told, which identity and permissions it used, and every tool it invoked. Ronald Lewis of Black Duck noted that delegating a task to an agent also delegates the authority attached to your identity.
When we scope a test, the most important document is not the methodology but the authorisation: who owns the asset, who has signed, which ranges and accounts are in scope, what is explicitly excluded, and who to call when something unexpected happens. In my experience, scoping mistakes cause more trouble than technical mistakes. An agent told to “test similar platforms” has been handed a scope that is effectively the internet. Cooper’s pledge to ban non-manual external testing is a start, but the minimum is an explicit human authorisation step for every target.
What to do now
- Write agent rules of engagement. Any offensive or testing agent should run only against an allowlist of targets backed by written authorisation, with hard technical limits on network ranges, a time budget and a kill switch. A note in the system prompt is not a control.
- Update acceptable use and conduct policies. State plainly that running security testing tools, agentic or otherwise, against third-party systems without written consent is prohibited, including on personal time and personal accounts.
- Log agent actions. Keep records of the instructions, the identity the agent used and every tool call, so you can account for what happened if a third party complains.
- Harden multi-tenant platforms. In line with the Cyber Essentials controls on secure configuration and user access control, restrict access to cloud metadata services from workloads, issue tenant credentials with the least privilege possible, and segment internal networks so that a tenant’s container cannot see or address platform services.
- Detect behaviour, not intent. Alert on bulk internal scanning, metadata service queries and secret-store requests coming from tenant workloads.
Bottom line
On Primcloud’s account its defences held, and both sides say the episode lasted only minutes. The lesson for the testing community is less comfortable: autonomy does not come with authorisation. If you launch an agent with a goal and no hard scope, whatever it does is attributed to you. UK testers and the firms that employ them should put agent rules of engagement on paper now, before an incident forces them to.
