Cloud application hosting platform Northflank is telling customers to rotate every credential and secret stored on its platform, after a security breach that led to unauthorised use of customers' AI API keys. BleepingComputer reported on 31 October.
What happened — and what is still missing. Northflank's public warning advises rotation, but as of this writing the company has not published a technical post-mortem detailing how the breach occurred, what part of its infrastructure was accessed, or which customers were concretely affected. Customers asking for per-account exposure detail — whether their specific stored secrets were read, and by whom — have not, per the BleepingComputer report, received a full account. Until that detail is published, the conservative posture is to assume exposure.
Why AI keys deserve a higher place in the runbook. Traditional incident-response playbooks often deprioritise third-party API keys behind database passwords and SSH access. That ranking is out of date. AI API keys are metered and instantly monetisable — an attacker can burn through credits via automated inference with no resale step required — and they are frequently unmonitored. The detection gap compounds the problem: Northflank's own telemetry will not show outbound calls made with an AI key from inside its infrastructure, so abuse surfaces at the AI provider rather than at the platform that was breached. If your runbook still treats these keys as low-value, update it.
The checklist. For platform teams, the response is short, and order matters:
- Rotate everything stored on Northflank — API keys, tokens, deployment credentials, database strings, and in particular any AI provider keys (OpenAI, Anthropic, Google and similar services) that were pasted into the platform's secret store or environment variables. Treat every stored secret as compromised until proven otherwise.
- Map where each key was consumed — trace every rotated key back to the pipelines, staging environments, and vendor integrations that used it. Rotation closes the door, but it does not tell you what walked through it beforehand.
- Review provider-side logs and spend dashboards — this is the step most likely to be skipped and the one that matters most. The only place abnormal inference activity would surface is at the AI provider itself. Check for unfamiliar model calls, spend that exceeds expectations, or requests from regions you have no operations in.
- Tighten secrets hygiene — scope keys to least privilege where the provider allows it, set per-key spend limits or hard caps, and enable provider-side alerts on anomalous usage.
The supply-chain lesson. The broader issue is concentration: a hosting or CI platform that holds your secrets multiplies the blast radius across every downstream integration wired into it. The practical mitigation is boring but effective — spread secrets across providers rather than vaulting everything in one place, keep genuinely sensitive keys out of platform-managed secret stores entirely where possible, and make sure each provider can alert you independently.
For teams in Hong Kong and similar environments, it remains common to see a single "master" set of keys kept in one shared vault or a repo-level environment file; this incident is a reminder that one compromised store can cascade into every connected service.
A platform you trust to run your applications can also be the single point of failure for the keys that run everything else. Rotate first, audit second, and check the AI dashboards before the attacker's bill becomes yours.
雲端應用託管平台 Northflank 已通知客戶，要求輪換儲存於其平台上的所有憑證及機密資料。此前一宗安全漏洞導致客戶的 AI API keys 遭未經授權使用。BleepingComputer 於 10 月 31 日報道。
事故經過——以及尚未提供的資料。 Northflank 已公開發出警告，呼籲用戶輪換密鑰，但截至本文撰寫時，該公司仍未發布技術性事故檢討報告，詳述漏洞如何發生、其基礎設施哪一部分被入侵，以及哪些客戶確實受到影響。據 BleepingComputer 報道，要求取得各帳戶受影響細節的客戶——例如其特定的儲存機密是否被讀取、由誰讀取——均未獲完整交代。在該等細節公布之前，審慎的做法是假定資料已遭洩露。
為何 AI keys 應在應變手冊中佔更高優先級。 傳統事故應變手冊往往將第三方 API keys 的處理次序排在資料庫密碼及 SSH 存取權限之後。這個排序已經過時。AI API keys 以用量計費且可即時變現——攻擊者可透過自動化 inference 直接燒盡額度，無需轉售過程——而且往往處於無監察狀態。偵測上的盲點令問題更為惡化：Northflank 自身的遙測數據不會顯示從其基礎設施內部以 AI key 發出的對外呼叫，因此濫用行為會在 AI 供應商一端浮現，而非在遭入侵的平台本身。如果你的應變手冊仍視此類 keys 為低價值項目，應立即更新。
檢查清單。 對平台團隊而言，應對措施並不複雜，但次序至關重要：
- 輪換所有儲存於 Northflank 的資料——API keys、tokens、部署憑證、資料庫連接字串，尤其是任何貼上平台 secret store 或環境變數的 AI 供應商 keys（OpenAI、Anthropic、Google 及類似服務）。在證實並非如此之前，應視所有儲存的機密為已外洩。
- 梳理每把 key 的使用位置——追查每把已輪換的 key，找出使用過它的 pipelines、staging 環境及供應商整合。輪換是把門關上，但不會告訴你此前有誰曾穿門而過。
- 檢查供應商端的日誌及開支儀表板——這一步最易被略過，卻也是最重要的一環。異常 inference 活動唯一會浮現的地方，正是 AI 供應商本身。檢查有否不熟悉的模型呼叫、超出預期的開支，或來自你沒有業務運作的地區的請求。
- 加強機密資料管理——在供應商允許的情況下，將 keys 的權限範圍縮至最低必要權限（least privilege），為每把 key 設定開支上限或硬性封頂，並啟用供應商端的異常用量警示。
供應鏈的教訓。 更廣泛的問題在於集中度：一個代你保管機密的託管或 CI 平台，會把波及範圍擴散至所有接駁其上的下游整合。實際的防範方法雖不花巧卻行之有效——將機密分散於多個供應商，而非全部存放於單一 vault；在可行情況下，盡量令真正敏感的 keys 完全不存入平台管理的 secret store；並確保每個供應商均能獨立向你發出警示。
對香港及類似環境的團隊而言，將一套「總控」keys 存放於單一共享 vault 或 repo 層級的環境檔案，仍是常見做法；今次事故提醒我們，一個被攻破的儲存位置，足以連鎖波及每一個已接駁的服務。
你信任用來運行應用程式的平台，同樣可能成為運行其他一切的 keys 的單點故障。先輪換，再審計，並趕在攻擊者的帳單變成你的帳單之前，檢查 AI 儀表板。