Clés API Anthropic : GitHub bloque désormais leur push, et Copilot peut exiger une politique à jour

Qu'est-ce que GitHub a changé le 13 octobre pour les clés API Anthropic ?

Depuis le 13 octobre 2026, GitHub bloque par défaut un push qui contient une clé API Anthropic de compte de service ou une clé utilisateur. Le blocage vaut dans les dépôts où le secret scanning (la détection automatique de secrets) est actif, dépôts publics gratuits compris.

Le changelog de GitHub nomme deux types : anthropic_service_api_key et anthropic_user_api_key. Ils rejoignent la push protection, qui refuse le commit avant qu'il n'atteigne le dépôt.

Le même changelog ajoute Salesforce comme partenaire du secret scanning et détecte les clés Cloudsmith. Mais il ne range que les deux types Anthropic dans la push protection par défaut.

Côté Anthropic, la documentation, qui parle aussi de clé API Claude, distingue la clé personnelle, qui agit en votre nom, et la clé de compte de service, faite pour la CI, la production et les agents. Les noms de GitHub semblent correspondre à ces deux types. Aucune des deux pages ne l'écrit en toutes lettres.

Tout ce qui suit vient des changelogs et des docs de GitHub et d'Anthropic, relus le 15 octobre 2026. Je n'ai pas testé de push avec une vraie clé.

Quels dépôts sont protégés, et qui peut passer outre

« Par défaut » ne veut pas dire « partout ». Tout dépend de la visibilité du dépôt et de votre offre GitHub :

• Dépôt public : le secret scanning tourne gratuitement. D'après le changelog, ces dépôts bloquent les nouvelles clés Anthropic.
• Dépôt privé ou interne d'une organisation : il faut GitHub Secret Protection, sur GitHub Team ou Enterprise Cloud.
• Votre compte : la push protection pour les utilisateurs est active par défaut. Elle vous empêche de pousser un secret vers un dépôt public.

La doc de la push protection précise un point souvent oublié. Pour les dépôts, elle est désactivée par défaut et exige Secret Protection. Un dépôt privé d'organisation sans cette option n'a donc aucun blocage côté dépôt.

Le blocage se contourne. Par défaut, toute personne qui a l'accès en écriture peut passer outre en choisissant une raison. « C'est utilisé dans les tests » ou « faux positif » créent une alerte fermée. « Je corrigerai plus tard » crée une alerte ouverte.

Pour serrer la vis, GitHub propose le contournement délégué (delegated bypass). Seuls les acteurs désignés peuvent alors passer outre ou valider les demandes des autres.

Reste le passé. Le secret scanning parcourt tout l'historique Git, sur toutes les branches. GitHub dit aussi relancer périodiquement l'analyse quand il ajoute des types. Une clé commitée il y a six mois peut donc lever une alerte cette semaine.

Une clé Anthropic a fuité : ce qui se passe, et quoi faire

Une clé API, c'est l'accès à votre compte et à votre facture. La page de bonnes pratiques d'Anthropic la compare à un numéro de carte bancaire.

Pour les dépôts publics, Anthropic décrit un circuit automatique. GitHub repère la clé et prévient Anthropic. Anthropic désactive la clé et envoie un e-mail au propriétaire.

Une nuance compte. Cette page date de mars 2026. Les clés personnelles et de compte de service sont arrivées le 27 août 2026, d'après les notes de version d'Anthropic. Côté GitHub, les sources divergent. Le changelog range les deux types parmi les détecteurs qui alertent l'utilisateur, pas parmi les partenaires qui préviennent l'éditeur de la clé. Le tableau de la doc GitHub, lui, les marque « Partner ». Je ne compte donc pas sur une désactivation automatique pour une clé de compte de service.

Si une clé a fuité, voici l'ordre que je suis :

1. Désactiver ou supprimer la clé dans la Claude Console. La désactivation est réversible. La suppression est définitive.
2. Créer une nouvelle clé et la déployer là où l'ancienne servait.
3. Lire les logs et l'usage de la Console, pour repérer des appels qui ne sont pas les vôtres.
4. Laisser l'historique Git tranquille, sauf obligation. La doc GitHub juge la réécriture longue et souvent inutile si la clé est déjà révoquée.

Anthropic propose aussi une expiration à la création : 3 heures, 1 jour, 7 jours, 30 jours, une durée libre ou jamais. Elle se fixe à la création et ne se modifie plus. Une clé de démo à 7 jours limite les dégâts d'un oubli.

Où mettre la clé dans une application Spring Boot

La règle tient en une phrase : la clé ne va jamais dans un application.properties commité. Spring Boot lit ses sources de configuration dans un ordre précis. D'après sa documentation, les variables d'environnement passent après les fichiers application.properties et peuvent donc les écraser.

