October 27, 2026
Posted by Refael Angel
Summary:
Railway’s October 2026 breach exposed a critical limitation of encryption at rest: attackers who compromise the systems authorized to decrypt secrets can obtain plaintext without breaking the encryption itself. Railway confirmed that some customer environment variables were decrypted, with up to 100,000 workspaces potentially affected. The incident also disrupted deployments and triggered widespread credential resets. It underscores the need for Zero-Knowledge encryption, short-lived credentials, and security architectures that keep secrets out of AI agents’ hands.
What Happened in the October 2026 Railway Breach?
On October 21, platform operator Railway disclosed that an intruder accessed internal systems containing customer environment variables, and in some cases decrypted and read them Railway estimated that 1.85% of workspaces, roughly 100,000, could have had some environmental variables compromised. Railway’s preliminary investigation showed that attackers were specifically after AI provider API keys to support model distillation attacks. Railway worked with GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Stripe, and others to revoke the stolen credentials, and advised all customers to rotate every credential stored before that date.
The consequences extended beyond potential credential exposure. Railway halted new builds and deployments during containment, while customers experienced interruptions to its dashboard, API, and CLI. Existing applications remained online, but engineering teams faced widespread credential resets and, in some cases, additional recovery work to restore integrations and deployments.
Railway handled disclosure responsibly, publishing a detailed preliminary report while its investigation continues. But the incident raises a fundamental question for every organization that entrusts a provider with its secrets: if an attacker compromises the systems authorized to decrypt them, how much sensitive information could become accessible, and what would it cost the business to recover?
Encryption at Rest Cannot Protect a Compromised Decryption Path
Railway’s environment variables were encrypted. That slowed the attackers, but it didn’t stop them. The platform had to be able to decrypt them to inject them into builds and running services. By compromising internal credentials and gaining additional API access, the attacker ultimately obtained the ability to decrypt a subset of those secrets. The lesson is clear: whoever controls the platform controls the decryption path. An attacker who gets deep enough inherits that path.
This is true of any provider that holds the master key, including the native cloud secrets managers and most SaaS vaults. The question to ask any secrets vendor is not “do you encrypt?” It is “who can decrypt?” If the answer includes the vendor, the answer also includes anyone who compromises the vendor.
Railway’s Attackers Were Shopping for AI Keys
Railway’s analysis indicates that the actor was targeting workspaces with large numbers of environment variables and high concentrations of AI vendor keys, with the goal of running distillation attacks against inference providers. The same week brought the OpenCode console breach exposing OpenAI, Anthropic, and Google keys, and Symantec’s report of an autonomous agent running 100,000-step LLMjacking campaigns.
AI provider keys are now the most liquid credential on the market. Anyone holding one can run inference at the owner’s expense, strip-mine a model, or feed an offensive agent. And they are overwhelmingly stored the way Railway’s were: as static strings in environment variables.
Finding and replacing compromised keys becomes even harder when you don’t know where they all are. The 2026 State of AI Agent Identity Security report found that only 44% of surveyed leaders knew where all credentials and secrets used by their AI agents were stored. When security teams cannot account for every credential, even determining what needs to be revoked becomes a significant incident response challenge.
What Was Missing: Zero Knowledge + Dynamic Secrets
Two properties could have changed the Railway breach outcome entirely.
1. Zero-Knowledge: the vendor cannot decrypt what it does not have. Akeyless is built on patented Distributed Fragments Cryptography™. Encryption keys exist only as independently generated fragments held in separate locations, and one of them, the Customer Fragment, never leaves the customer’s environment. The fragments are never assembled into a complete key, even during cryptographic operations. A full compromise of Akeyless infrastructure yields ciphertext that Akeyless itself cannot read. The platform is FIPS 140-3 validated (NIST CMVP #5227), and customers who need hardware custody can hold their fragment in an HSM.
2. Dynamic secrets: there is nothing to steal because nothing persists. A static API key is a credential waiting to be exfiltrated. Akeyless replaces it with a just-in-time credential: created at the moment of use, scoped to the minimum permission for that task, and revoked or allowed to expire when its TTL ends. Where a static credential is unavoidable, Akeyless rotates it automatically on schedule or on event, across databases, cloud accounts, SSH, Kubernetes, and SaaS. Railway’s “rotate everything” warning becomes a non-event, because rotation is already continuous.
Take the Key Away from the Agent Entirely
The Railway attackers went looking for AI provider keys in environment variables because that is where agent frameworks expect them. Akeyless SecretlessAI® removes those keys from the agent altogether, while Akeyless Agentic Runtime Authority governs what the agent can do with the access it receives.. The agent holds zero credentials and has zero direct network path to any target. Every action is brokered through the Akeyless Gateway, where a short-lived credential is injected into the session, invisible to the agent, and destroyed when the session ends. An intent classifier checks each request against the originating prompt before access is granted, responses can be masked for PII and secrets, and every action is written to one audit chain from human prompt to target command. Whatever your agents speak (MCP, OpenAI, Anthropic, Gemini, Bedrock, LangChain, CrewAI, AutoGen), the Gateway speaks it.
What to Do Now
- Inventory every AI provider key your organization holds and where it lives. Record who owns it and which services depend on it. Env vars, CI secrets, and agent configs count.
- For each secrets store you use, get a written answer to “can the vendor decrypt this?”
- Convert the highest-value static credentials to dynamic, just-in-time access where supported, starting with database and cloud credentials. For AI provider keys that must remain static, broker their use without exposing them to agents and automate rotation where supported.
- Put a mandatory choke point between agents and targets, so a prompt-injected agent has no target credentials to surrender and no direct route around your access controls.
Railway’s customers spent this week rotating. The goal is an architecture where that week never happens. With encryption keys the provider cannot reconstruct, fewer persistent credentials to revoke, and AI agents that never handle the secrets they use, there’s less for attackers to take and less for customers to recover.
Book a 30-Minute Secrets Exposure Review. We’ll help you assess who can decrypt your secrets, where persistent credentials remain exposed, and how to move your AI workloads toward brokered, credential-free access.
Frequently Asked Questions About the Railway Breach
What happened in the October 2026 Railway breach?
Attackers compromised internal systems at platform operator Railway and obtained access to encrypted customer environment variables. By compromising additional credentials and gaining API access, they were able to decrypt a subset of those secrets. Railway suspended builds and deployments during containment and coordinated widespread credential resets with affected service providers.
How many Railway customers were affected by the breach?
Railway estimated that up to 1.85% of its workspaces, approximately 100,000, had environment variables potentially compromised. This does not mean every secret in those workspaces was decrypted. As a precaution, Railway recommended that all customers who had stored sensitive credentials before October 21 rotate them.
Why didn’t encryption protect Railway’s secrets?
Encryption at rest protects stored data, but platforms still need a way to decrypt secrets for legitimate use. Railway’s attackers compromised internal credentials and gained sufficient access to decrypt some customer environment variables. The incident illustrates why protecting encrypted data also requires securing who can authorize and perform decryption.
How does Zero-Knowledge secrets management protect against provider compromise?
Zero-Knowledge secrets management separates cryptographic control so the service provider cannot independently decrypt customer secrets. Akeyless uses Distributed Fragments Cryptography™ (DFC™), with independently generated key fragments held in separate locations, including the customer environment. The complete encryption key is never assembled, preventing a compromise of Akeyless infrastructure alone from exposing protected secrets.
Can dynamic secrets eliminate the risk of stolen API keys?
Dynamic secrets reduce credential-theft risk by issuing short-lived, narrowly scoped credentials when needed rather than relying on persistent keys. However, not every service supports dynamic credential issuance. Where static API keys remain necessary, centralized credential brokering, automated rotation, and least-privilege access can reduce exposure and simplify incident response.
How can AI agents access services without holding API keys?
Akeyless SecretlessAI® brokers access through the Akeyless Gateway, keeping downstream credentials out of AI agents’ environments and context windows. Akeyless Agentic Runtime Authority adds intent-aware policy enforcement to control what agents can do with that access, while providing audit records that link agent actions to the originating request and policy decision.
