Northflank Breach: Assume Your AI API Keys Are Decrypted

What Northflank disclosed

Northflank is a platform for deploying applications, containers, databases, and AI workloads without managing your own servers. Like most platforms in this category, it asks customers to paste their API keys — database passwords, cloud credentials, and increasingly OpenAI, Anthropic, and Bedrock keys — into an environment variable store, which Northflank then encrypts at rest and decrypts to inject into the customer's running workload.

On October 30, Northflank received a threat alert from cloud security firm Wiz and opened a public incident. Its status page updates escalated quickly, from telling customers to rotate their secrets as a precaution to a blunt instruction a few hours later: treat every stored environment variable as already in attacker hands. Later that evening, Northflank confirmed what its own warning had anticipated — multiple customers reported that AI API keys they had stored on the platform were already being used without authorization.

As of this writing, Northflank has not said how the attackers got in, how many customers were affected, or whether anything beyond AI provider keys was read and abused. That's a reasonable amount for a platform to still not know two days into an active incident — but it also means customers are rotating secrets without knowing the actual blast radius, which is exactly why "assume everything is decrypted" became the operative guidance rather than a narrower, more comfortable claim.

Part of a month-long pattern, not an isolated incident

Wiz's research team gave the month a name: "Black October for AI Developer Platforms." Its report counts at least nine AI developer platforms that disclosed security incidents in October 2026 alone — Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, and Northflank among them. Wiz's framing is consistent across the list: attackers went looking specifically for stored environment variables, with AI provider credentials as the priority target, because those keys can be resold or run up enormous inference bills before anyone notices.

Northflank's own incident sits next to Railway's, disclosed ten days earlier. Railway's preliminary report said an attacker accessed its internal systems and decrypted stored environment variables for a subset of workspaces, with the company estimating that at most 1.85% of all workspaces — roughly 100,000 — had some variables potentially compromised. Fireworks AI, Zeabur, and the rest of the list vary in root cause and scope, but they share the same object of interest: a central store of customer secrets that, if an attacker gets far enough in, can be turned back into plaintext.

Why "store the key, inject it later" keeps failing the same way

The architecture underneath Northflank, Railway, and most platforms in this category is not unusual or careless by industry standards. Customers provide a secret. The platform encrypts it at rest. When a workload needs the credential, the platform decrypts it and injects it into the environment as a plaintext variable, where the application reads it directly. This is how environment-variable-based secrets management has worked for over a decade, and it's the default pattern baked into nearly every PaaS, CI system, and container orchestrator.

The problem is what that architecture requires to function: somewhere in the platform's infrastructure, there has to be a path from "encrypted blob" to "plaintext key the application can use." That path is also the attacker's path. Once someone compromises the right internal system — a build service, an API layer, a credential broker — the same decryption capability the platform uses to serve legitimate workloads is available to them. Encryption at rest protects a database dump; it does not protect a service that is designed to decrypt on demand.

That's why Northflank's own language is the honest one: not "we believe some keys may have been accessed," but "assume all environment variables have been decrypted." When the compromise is inside the layer that does the decrypting, there's no narrower, more reassuring claim available. Every key that ever passed through that layer has to be treated as burned.

The alternative: never let the real key land anywhere

There's a structurally different way to handle third-party API keys, and it's worth stating plainly rather than overselling: a proxy-injection model, where the real OpenAI, Anthropic, or Bedrock key is injected at the network egress point — the outbound call to the provider — and never handed to the application process, the CI runner, or the container's environment variables at all. The app holds a reference or a scoped, short-lived credential; the gateway swaps in the real key only on the wire, on the way out to the provider.

This doesn't make a platform breach impossible, and it wouldn't have stopped Northflank's attackers from reaching whatever internal system they reached. What it changes is what's there to steal. If an attacker compromises the application layer, the CI environment, or even a customer's own container, there's no live, usable key sitting in an environment variable to decrypt or exfiltrate — because the key was never placed there. The thing a platform-level breach is hunting for simply doesn't exist in that location. That's the practical distinction between "store the key and inject it later" and "never store a usable copy of the key where a runtime can read it."

This is the core idea behind KnoxCall's AI gateway architecture: API keys for OpenAI, Anthropic, Bedrock, and other providers are injected at the egress wire, not handed to app processes, env vars, or AI agents. It's a genuinely different failure mode than the one Northflank, Railway, and the rest of the Black October list are working through this week — not because the vendor is less likely to be breached, but because a breach of the surrounding infrastructure has less to find.

What to do if you have keys on Northflank — or any similar platform

• Rotate at the source, not just in the dashboard. Revoke the key with OpenAI, Anthropic, AWS, or whichever provider issued it, then generate a replacement. Rotating only inside Northflank leaves the old key valid everywhere else it was ever copied.
• Check provider usage and billing logs, not just Northflank's. LLMjacking shows up as unexpected inference volume or unfamiliar regions in your OpenAI, Anthropic, or Bedrock usage dashboard, often before a platform confirms anything.
• Rotate everything in scope, not just AI keys. Northflank's own guidance covers secrets on workloads, secret groups, and global secrets — database passwords and cloud credentials included.
• Disable public exposure on database add-ons if you'd enabled it, and turn on audit logging now that Northflank has made it available to all accounts, including free tiers.
• Treat this as a prompt to re-architect, not just re-rotate. If the same category of platform can be breached again — and the nine-incident month suggests it will be — the question worth asking is whether your keys need to live in a decryptable store at all.

What's still unknown

Northflank has not published a root-cause analysis. It hasn't said how attackers reached the system that decrypts environment variables, how many customers were affected, or whether non-AI secrets were abused as broadly as AI keys were. Those are the honest gaps as of this writing, and any article claiming more certainty than that is guessing. What is confirmed: the alert came from Wiz, the company told customers to assume full decryption, and customers reported real, unauthorized AI API usage within hours of that warning.

For a deeper look at why environment variables are a weak place to keep credentials even outside platform breaches, see KnoxCall's security overview and our related piece on the credential attacks no checklist can stop.