What Happened
Northflank, a cloud application hosting platform, experienced a security breach that led to unauthorized use of its customers' AI API keys. The company is advising customers to rotate all credentials and secrets stored on the platform.
This incident highlights a platform compromise, abuse of customer-held AI keys, and a blanket rotation advisory. While the specifics of the attack vector or dwell time remain unknown, we can examine the control gaps this incident reveals in most hosting-platform deployments and what standards say about them.
Timeline
Here's what we know for sure:
- A breach occurred on the Northflank platform. The initial access method and date are not established here.
- Customers' AI API keys were used without authorization. Keys stored on the platform were abused, meaning the secrets were accessible to whoever gained access.
- Northflank advised customers to rotate all credentials and secrets stored on the platform. The broad scope of this advice suggests the provider couldn't determine which secrets were exposed.
When a provider advises "rotate everything," it's often because they can't confirm which secrets remained secure. This advisory indicates uncertainty about the extent of the breach.
Which Controls Failed or Were Missing
Consider these as control categories highlighted by the incident, not specific findings about Northflank's internal state.
Secrets were exposed to the platform layer. The misuse of AI keys implies they were accessible from the hosting environment. Any secret a platform can decrypt at runtime is vulnerable if the platform is compromised. If your keys are stored as long-lived static values, your security relies on the provider's perimeter.
Long-lived static credentials. AI provider keys are typically bearer tokens without built-in expiry. A stolen key remains valid until revoked. Without scheduled rotation, the attacker's window of opportunity is unlimited.
Weak scoping of what the keys could do. Misuse of an AI key means someone could spend your money and consume your quota. Keys without spend caps, model restrictions, or allowed-origin constraints give an attacker full access.
Slow detection on the customer side. Customers often learn of key abuse through a provider notice or a billing spike. If your first signal is an invoice, your usage monitoring is inadequate.
No rehearsed rotation path. "Rotate all credentials" is easy to say but difficult to execute when secrets are hardcoded across services, pipelines, and teammates' laptops. Teams without an inventory of where each secret resides will rotate slowly and incompletely.
What the Relevant Standards Require
Several frameworks address these gaps.
PCI DSS v4.0.1. Requirement 8.3.9 mandates changing passwords or passphrases used as the only authentication factor every 90 days, or dynamically assessing account access based on security posture. Requirement 8.6.3 requires protecting passwords and passphrases against misuse, changing them periodically based on risk analysis, and changing them upon suspected or confirmed compromise. API keys fall under this category. Requirement 8.6.2 prohibits hard-coded passwords in scripts, configuration files, and source code. Requirements 3.6 and 3.7 cover cryptographic key protection and lifecycle management, including key replacement when integrity is weakened or compromise is suspected.
ISO/IEC 27001:2022. Annex A control 5.17 requires controlled allocation and management of authentication information, and Annex A 8.24 covers cryptography rules, including key management. Annex A 5.19 through 5.22 address supplier relationships, relevant to hosting provider access to your secrets.
SOC 2 Type II. The Common Criteria under logical access (CC6.1 and CC6.2) expect restricted access to credentials and timely removal or modification of access. CC7.3 and CC7.4 cover evaluating and responding to security incidents, relevant to a provider breach advisory.
NIST Cybersecurity Framework (CSF) v2.0. The Protect function's identity management and access control category (PR.AA) covers credential issuance and lifecycle management. The Govern function's supply chain risk management category (GV.SC) addresses the dependency on third parties holding your secrets. The Respond function covers incident management and mitigation once an advisory arrives.
NIST 800-53 Rev 5. IA-5 (authenticator management) and SC-12 (cryptographic key establishment and management) are direct references. SA-9 covers external system services.
Lessons and Action Items for Your Team
Inventory every secret and its consumers. List each credential, what it unlocks, where it's stored, and who or what uses it. You can't rotate on demand what you can't enumerate. This is essential for everything else.
Move to short-lived credentials where the provider supports them. Prefer tokens that expire on their own, issued at runtime from a central secrets manager, over static keys pasted into platform settings. Where an AI provider only offers static keys, implement rotation around them.
Automate rotation on a schedule and on trigger. Scheduled rotation meets the periodic-change intent of PCI DSS Requirement 8.6.3 when supported by risk analysis. Trigger-based rotation, meaning a one-command or pipeline-driven rotate-everything action, is necessary when a provider sends an advisory. Test it before you need it. Measure how long a full rotation takes in your environment and treat that number as a risk metric.
Constrain what each key can do. Create separate keys per service and environment. Apply spend limits, model allowlists, and network or origin restrictions wherever the AI provider offers them. A stolen key with a hard monthly cap is an annoyance; one without is an open tab.
Monitor usage, not just invoices. Alert on request-volume anomalies, unfamiliar source IPs, and unexpected model usage. Pull usage data from the AI provider's API into your own alerting rather than waiting for billing.
Treat your hosting provider as part of your secrets threat model. Record in your risk register that a platform compromise can expose any secret stored there. Decide, per secret, whether platform-held storage is acceptable or whether it should be fetched at runtime from a store you control.
Write the provider-breach runbook now. It should cover who gets the advisory, who owns rotation of each secret class, how you confirm old keys are revoked (not merely replaced), and how you review provider logs for abuse during the exposure window. Map it to your SOC 2 Type II incident response evidence and your ISO/IEC 27001:2022 supplier controls so the same document serves the auditor.
The Northflank advisory to rotate everything is the right call for a provider that can't scope the exposure. It's also a preview of your own worst day. The teams that handle it well are the ones that already know where their secrets are and have practiced replacing them.