Avec Spring AI, la propriété s'appelle spring.ai.anthropic.api-key. La doc de Spring AI 2.0 indique que la clé est lue dans ANTHROPIC_API_KEY quand elle n'est pas fournie. Le fichier commité ne contient alors que des réglages sans risque :

# application.properties (commité) : aucune clé ici
spring.ai.anthropic.chat.model=claude-haiku-5-5
# La clé arrive par l'environnement :
#   ANTHROPIC_API_KEY=sk-ant-...   (lue par Spring AI)
#   ou SPRING_AI_ANTHROPIC_APIKEY   (variable Spring Boot)

Ce bloc est assemblé à partir des deux documentations. Je ne l'ai ni compilé ni exécuté.

En local, un fichier .env reste acceptable s'il figure dans le .gitignore : c'est la condition que pose Anthropic. Dans le cloud, Anthropic conseille plutôt un stockage chiffré des secrets. Prévoyez aussi une clé par environnement : développement, test, production.

Pour la CI et la production, je prends une clé de compte de service. Une clé personnelle cesse de fonctionner quand son propriétaire quitte l'organisation, et le service tombe avec elle.

Mieux encore : la fédération d'identité (Workload Identity Federation) remplace la clé longue durée par un jeton court. La Console d'Anthropic préremplit sa configuration pour GitHub Actions, AWS, Google Cloud, Microsoft Entra ID et Kubernetes, et accepte tout fournisseur OIDC standard. Sa doc précise qu'elle réduit l'impact d'une fuite sans garantir seule la sécurité de bout en bout.

Le même piège existe hors de Java. Pour Claude Code, je détaille ailleurs comment configurer Claude Code avec des variables d'environnement sans commiter la clé.

Copilot : imposer une politique à jour avec forceRemoteSettingsRefresh

Le second changelog du 13 octobre concerne les administrateurs d'entreprise GitHub. Il ajoute le réglage forceRemoteSettingsRefresh aux managed settings, les réglages imposés par l'entreprise aux clients Copilot.

Mis à true, il oblige le client à télécharger la politique au démarrage, sans se contenter du cache. Selon le changelog, un client qui ne peut pas confirmer la politique « fails closed » : il se bloque au lieu de tourner avec une politique périmée.

La doc précise l'effet par client :

• Copilot CLI et l'app GitHub Copilot : le cache d'une heure est ignoré. Si le téléchargement échoue, les opérations concernées sont restreintes.
• VS Code : les fonctions Copilot restent bloquées jusqu'au rafraîchissement réussi.

Conséquence pratique : sans réseau au démarrage, pas de Copilot. Pour un dev en train ou derrière un proxy capricieux, c'est un vrai changement.

Le mode de diffusion compte aussi. Par MDM (la gestion des postes) ou par fichier, l'exigence vaut dès le premier démarrage. Posée côté serveur, elle ne s'applique qu'après une première réception par le client.

Le même jour, GitHub a ajouté une version minimale liée à la clé sandbox, qui impose un bac à sable local aux commandes de Copilot. Quand l'entreprise la déclare, les clients trop anciens perdent l'accès à Copilot. Il faut VS Code 1.141.0, Copilot CLI 1.0.93 ou l'app 1.1.26.

Ce que je fais cette semaine en tant que CTO ou dev Java

Mon avis : le blocage par défaut est un bon filet, pas une politique de secrets. Il ne couvre ni les dépôts privés sans Secret Protection, ni les clés collées dans un log ou un outil hors de GitHub.

Quatre actions, dans cet ordre :

1. Vérifier la push protection sur chaque dépôt privé qui touche à un LLM. Sans Secret Protection, rien ne bloque côté dépôt.
2. Restreindre le contournement avec le contournement délégué, au moins sur les dépôts de production.
3. Sortir les clés des fichiers : variables d'environnement, gestionnaire de secrets, clé de compte de service pour la CI, expiration courte pour les démos.
4. Tester forceRemoteSettingsRefresh sur un petit groupe avant de l'étendre, car il bloque Copilot hors ligne.

Si vos dépôts privés ont déjà GitHub Code Security ou Advanced Security, regardez aussi AI Scan, sorti en GA le 15 octobre. Il analyse les pull requests dans les langages que CodeQL ne couvre pas, dont les JSP et les Dockerfiles.

Vous voulez savoir où traînent les clés d'API de vos applications Spring Boot, et comment les sortir du code sans casser la CI ? Je développe en Java / Spring Boot depuis 2015. Réserver un appel découverte de 30 minutes.