# Northflank: злом платформи призвів до зловживання чужими AI API ключами

> 30 жовтня Northflank підтвердив злом і попросив вважати всі environment variables скомпрометованими. Розбираємось, що сталося і як захистити AI API ключі на PaaS.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-11-02
- Категорія: Backend і System Design
- Canonical: https://cookiesoftware.io/blog/northflank-ai-api-keys-breach

---
Якщо твій застосунок деплоїться на Northflank і там зберігаються ключі до AI-провайдерів – OpenAI, Anthropic, AWS Bedrock чи будь-якого іншого – ротуй їх просто зараз. 30 жовтня 2026 року компанія підтвердила security-інцидент і прямо попросила клієнтів вважати всі environment variables скомпрометованими: "Assume all environment variables have been decrypted. Disable/rotate all keys". Невдовзі після цього Northflank підтвердив, що клієнти вже повідомляють про неавторизоване використання своїх AI API ключів.

## Чому це стосується саме тебе, а не лише DevOps-команди

Якщо ти розробляєш pet-проєкт, MVP стартапу чи просто тестуєш AI-фічу на PaaS типу Northflank, Railway чи подібних – ти, швидше за все, поклав API ключ до OpenAI або Anthropic в environment variable і забув про нього. Це нормальна практика. Проблема в тому, що такі ключі коштують дорожче за звичайні креденшли: доступ до бази даних зловмисник ще має якось монетизувати, а ключ до дорогої LLM можна одразу використовувати для генерації контенту, перепродажу доступу чи просто спалювання чужого бюджету. Саме тому AI developer platforms стали пріоритетною ціллю для атак – про це прямо каже дослідження Wiz, на яке посилається і сам Northflank у своїх апдейтах.

Якщо ти вже думав про те, як секрети в принципі потрапляють у зону ризику – подивись [GitHub тепер блокує Anthropic API keys: секрети в AI-еру](/blog/github-anthropic-secret-scanning), там інший кут цієї ж проблеми: витік ключів через код, а не через платформу.

## Таймлайн, який показує різницю між швидкою і повільною реакцією

За опублікованим таймлайном Northflank, Wiz попередив компанію про загрозу о 11:43 UTC 30 жовтня. Інженери Northflank переглянули алерт за хвилину і одразу випустили патч мережевої політики, а потім ще два – о 12:50 і 13:05 UTC. Компанія також залучила команду incident response від Wiz. Це приклад того, як реально виглядає швидка реакція на production-інцидент: не "ми розберемось протягом тижня", а патчі з інтервалом в хвилини.

При цьому Northflank чесно не розкрив, як саме зловмисники отримали доступ до системи, скільки клієнтів постраждало і чи вкрадено щось окрім AI API ключів. BleepingComputer звертався до компанії за коментарем і відповіді не отримав. Це важливий нюанс: багато деталей просто невідомі, і будь-які твердження про "як саме вкрали ключі" на цьому етапі – спекуляція, а не факт.

Як частину реагування Northflank увімкнув ротацію креденшлів для PostgreSQL, MongoDB, MySQL і Redis та додав audit logs усім клієнтам, включно з тими, хто на безкоштовному тарифі. Це корисно для розслідування, але не скасовує головної поради: ротувати секрети самостійно, не чекаючи, поки платформа щось зробить за тебе.

## Чорний жовтень для AI-платформ – це не поодинокий випадок

Northflank – не перша і не остання жертва жовтня. У звіті "Black October for AI Developer Platforms" Wiz нарахував щонайменше дев'ять подібних інцидентів серед AI developer platforms, включно з Railway, OpenCode, Warp і Lightning AI. У Railway також йшлося про потенційне розкриття розшифрованих environment variables, OpenCode повідомив про витік AI API ключів, а Warp – про злом, що розкрив логи AI-агентів і дані телеметрії користувачів.

