What happened
Railway’s final incident report, last updated at 18:02 UTC on 10 November 2026, said the intrusion ran from the first exploit at 07:28 UTC on 20 October until the attacker was fully evicted at 09:24 UTC on 21 October 2026. Railway said at most 1.85% of workspaces, about 100,000, could have had environment variables decrypted; the logs identify environments, not individual variables, so this is an upper bound.
The attacker read 353 build histories and decrypted linked-account tokens for 1,852 users, including BYOK agent keys and GitHub OAuth tokens; Railway reset those tokens and found no login using them. Unauthorised spend on stolen keys was estimated at approximately $740,000. Railway said indicators were being shared privately and had not published them by the final report.
Railway described a harness similar to ARTEX; it did not identify the exact framework. No underlying model or version was identified in the cited sources. The operator created a swarm of accounts and used queries matching AI-provider key names; Railway did not publish the agent configuration. The attack tooling probed multiple routes in parallel and the operator’s database queries prioritised AI-provider key names; the sources do not establish whether any individual action was performed by an AI model rather than the operator. Attribution posture: Railway named no actor and has not established whether the original intruder operated the downstream credential-resale services.
Why this matters now
An AI-provider key is both a privileged machine identity and a payment instrument. Once stolen, it can produce direct usage charges without accessing the victim’s bank account or traditional payment card. Security, FinOps, procurement and legal teams therefore share ownership of containment and loss allocation.
The breach crossed multiple control planes: multi-tenant build infrastructure, internal orchestration, encrypted-variable storage and an upstream key-management service. The upper bound is large, but Railway’s logs identify potentially affected environments rather than each decrypted variable. Customers must not confuse population-level exposure with proof that every secret was taken.
Railway’s account of searches for AI-provider key names shows why generic secret rotation is too slow. Keys should be scoped to one workload, limited to necessary models and protected by hard spending limits and behavioural alerts. Provider refund terms should be known before an incident, not negotiated after unauthorised consumption.
The decision for security leaders
Cloud platform and IAM owners should treat every relevant secret stored before containment as requiring a documented disposition. Rotate AI-provider keys first because they can create immediate cost, then cloud, database, payment, repository and registry credentials according to reachable privilege.
AI service owners and FinOps should reconcile model usage by key, workload, source address and model family. Submit provider refund claims separately from credential revocation; a financial dispute does not invalidate a stolen key or stop further consumption.
Procurement and architecture leaders should require evidence describing who can decrypt tenant secrets, how decryption is logged, whether workloads receive unique short-lived identities and how fraudulent use is allocated contractually. AI-agent governance should cover the credentials an agent can spend, not only its prompts and tools.
Evidence of closure
- Provider consoles show old keys revoked and replacement keys active.
- Billing review reconciles unauthorised usage and submitted refund claims.
- Cloud and repository audit logs show no unexplained access.
- Secrets architecture documents per-workload scope, expiry and decryption logging.
The Security.io assessment
The October intrusion was already known; the final report changed the enterprise decision by quantifying an upper-bound exposure population, token categories and financial impact. The figures are vendor-reported and should guide response prioritisation without being misrepresented as a confirmed count of individually decrypted secrets.
Railway’s forensics did not indicate customer databases were accessed, and it found no Railway-account login using the reset linked-account tokens. Those negative findings narrow the confirmed impact but do not remove the need to review downstream provider usage, repositories, registries and any service reached with stolen credentials.
The durable lesson is architectural: envelope encryption does not prevent disclosure when a compromised internal identity can obtain encrypted records and invoke decryption. Closure should therefore include reduced decryption authority, central audit logging, short-lived per-workload credentials and spending controls that contain misuse even after a secret escapes.
Questions for the morning meeting
- Who absorbs fraudulent AI usage when providers refuse refunds?
- Which platforms can decrypt customer secrets at runtime?
- Are AI keys treated as privileged machine identities?
- Can one platform compromise multiple model providers?