З 13 жовтня GitHub розпізнає два типи ключів Anthropic – anthropic_service_api_key і anthropic_user_api_key – і блокує їх через push protection за замовчуванням у всіх репозиторіях із secret scanning, включно з безкоштовними публічними. Новина маленька, а привід великий: у типовому AI-проєкті секретів уже більше, ніж у середньому бекенді п'ять років тому, і push protection – це останній рубіж, а не стратегія. Нижче – що саме змінилось і checklist, який варто пройти сьогодні.

Що саме додав GitHub

За офіційним changelog, у detection потрапили обидва типи Anthropic-ключів – сервісні й користувацькі – і обидва входять у push protection за замовчуванням. Тобто спроба запушити ключ у репозиторій із secret scanning тепер зупиняється до того, як секрет опиниться в історії.

Паралельно до партнерської програми приєднався Salesforce: їхні Marketing Cloud OAuth-токени, знайдені в публічних репозиторіях, GitHub пересилає вендору на відкликання чи ротацію.

Ми навчили AI писати production-код. Але людство все ще комітить API keys у Git – і добре, що платформа почала страхувати саме AI-ключі, бо їх стає дедалі більше.

AI-stack = більше секретів

Порахуй чесно, скільки credentials у твоєму «простому AI-застосунку»:

  • ключ model provider (а часто двох-трьох);
  • vector database;
  • tracing/observability сервіс;
  • MCP-сервери зі своїми токенами;
  • sandbox provider;
  • cloud-акаунт під усім цим.

Шість типів секретів ще до того, як ти написав першу бізнес-функцію. Кількість credentials у проєктах росте швидше, ніж developer-дисципліна, і саме тому «випадковий commit із ключем» – це не історія про джунів. Це статистика, яка наздоганяє будь-яку команду без процесу.

Окремий нюанс AI-ери: секрети тепер течуть не лише через git. Ключ може опинитись у промпті, який ти вставив у чат, у логах агента, у збереженому контексті сесії. Про гігієну промптів я вже писав у чеклісті перевірки AI-коду – секрети там окремий пункт не випадково.

Push protection корисна, але не достатня

Найкращий секрет – той, якого розробник взагалі не бачить. Push protection ловить помилку в останній момент, і це чудово, але production-підхід виглядає ширше:

  • Локальний .env – лише для розробки. І він у .gitignore з першого коміту, а не після інциденту.
  • Secret manager у деплої. Vercel env vars, AWS Secrets Manager, Doppler – будь-що, аби ключ не жив у файлах репозиторію.
  • Short-lived credentials там, де можливо. Токен, який живе годину, робить витік на порядок менш болючим, ніж вічний ключ. Та сама логіка, що й у access/refresh-токенах: короткий строк життя – це властивість дизайну, а не незручність.
  • Мінімальний scope. Ключ для читання не повинен уміти писати. Сервісний ключ CI не повинен бути адмінським.
  • Ротація за розкладом, а не «коли згадаємо».
  • Жодних секретів у логах. Включно з логами агентів – вони люблять чесно переказувати все, що бачили.

Якщо ключ уже в git history

Найпоширеніша помилка: видалити рядок наступним комітом і видихнути. Git нічого не забуває – ключ лишається в історії, у форках, у клонах, у кеші CI. Правильна послідовність одна:

  1. Негайно відкликати або ротувати ключ у консолі провайдера. Це єдиний крок, який реально закриває діру.
  2. Вичистити історію (git filter-repo чи BFG) – вже як гігієна, а не як захист.
  3. Перевірити логи провайдера на предмет використання ключа за час експозиції.

Я на цьому колись сам обпікся з вебхук-секретом у скрипті – тому казатиму прямо: видалення рядка без ротації – це прибирання місця злочину без арешту злочинця.

Перевір свої ключі, поки це дешево

П'ятнадцять хвилин сьогодні замість інциденту завтра:

  1. Прожени gh secret-scanning або просто переглянь: чи ввімкнений secret scanning + push protection у твоїх репозиторіях (для публічних – він уже є).
  2. git log -p | grep -iE "api[_-]?key|secret|token" по найстаршому проєкту. Знайдене – ротуй, не редагуй.
  3. Склади список усіх секретів AI-стека свого поточного проєкту. Якщо їх більше п'яти і немає secret manager – ти знаєш, що робити на цьому тижні.

Виправдання, які чув кожен security-інженер

  • «У нас приватний репозиторій, нам можна». Приватність репо – не шифрування: над-scoped PAT, витік акаунта чи зміна видимості перетворюють «можна» на інцидент.
  • Ключ у фронтенді «тимчасово». Тимчасове живе найдовше. Для браузерного коду ключів не існує – тільки серверні проксі.
  • Один ключ на всі середовища. Dev-ключ у проді й prod-ключ у dev – обидва варіанти погані, але другий гірший.
  • Довіра push protection як єдиному захисту. Вона не бачить секрети, що вже в історії, і не працює там, де її не ввімкнули.

AI security часто починається не з prompt injection, а з того, що хтось випадково закомітив ключ. Добре, що GitHub тепер підстраховує і з Anthropic-ключами – але підстраховка працює найкраще, коли вона не єдина сітка під канатом.