# GitHub тепер блокує Anthropic API keys: секрети в AI-еру

> GitHub додав Anthropic service і user API keys у secret scanning із push protection за замовчуванням. Чому в AI-проєктах секретів стає більше, ніж дисципліни, і практичний checklist, щоб ключ не поїхав у git.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: Backend і System Design
- Canonical: https://cookiesoftware.io/blog/github-anthropic-secret-scanning

---

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

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

За [офіційним changelog](https://github.blog/changelog/2026-10-13-secret-scanning-blocks-anthropic-keys-by-default-adds-salesforce/), у 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-коду](/blog/ai-kod-chek-list-perevirky) – секрети там окремий пункт не випадково.

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

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

- **Локальний `.env` – лише для розробки.** І він у `.gitignore` з першого коміту, а не після інциденту.
- **Secret manager у деплої.** Vercel env vars, AWS Secrets Manager, Doppler – будь-що, аби ключ не жив у файлах репозиторію.
- **Short-lived credentials там, де можливо.** Токен, який живе годину, робить витік на порядок менш болючим, ніж вічний ключ. Та сама логіка, що й у [access/refresh-токенах](/blog/access-refresh-tokens-nodejs): короткий строк життя – це властивість дизайну, а не незручність.
- **Мінімальний 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-ключами – але підстраховка працює найкраще, коли вона не єдина сітка під канатом.