Changing a Northflank secret may leave the stolen key active

Updating Northflank environment variables does not disable stolen credentials or stop unauthorized AI API…

Changing a Northflank secret may leave the stolen key active

The short version

  • Replacing a secret in Northflank does not revoke a stolen copy; the issuing provider must disable it.
  • Northflank reported unauthorized AI-key use, but has not confirmed affected customer counts, providers, or broader credential abuse.
  • Customers should replace credentials across every workload, verify old values fail, and inspect provider usage and billing.

Changing a secret in Northflank can leave the stolen copy alive and billing your account. Revoke exposed credentials with their issuers, replace them across workloads, then inspect provider usage and billing for damage.

That sounds obvious until you are operating on a live system while workers reconnect with yesterday’s database password. I once ate a cold margherita beside a terminal because one forgotten process refused to die. Mozzarella and regret.

The Northflank security incident on October 30, 2026 pushed recovery beyond its dashboard. An environment variable may hold an AI key, cloud credential, database password or payment token. Northflank can change what gets injected into an application, but only the issuer controls whether the old credential still works.

That decides whether an attacker gets locked out or enjoys another evening of free compute.

The alert outran the evidence

The company’s official timeline says Wiz sent a threat alert at 11:43 UTC. Engineers reviewed it one minute later and deployed the first network-policy patch 19 minutes after the alert. Fast response. I have watched six founders spend longer choosing an emoji for an “urgent” Slack channel.

Bar chart comparing current figures against their baselines: Terminal-Bench 4.0 score 41 % versus 28 %, Artificial Analysis Cyber Index score 51 % versus 34 %, Artificial Analysis Cyber Index score 51 % versus 57 %.

The timeline leaves major forensic questions open. Northflank has not disclosed the initial access path, exploited vulnerability or attacker technique. We do not know when access began, which customers or regions were affected, or whether any customer’s environment variables were read. The number of exposed credentials, duration of misuse and financial cost tied specifically to Northflank remain unknown.

Here is how I decide under that uncertainty. Wiz’s alert triggered investigation and network-policy patches. Instructions to treat environment variables as decrypted expanded recovery from a platform fix to customer credential rotation. Reports of unauthorized AI-key use widened it again: issuers had to revoke those credentials, while customers needed replacements, updated workloads, and usage and billing reviews. Each step expanded the boundary because a copied credential survives closure of the route that exposed it. Forensics can establish scope later. A valid bearer token works meanwhile.

Telling customers to assume exposure before proving exactly what happened was correct. Security teams need a safe posture while evidence is incomplete. The instruction does not prove every environment variable was accessed or decrypted. A later update said the investigation remained ongoing, with no further confirmed findings.

That wording matters. Customer reports of unauthorized use justify immediate revocation, but attribution requires provider logs, matching timestamps and evidence linking requests to this incident. Nobody has publicly completed that chain for every reported charge.

Nor is there a confirmed link between Northflank and one wider campaign against AI developer platforms. Wiz reported broader attacks targeting stored credentials, but found no shared vulnerability or dependency connecting every incident. Similar targets attract similar thieves. We can skip the cinematic mastermind stroking a cat.

A network patch closes a door. Keys carried through it now have their own life.

Why an updated AI key may keep costing money

Users reported unauthorized use of AI API keys supplied to the platform, according to Northflank. The company did not publish the providers, usage volume or affected-customer count. It also has not confirmed abuse of credentials beyond those reported AI keys.

An AI API key usually acts as a bearer credential: whoever presents a valid copy receives its permissions without proving ownership. An attacker can test it with a small request, then automate calls or add it to a resale pool. The AI provider sees a valid key and charges its owner. Because requests go directly from attacker to provider, Northflank may never see them. Editing an environment variable switches the legitimate application to a new key while the attacker spends through the copied one.

A successful redeployment answers half the question. The application may be healthy while an attacker burns money through its previous secret. A green deployment badge has excellent bedside manner and little forensic value.

The guidance used the right order for reported AI-key abuse: revoke with the issuer, generate a replacement, update Northflank secrets and workloads, then inspect usage and billing. When abuse is active, revocation comes first. I will accept a brief outage before someone keeps setting euros on fire.

Provider records may show when the stolen key first appeared, whether requests continued after replacement, and how much activity reached the account before revocation stopped it. Review billing separately because usage dashboards and invoices may expose different clues. Preserve useful timestamps and request identifiers before opening support tickets with Northflank and the provider.

Magnifying glass rests over activity records beside euro-marked invoice sheets, clips, and red accounting lines.

Wiz has described similar interest in AI credentials across developer platforms, though it has not tied every incident to one attacker or exploit. The economics need no elaborate theory: stolen compute becomes inventory, and somebody else gets the invoice. Molto conveniente, if you are the thief.

“LLMjacking” sounds like cyberpunk wizardry. The mechanism is ordinary credential theft in a fashionable outfit.

