Railway Got Hacked. Thirteen Days Later, Its Engineer’s AI Agent Probed a Competitor

On October 20, 2026, Railway’s monitoring started firing on abnormal activity. What first looked like elevated latency turned into a security incident that reached internal systems and exposed stored customer secrets. Railway eventually concluded that environment variables belonging to as many as 1.85% of its workspaces, roughly 100,000, may have been compromised. It told every customer who had stored secrets before October 21 to rotate them.

Then, on November 3, Railway found itself in a very different security story.

Primcloud founder Josh Manders publicly accused Railway product engineer Jake Runzer of trying to breach Primcloud’s infrastructure. Runzer answered that the activity was his. He said he had been running AI agents to test signups and other flows on similar platforms, and that the harness he designed had gone “off the rails” and reached too far. Railway cofounder Jake Cooper apologized and said the company would prohibit automated external testing.

The timing is brutal. Railway had just spent two weeks asking customers to trust its handling of a serious breach. Now it had to explain why tooling operated by one of its own employees was probing another hosting platform.

The first incident was already a serious one

Railway says the attack began on October 20 at 13:58 UTC, when monitoring detected unusual latency. Engineers investigated what they initially believed was an attempted privilege escalation in the company’s build infrastructure and halted builds while they deployed mitigations. By 19:53 UTC, however, Railway had found evidence that the attacker could escalate access across multiple parts of its systems in parallel.

The situation deteriorated overnight. Railway’s timeline says investigators discovered that the attacker had obtained encrypted secrets. The attacker later reached credentials for Railway’s CI environment, which allowed some additional artifacts containing API access to be decrypted. Railway then found evidence of an unauthorized query against encrypted environment variables, with some of those values apparently decrypted using the compromised credentials.

Environment variables are often where developers put the things they absolutely do not want to leak: database passwords, GitHub credentials, registry tokens, Stripe keys and API keys for model providers. Railway ultimately told users to revoke and replace sensitive variables stored on the platform before October 21 and review related audit logs for suspicious activity.

Running customer applications stayed online, but new builds and deployments were paused while Railway worked through the incident. Railway also invalidated access tokens, rotated internal credentials, rebuilt affected tooling from validated source and accelerated a migration of its builder infrastructure from isolated multi-tenant environments to single-tenant environments.

The company said the attacker did not log into individual Railway user accounts. Its preliminary estimate put the maximum number of workspaces with potentially compromised environment variables at 1.85%, or about 100,000 workspaces. Because Railway could not determine exactly which individual variables had been decrypted, it contacted a broader group of customers and supplied potentially affected credentials to providers for revocation.

GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Stripe and other providers were among the companies Railway said it contacted. Some providers revoked more keys than Railway could definitively tie to the breach, so receiving a revocation notice did not necessarily mean a particular key had been stolen.

There were also reports of direct financial damage. The Hacker News cited security researcher Taylor Monahan as saying cryptocurrency wallets whose private keys had been stored on Railway were drained during the incident. Railway’s own preliminary report does not establish the scope of those thefts, so that claim should be treated separately from Railway’s confirmed findings.

Railway says the attacker was hunting AI keys

Railway’s explanation of the attack is unusual. The company said its forensic evidence suggested the attacker was searching specifically for AI-provider API keys and intended to use them for model-distillation attacks. Railway also said the attacker appeared to have access to “abliterated models” and significant compute capacity, which it believes helped enable the intrusion. Its investigation was still ongoing when the preliminary report was published, and Railway said it was withholding exploit details while that work continued.

Railway said the attacker’s behavior favored workspaces with large collections of environment variables and environments containing many AI-service credentials. Its logs reportedly showed Railway staff the names of API keys the attacker’s payloads were searching for, prompting the company to contact upstream providers before its public disclosure.

That framing puts the incident into the growing problem of LLMjacking, where attackers steal access credentials for expensive AI infrastructure and consume or resell the victim’s inference capacity. Google Threat Intelligence has documented cases in which stolen model access was resold through intermediary services and generated costs exceeding $100,000 per day, with losses reaching as high as $1 million for individual victims.

Railway’s exact explanation for its attacker, however, remains Railway’s own preliminary assessment. The company has said external incident-response specialists and authorities are involved and that a fuller report will follow the forensic investigation.

Then Josh Manders asked why a Railway employee was inside Primcloud

Early on November 3, Primcloud founder Josh Manders posted a blunt question to Railway: why was one of its employees trying to breach his infrastructure? He identified the employee as Jake Runzer. Railway’s own company page lists Runzer as a product engineer.

Runzer did not deny it.

In the exchange reported by RuntimeWire, he wrote that it was indeed him and said there had been “no malice intended.” He explained that he had been running agents that signed up for similar platforms and performed agentic testing. He said he stopped the harness after realizing it had gone too far.

That admission changed the shape of the story. Manders was not merely attributing suspicious traffic to Railway based on an IP address or a guess. A Railway employee acknowledged that his tooling generated the activity.