Техніку, коли вкрадені креденшли використовують для доступу до AI-моделей за чужий рахунок, Wiz називає LLMJacking. У двох досліджених кейсах скомпрометовані enterprise-креденшли використали для близько 2,5 мільйона викликів Amazon Bedrock API, що згенерувало приблизно $100 000 витрат. Дослідники також знайшли інфраструктуру, пов'язану з перепродажем доступу до AI-моделей, хоча не змогли напряму пов'язати її з конкретними зламами.

## Практичний шар: як обмежити шкоду від вкраденого ключа ще до ротації

Ротація секретів – це реакція постфактум. Корисніше мати захист, який спрацює ще до того, як ти дізнаєшся про злом. Найпростіший варіант – обмежити кількість викликів з одним ключем за одиницю часу на рівні твого власного коду, а не покладатись лише на ліміти провайдера:

```typescript
type UsageWindow = {
  count: number;
  windowStart: number;
};

const usage = new Map<string, UsageWindow>();

const MAX_CALLS_PER_MINUTE = 20; // консервативний ліміт для одного ключа
const WINDOW_MS = 60_000;

export async function guardedFetch(
  apiKey: string,
  url: string,
  init: RequestInit,
): Promise<Response> {
  const now = Date.now();
  const entry = usage.get(apiKey) ?? { count: 0, windowStart: now };

  if (now - entry.windowStart > WINDOW_MS) {
    entry.count = 0;
    entry.windowStart = now;
  }

  entry.count += 1;
  usage.set(apiKey, entry);

  if (entry.count > MAX_CALLS_PER_MINUTE) {
    throw new Error(
      `Call limit exceeded for key ending in ...${apiKey.slice(-4)}. Можливий витік ключа - зупини процес і перевір.`,
    );
  }

  return fetch(url, init);
}
```

Це не замінює моніторинг на рівні провайдера чи платформи, але дає тобі власний запобіжник, який не залежить від того, чи встигне Northflank, Railway або будь-хто інший помітити аномалію раніше за тебе. Про те, як системно будувати спостереження за витратами AI-агентів, є окремий розбір – [AI observability: чому агент витратив $8 і все одно викликав не той tool](/blog/ai-agent-observability).

Друга практична звичка – не тримати один і той самий AI API ключ для dev, staging і production. Якщо витече ключ з dev-середовища, компрометація production – це вже твоє архітектурне рішення, а не доля.

## Чесні обмеження такого підходу

Rate limiting на рівні коду – це додатковий шар складності, і він не безкоштовний: легітимний сплеск трафіку (наприклад, після релізу фічі) може впертися в твій же ліміт і зламати продукт замість того, щоб захистити його. Крім того, якщо зловмисник краде ключ і одразу робить невеликі, "тихі" запити – такий wrapper його не зловить, бо аномалії не буде видно в короткому вікні.

Ротація секретів теж не тривіальна: якщо ключ хардкодиться в кількох сервісах або кешується на рівні контейнера, ротація без даунтайму вимагає окремої стратегії – graceful reload конфігурації, а не просто заміну значення в панелі платформи. Це варто продумати заздалегідь, а не в момент інциденту.

## Коли все це варто впроваджувати вже зараз

Якщо твій застосунок зберігає AI API ключі на будь-якому PaaS (не лише Northflank) – це вже достатня причина: окремі ключі на кожне середовище, базовий rate limit у коді та моніторинг рахунків у провайдера хоча б раз на день. Якщо ти працюєш з commercial-grade AI-інтеграцією, де рахунок може вирости на тисячі доларів за ніч, – лічильник викликів і алерт по бюджету потрібні вже на етапі MVP, а не "колись потім".

AI API ключ – це не конфігураційне значення, яке можна спокійно тримати поруч із паролем до тестової бази. Це фактично доступ до готівки, і варто проєктувати систему секретів так, ніби про злом ти дізнаєшся не з попередження платформи, а з рахунку за використання, який прийде через тиждень.