AI API Key Security After the Northflank Breach: What Cloud Hosting Teams Must Do This Week
On October 30, 2026, cloud hosting platform Northflank told every customer to assume their stored environment variables had been decrypted. Not as a precaution. As a statement of fact: "Assume all environment variables have been decrypted. Disable/rotate all keys."
By 15:12 UTC that same day, Northflank confirmed that multiple customers had already reported unauthorized use of their AI API keys. OpenAI keys. Anthropic keys. Inference credentials that cost money per request and carry no default spending cap.
Sources: BleepingComputer, mezha.net, Northflank's own status page timeline.
Why AI API keys are more dangerous than database passwords -
Most teams treat AI API keys the same way they treat a database password: sensitive, yes, but just another credential. The distinction matters more than most ops leads realize.
A stolen database password gives an attacker access to your data. That is bad. A stolen AI API key gives an attacker access to your billing account. They can run inference at your expense, with no physical limit except your credit card ceiling. They can exfiltrate prompts and responses. If the key has write access to fine-tuning or assistant configuration (as OpenAI keys do by default), they can modify your AI behavior.
Database credentials are typically scoped by default: a read replica user cannot drop tables. AI API keys are almost never scoped by default. A freshly created OpenAI key can access every API endpoint, every model, every assistant, and initiate billing events.
The cloud security context here matters: Northflank is the ninth AI developer platform breached in October through stolen environment variables. The target is consistent: AI keys first, everything else second. Attackers know which stored secrets generate immediate, billable value.
The ops failure pattern -
Cloud platforms like Northflank, Railway, Render, Heroku, and Fly.io all offer environment variable storage as a first-class feature. It is the documented, recommended way to configure deployed applications. It is what every tutorial, starter repo, and onboarding checklist points to.
The problem is not that teams use environment variables. The problem is that teams use the same credential management practice for a $0.002/token inference key that they use for a development database URL.
The specific failure pattern looks like this:
- Developer creates an AI API key at the provider.
- Key is pasted into the cloud platform's environment variable interface.
- Key rotates when someone remembers, which is never, because nothing broke.
- Platform breach. Key is in plaintext or weakly encrypted in the platform's backend.
- Key is used. Bill arrives. You find out via an email from OpenAI at 3am.
There is a second failure embedded in step 4. Most teams assume their cloud platform encrypts secrets at rest. Northflank's guidance that customers should "assume all environment variables have been decrypted" implies either the encryption failed or the attacker accessed the keys before encryption was applied, or both. The root cause has not been disclosed. Waiting for the post-mortem before rotating is the wrong call.
The same pattern (stolen environment variables, AI keys extracted, immediate use for inference) appeared across at least eight other platforms this month. This is not a Northflank-specific problem. It is a pattern that targets wherever AI teams store keys in platform-managed env vars.
What to do this week :
This is the rotation checklist. If you run AI workloads on any cloud hosting platform, run through it now. The commands below use OpenAI as the example provider; the same steps apply to Anthropic, Google, Mistral, and any other inference provider you use.
1. Rotate the key at the issuer, not just in the platform -
Rotating inside Northflank (or any platform) creates a new platform record. The old key remains valid at the provider until you revoke it there. Go to the provider dashboard first.
OpenAI: platform.openai.com/api-keys
Anthropic: console.anthropic.com/settings/keys
Revoke the compromised key. Create a new one. Do not reuse the same key name to avoid confusion in your logs.
2. Check provider billing and usage logs for the quiet window -
The breach was detected October 30. If your key was accessed, usage may have started earlier. Do not just check today's logs.
# OpenAI usage API (replace YOUR_NEW_KEY and adjust start_date)
curl https://api.openai.com/v1/usage?date=2026-10-01 \
-H "Authorization: Bearer ***"
Look for any usage on dates you did not initiate requests. Unexplained model calls, especially to expensive models, are the signal.
3. Audit every platform where you store AI keys -
Run a quick inventory. Where does each AI key live?
# Search your codebase for key references (run from your repo root)
grep -r "OPENAI_API_KEY\|ANTHROPIC_API_KEY\|sk-" . \
--include="*.env" --include="*.yaml" --include="*.toml" \
--include="*.json" -l
List every platform that holds a copy: Northflank, Fly.io, Railway, Render, Heroku, GitHub Actions secrets, Vercel, AWS SSM, your CI/CD environment. Each platform where the key lives is a surface.
4. Move AI keys out of platform env vars and into a secrets manager -
Platform env vars are convenient. They are also a single-layer control. A secrets manager adds isolation, audit trails, and access scoping that platform env vars cannot provide.
Options by complexity:
- AWS Secrets Manager or Google Secret Manager: managed, auditable, IAM-scoped
- HashiCorp Vault: self-hosted, fine-grained, works across any infra
- Doppler or Infisical: developer-friendly wrappers, git-native workflows
# Store in AWS Secrets Manager
aws secretsmanager create-secret \
--name "prod/openai-api-key" \
--secret-string "sk-yourkey..."
# Retrieve at runtime (no env var needed at the platform level)
aws secretsmanager get-secret-value \
--secret-id "prod/openai-api-key" \
--query SecretString --output text
Your application fetches the key at startup from the secrets manager. The platform never holds it.
5. Scope your API keys to the minimum necessary permissions -
OpenAI keys created after November 2024 support permission scoping. Anthropic keys support usage tiers and spend limits. Use them.
If your application only reads completions, the key does not need access to fine-tuning, assistants management, or file uploads. Create scoped keys. A key that cannot initiate fine-tuning jobs is worth much less to an attacker.
6. Set a spending limit at the provider level -
This does not prevent abuse, but it caps the financial damage.
OpenAI: platform.openai.com/settings/organization/limits
Anthropic: console.anthropic.com/settings/billing
Set a monthly limit 20% above your expected spend. Anything beyond that triggers an alert before it triggers a large bill.
7. Enable audit logs everywhere you can -
Northflank enabled audit logs for all customers after this breach, including free-tier accounts. That is useful now. It should have been default. Turn on audit logging for your cloud platform account, your secrets manager, and your AI provider account. If something happens again, you want a log that tells you when the key was accessed and from where.
The pattern will repeat :
Northflank is the ninth. The attack surface is the same across every platform that stores AI credentials in environment variables. The attacker behavior is consistent: access the platform, extract the env vars, run inference before anyone notices.
AI ops teams need to treat inference credentials the same way payment ops teams treat Stripe keys: high-rotation, tightly scoped, never in a place where a platform compromise exposes them directly.
The checklist above takes two to four hours to run properly. The alternative is finding out your AI budget was spent by someone else.
If you want a team to audit your AI ops stack and close these gaps before they become incidents, ZycoSoft works with founders and ops leads on exactly this. Book a 30-minute call.
Frequently Asked Questions
On October 30, 2026, Northflank advised all customers to assume their stored environment variables had been decrypted. By 15:12 UTC, multiple customers had confirmed unauthorized use of their AI API keys. The attacker accessed stored credentials and used them for billable inference requests before the breach was publicly disclosed.
A stolen AI API key gives an attacker access to your billing account, not just your data. They can run inference at your expense with no default spending cap. If the key carries write permissions — as most OpenAI keys do by default — attackers can also modify assistants, initiate fine-tuning jobs, or exfiltrate prompt history.
Go to the provider dashboard directly: platform.openai.com/api-keys for OpenAI, console.anthropic.com/settings/keys for Anthropic. Revoke the existing key there first, then create a new one. Do not just update the key value in your cloud platform — the old key remains active at the provider until explicitly revoked.
Use a dedicated secrets manager: AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or Infisical. Your application fetches the key at runtime from the secrets manager. The cloud platform never holds the value, so a platform compromise does not expose the key.
Check your provider's usage API or billing dashboard for the full period before the breach — not just recent days. For OpenAI, query the usage API endpoint. Look for inference calls on dates you did not initiate requests, unexpected model choices, or usage spikes on expensive models. Enable audit logs at the provider level so future access is traceable.
Yes. Spending limits do not prevent abuse but cap the financial damage. Set a monthly limit roughly 20% above your expected spend at both the provider level and, if your platform supports it, per-project or per-key. Most providers alert before cutting off service, giving you a window to investigate before a large bill lands.