Rotation has to cross both systems

In an update published early on October 31, Northflank said it had enabled audit logs for every customer, including free users. Put them in the incident folder immediately, though newly available records may not reconstruct every earlier action. Because the public timeline does not identify when possible access began, search before the Wiz alert.

Rotation controls for managed add-ons were also progressively enabled. They help because Northflank manages both the secret and its service connection. User-supplied AI keys cross another boundary: Northflank stores and injects them, but the AI provider decides whether they remain valid.

Marjorie Janiewicz said:

I don’t want to get disconnected. I want to own my model.

Complete rotation crosses both systems. Find every location holding the credential, including workloads, secret groups and global secrets. Revoke or disable the old value at its issuer, create a replacement, update every legitimate consumer and redeploy affected workloads. Check forgotten workers, scheduled jobs, staging environments and local scripts still presenting the old value. Finally, test it and confirm the issuer rejects it. Rotation ends when the stolen copy fails.

Build the inventory around the issuing service, credential owner, revocation location and every consuming workload. Treat unused keys with extra suspicion because nobody notices when their behavior changes. A secret marked “updated” in one dashboard is comforting like a clean kitchen while the gas remains on.

Order depends on the credential. Kill active AI keys, payment tokens and powerful cloud credentials immediately when abuse appears. Database credentials often need overlap: create a second user, deploy it, verify connections, then disable the previous account. That avoids turning precautionary rotation into a self-inflicted outage.

One universal “rotate all” button would be lovely. So would calorie-free carbonara.

After revocation, inspect provider records for activity surviving the initial exposure window and compare it with expected application behavior, especially when the old credential had broad permissions or no practical spending cap. Establish when the copied secret stopped working. Without proof, “rotated” describes an administrative action, not a security outcome.

The instruction to assume decryption was deliberately broader than confirmed findings. That conservative posture deserves credit, but customers need their own evidence because the company has not published the number or identity of affected projects, credentials, regions or AI providers. We also do not know whether credentials beyond the user-reported AI keys were abused.

This is incident response’s frustrating bit: the platform tells everyone to move, but each customer must prove where its feet were standing.

Make the next stolen key boring

A deployment platform concentrates credentials from many customers and external services in one operational layer. That makes it useful, and attractive to attackers. Recovery is easier when each stolen credential has a narrow blast radius and short life.

Arthur Mensch said:

be a tool for empowerment, not dominance.

Segmentation changes the economics predictably. Give each application and environment a restricted key, and one theft reaches fewer workloads. Short expiration reduces abuse time. Provider quotas and spend alerts cap the invoice and expose unusual activity earlier. Model, region or cloud-role restrictions reduce what a credential can buy or reach. Runtime identity removes long-lived pasted tokens where supported. A machine-readable inventory shows responders who owns each credential, which workloads use it and where to kill it.

Run a timed rotation drill this month. Pick one AI key, find every consumer, replace it and prove the old copy fails. Record the time. If this requires searching old Slack threads or messaging the one engineer hiking in Patagonia, the inventory has failed.

The strongest objection is that facts remain incomplete. Northflank described environment-variable decryption as an assumption customers should act on, and its later update said the investigation was ongoing with no further confirmed findings. The affected scope may eventually narrow. That does not change the immediate decision: an exposed bearer credential can keep generating charges while everyone awaits forensic certainty.

By the next incident, AI credential theft will be more automated because the transaction is clean: test the key, consume or resell access, send the bill elsewhere. I expect engineering teams to measure credential revocation time alongside application recovery time by the end of 2027, because a restored workload can coexist happily with an active thief.

Ask one question in the next engineering meeting: If the alert arrived at five this afternoon, when would every old credential be provably dead?

If the answer starts with finding them, start the clock now.

Frequently asked questions

Is changing an exposed secret in Northflank enough?

Updating a secret in Northflank changes what the platform injects into legitimate workloads, but it does not invalidate a copy already held by an attacker. The old credential must be revoked or disabled with its issuing provider, then every legitimate consumer must receive a replacement and be redeployed.

Did Northflank confirm that stolen AI API keys were abused?

Northflank said users reported unauthorized use of AI API keys stored on the platform. It did not publish the providers, usage volume, or affected-customer count, and it has not confirmed abuse of other credentials. Attribution still requires provider logs, matching timestamps, and evidence connecting requests to the incident.

What should Northflank customers check after rotating credentials?

Customers should inspect provider usage records and billing separately, preserve timestamps and request identifiers, and compare activity with expected application behavior. They should search from before the Wiz alert because the public timeline does not identify when possible access began, then confirm exactly when each revoked credential stopped working.

Sources

Related reading

Luca

Luca

Luca by the way is the personal blog of Los Angeles based entrepreneur Luca Capula. A true Italian who lives between Torino and LA.

More posts →