Railway cofounder Jake Cooper then joined the thread. He described the behavior as looking “pretty agentically ‘off the rails’,” apologized to Manders and said Railway would ban non-manual external testing. In a later reply, Cooper put the responsibility more plainly: if Railway did something dumb with a model, “we gotta own it.”

The episode spread quickly enough that accounts outside the two companies weighed in publicly, including vx-underground, which tracks security and malware research. Both posts are embedded above.

Manders later published a more detailed description of activity Primcloud says it recorded. According to coverage of his posts, the activity consisted of roughly 24 scripted commands over about 15 minutes from inside a newly deployed application container. Manders said no application was actually run.

The commands reportedly tried to use credentials available inside the container to request secrets, queried what the attached cluster credentials were permitted to do, attempted to reach the cloud metadata endpoint, guessed names for internal database and cache services, and scanned the internal network twice. Manders also clarified that a command returning a successful exit status did not mean it had successfully obtained the requested data.

That distinction matters when reading screenshots of agent activity. A log showing curl, token decoding, service discovery or a port scanner tells you what the process attempted. It does not, by itself, prove that sensitive information was returned. Primcloud says its controls blocked the attempts, and there is currently no public evidence that Runzer’s harness extracted customer data from Primcloud.

There is still a large gap between testing “first time user experience” and issuing commands that inspect service-account credentials or probe a private network. Cooper later explained that the work was supposed to involve signup-to-deploy testing. Runzer’s own description says his harness reached farther than he intended.

That is the part of the story that will be difficult to wave away as a quirky AI mishap.

“The agent did it” does not solve the responsibility problem

Runzer says he had no malicious intent. Nothing currently published contradicts that statement. There is also no public evidence that Railway management instructed an employee to attack Primcloud. The available evidence supports a narrower account: a Railway employee created an automated testing system, pointed it at external platforms, and the system performed actions that its operator later acknowledged had exceeded its intended scope.

Calling the system autonomous does not make those actions ownerless.

An AI agent with shell access is software with an unusually flexible control interface. If it can execute commands inside somebody else’s infrastructure, the operator has to constrain what it is allowed to touch. A prompt saying “test signup” is not the same thing as an enforced security boundary. The controls that matter here are explicit scope allowlists, egress restrictions and hard limits on what external environments an agent may access.

Cooper’s eventual response reflects the same principle. According to the public exchange, Railway’s new policy is to ban automated external testing and require such testing to be performed manually.

The awkward part for Railway is that this lesson arrived immediately after the company had experienced a breach involving attackers crossing internal security boundaries of their own.

On October 22, Railway’s preliminary report explained how an external actor escalated through its infrastructure and reached customer secrets. On November 3, an employee was explaining how an autonomous harness he built crossed the intended boundary of testing another platform. The technical circumstances are different, but both episodes revolve around the same operational question: what can a piece of software do after it gets farther than its operator expected?

Railway now has a trust problem bigger than either incident alone

Railway’s response to the October breach included several sensible containment measures. It shut down affected systems, rotated credentials, rebuilt internal tooling, accelerated single-tenant builder infrastructure and worked with external providers to revoke potentially exposed keys. The company also published a detailed timeline quickly while acknowledging that the forensic investigation was incomplete.

The November incident is smaller in technical impact, at least from what is publicly known. Primcloud says the probing was blocked, no confirmed customer-data theft has been disclosed, and Runzer stopped the harness.

Yet the second episode may be harder to explain culturally.

Railway’s product is infrastructure. Customers hand the company source integrations, deployment credentials, databases and environment variables precisely because they expect Railway engineers to understand boundaries better than most software teams. Railway itself says it serves roughly five million existing users.

Thirteen days after Railway disclosed the breach, the company had to apologize because software operated by one of its employees had crossed boundaries on another cloud platform.

That does not make the two incidents equivalent. One was an attack against Railway. The other appears to have started as an internal testing project that escaped its intended scope. Treating them as the same event would obscure what happened.

Putting them next to each other does reveal a common failure mode that companies deploying autonomous agents are going to encounter more often. The model can decide what command to try next, but the organization still decides what credentials it receives, what networks it can reach, where it is permitted to execute and whether anyone must approve the next action.

Railway’s own cofounder reached essentially that conclusion in the public thread: whoever operates the machinery is responsible for what it does.

The ban on automated external testing is that principle applied to Railway’s own engineers.

Sources

Railway: Preliminary report on the October 21 security incident
Railway: Security disclosure, October 21
The Hacker News: Railway says intruder may have accessed customer secrets
GitGuardian: New Railway incident, treat every environment variable as exposed
Google Cloud: The rise of LLMJacking
RuntimeWire: Railway cofounder apologizes after employee accused of trying to breach Primcloud
explainx: Railway agents vs Primcloud, claimed versus verified
Josh Manders’s November 3 post asking why a Railway employee was probing Primcloud
vx-underground’s post on the incident
Timo’s post on the incident
International Cyber Digest’s coverage of the incident