TL;DR: Akeyless’s October 2026 analysis shows that encrypted environment variables can still be decrypted if attackers compromise the systems authorized to read them, with up to 100,000 workspaces potentially affected. Encryption at rest is not a control boundary when the decryption path remains under someone else’s control, and that assumption now matters for every secrets programme.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Akeyless's report: Railway’s October 2026 breach exposed how encrypted environment variables can still be decrypted when attackers compromise the systems that authorize decryption, affecting up to 100,000 workspaces.
Why it matters: IAM, PAM, and NHI teams need to treat decryption authority, secret sprawl, and AI provider keys as governance problems, not just storage problems, because compromise can bypass encryption without breaking it.
By the numbers:
- Railway estimated that 1.85% of workspaces, roughly 100,000, could have had some environmental variables compromised.
👉 Read Akeyless's analysis of the Railway breach and secrets exposure
Context
Encryption at rest protects stored secrets, but it does not remove the need for a trusted decryption path. In this incident, the practical question is not whether the variables were encrypted, but who could authorize decryption and how much that authority exposed when compromised.
For identity programmes, that distinction matters because environment variables, CI secrets, and agent configurations often sit in the same trust chain as service accounts and API keys. When a provider can decrypt on behalf of customers, the provider’s access model becomes part of the customer’s secret sprawl challenge.
Key questions
Q: What breaks when encrypted secrets can still be decrypted by the platform that stores them?
A: Encryption protects stored data only until the decryption authority is compromised or misused. If a platform can reconstruct plaintext for normal operations, attackers who breach that platform may inherit the same power. The failure is not encryption itself but the trust model around decryption, which makes decryption paths part of the attack surface.
Q: Why do static environment variables create so much risk for cloud and AI credentials?
A: Static variables persist across builds, deployments, and agent workflows, which gives attackers more time and more places to reuse a stolen secret. The longer a credential remains valid, the harder it is to contain exposure and the more recovery work follows. Short-lived credentials shrink that blast radius by limiting both lifetime and reach.
Q: What are the signs that secret governance is failing in AI and workload environments?
A: The clearest signs are secrets that remain active outside their original workload, access paths that cannot be tied to a current owner, and role usage that appears only in telemetry, not in governance records. Those patterns show the vault is holding credentials, but not governing their lifecycle or real-world use.
Q: How should teams reduce the impact of a provider compromise without shutting down operations?
A: Separate high-value secrets from provider-held plaintext wherever possible, and use brokered or just-in-time access for the credentials that must remain in circulation. That reduces the number of secrets an attacker can recover if one platform is breached. The goal is to make compromise of one control plane less likely to expose the whole estate.
Technical breakdown
Why encrypted secrets still become plaintext
Encryption at rest protects data while it is stored, not while it is being legitimately used. If a platform must decrypt secrets to inject them into builds, runtime services, or automation, then the decryption path becomes the real security boundary. Once an attacker compromises the systems or credentials that sit on that path, they can often obtain plaintext without breaking the underlying cryptography. The control failure is not weak encryption. It is excessive trust in the component that can decrypt on demand. See the Encryption Guide.
Practical implication: Treat decryption authority as a privileged function and reduce how often platforms can independently produce plaintext secrets.
Why static environment variables are a high-value target
Static environment variables are convenient because they are easy to inject into applications, but that convenience creates persistence. A secret that stays valid for weeks or months gives an attacker more time to find, copy, and reuse it. In cloud and AI workflows, static keys often accumulate across CI systems, deployment tooling, and agent configs, which expands the number of places a compromise can turn into reuse. The technical issue is not just storage. It is credential duration plus reach. See the API Key Management Guide.
Practical implication: Prefer short-lived secrets where possible and reserve static variables for the narrow set of services that truly require them.
How agent workflows turn API keys into blast radius
AI agent stacks often expect provider keys in the environment, which means the agent and its surrounding tooling can inherit powerful credentials by design. That creates a wider blast radius than a normal application secret because the credential may be available to prompts, plugins, logs, or chained automation. When the same key can be used for inference, billing, or downstream tool access, compromise is no longer limited to one application. The mechanism is credential reuse across the agent runtime, not just exposed storage. Read the Ultimate Guide to NHIs: What are Non-Human Identities.
Practical implication: Broker agent access so the agent does not directly hold the keys it uses.
Threat narrative
Attacker objective: The attacker aimed to obtain AI provider API keys and use them for model distillation and related abuse.
- Entry occurred through access to internal systems that contained customer environment variables, giving the attacker a foothold in the decryption path.
- Credential access followed when the attacker obtained additional API access and could decrypt a subset of the stored secrets.
- Impact came through potential exposure of AI provider keys and widespread credential resets, which also disrupted builds and deployments.
Breaches seen in the wild
- Railway breach 2026: Stolen CI credentials let an attacker decrypt some Railway customer environment variables while hunting AI provider keys. Entry point not disclosed.
- 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Decryption authority is the real trust boundary: the breach worked because the platform could still reconstruct plaintext for legitimate use, and that authority became the attack path once internal systems were compromised. Encryption at rest did not fail technically; the governance model failed because decryption remained centrally reachable. The implication is that secrets programmes must measure who can decrypt, not just where data is stored.
Static credential exposure creates a longer incident tail: the most expensive part of this event was not only the breach itself but the need to reset and replace credentials after exposure. Static secrets remain valid across build systems, dashboards, APIs, and agent configs, so one compromise can generate a long recovery window. The practitioner conclusion is that secret lifetime is a security decision, not an operational afterthought.
AI provider keys are now high-value operational credentials: Railway’s attackers were reportedly hunting keys for model distillation, which means the target was not generic data theft but reusable access to AI services. That changes governance because AI keys can now carry direct financial, service, and abuse risk, especially when they live in environment variables or agent runtimes. Teams should treat these keys as production identities, not setup conveniences.
Zero-knowledge secrets management is a governance reset, not a feature upgrade: the core lesson is that provider-held decryption capacity is itself a dependency that must be governed. If the service can independently recover customer plaintext, then a compromise of that service can become a compromise of the secrets it protects. Aseparate custody model changes the trust assumption, which is the point.
Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret custody is becoming a design choice, not a storage detail: the next generation of secrets governance will be judged by whether a platform can independently reconstruct customer plaintext. When that answer is yes, the customer inherits the provider’s compromise risk as part of its own control plane.
AI key governance now sits inside identity governance: environment variables, agent configs, and CI secrets are effectively production credentials, so lifecycle control has to include ownership, revocation, and brokered access. If the organisation cannot account for every AI provider key, incident response will always start from a weak inventory.
Credential blast radius, not encryption strength, is the practical metric: the more places a static secret can live and the longer it stays valid, the more a single compromise can spread across builds, dashboards, and downstream services.
For practitioners
- Inventory every AI provider key and secret Map where each key lives, who owns it, and which services or agents depend on it, including environment variables, CI stores, and runtime configs.
- Challenge every vendor on decryption authority Obtain a written answer to whether the provider can independently decrypt customer secrets, and record that answer in your risk register.
- Convert high-value static credentials first Move the most sensitive database, cloud, and AI credentials to short-lived or just-in-time access where the target systems support it.
- Broker agent access without exposing secrets Place a mandatory control point between agents and targets so the agent receives access through mediation rather than holding the credential directly.
- Automate revocation playbooks for exposed keys Pre-stage rotation and revocation workflows so a leak in one environment variable does not become a manual multi-day recovery exercise.
Key takeaways
- The breach shows that encryption at rest does not prevent exposure when the platform can still decrypt secrets on behalf of customers.
- Railway estimated that up to 100,000 workspaces could have had some environment variables compromised, which created a large recovery burden.
- Teams should focus on decryption authority, secret lifetime, and brokered access, because those controls determine how far one compromise can spread.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · API Key Management Guide · Secrets Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The breach exposed stored secrets through a compromised decryption path. |
| NHI-07 — Long-Lived Secrets | Static environment variables and persistent API keys extended the recovery burden. | |
| Recommendation — Reduce secret leakage exposure by removing plaintext from long-lived storage and tightening where secrets can be decrypted. Replace long-lived secrets with short-lived credentials wherever the application path allows it. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central to rotating exposed API keys and other authenticators. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of exposed credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident turned on who could authorize decryption and access secrets. |
| Recommendation — Review decryption permissions and entitlements so no single compromise can unlock the full secret set. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attacker sought credentials and used them to obtain plaintext secrets. |
| Recommendation — Map secret exposure paths to credential access and exfiltration to prioritise detection and containment. | ||
Key terms
- Decryption Path: The decryption path is the set of systems, permissions, and operational steps that can turn encrypted data back into plaintext. In identity security, the path matters as much as the ciphertext because any compromise of that path can expose secrets without breaking encryption itself.
- Zero-Knowledge Secrets Management: Zero-knowledge secrets management is a custody model where the service provider cannot independently recover customer secrets in plaintext. The cryptographic design separates control so that provider compromise does not automatically reveal stored credentials, tokens, or environment variables.
- Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
- Brokered Access: Brokered access is a model where the user or workload proves identity to an intermediate control plane that issues short-lived access instead of exposing a reusable secret. For privileged operations, this shifts governance from secret storage to session control, auditability, and timely revocation.
What's in the full article
Akeyless's full report covers the operational detail this post intentionally leaves for the source:
- The preliminary incident timeline showing how Railway detected, contained, and disclosed the breach
- Operational guidance on rotating exposed credentials across cloud, database, and AI provider environments
- The provider-side explanation of zero-knowledge secrets handling and distributed fragment custody
- The SecretlessAI and agentic runtime control model for brokered access without exposing keys to agents
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 27, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org