GitHub blocca due nuove chiavi Anthropic prima che entrino nel repository

Nel changelog del 13 ottobre 2026, GitHub ha annunciato due nuovi rilevatori per le chiavi API Anthropic di servizio e utente. Nei repository con secret scanning attivo, la protezione push li blocca per impostazione predefinita: se riconosce una di queste credenziali durante l’invio, il commit non entra nella cronologia remota.

Il cambiamento riguarda i pattern anthropic_service_api_key e anthropic_user_api_key. Un push respinto lascia la credenziale nei commit locali finché non viene rimossa; una chiave già pubblicata richiede invece di intervenire anche sulla credenziale stessa. Blocco preventivo, avviso nel repository e segnalazione ad Anthropic sono passaggi distinti, con tempi e destinatari diversi.

Quando il push viene fermato

La protezione agisce mentre i commit vengono inviati al repository remoto. Se il controllo trova uno dei nuovi pattern e la protezione è attiva, il tentativo viene respinto prima della pubblicazione. La stringa può però essere già stata registrata in un commit sul computer di chi ha eseguito il push: il rifiuto non modifica automaticamente la cronologia locale.

Per riprovare, bisogna togliere la credenziale dal commit che la contiene. Se compare in un commit precedente del ramo che si sta inviando, cancellarla soltanto dalla versione corrente del file non basta: quel commit precedente fa ancora parte del push. Occorre correggere i commit locali interessati prima di inviarli di nuovo. Il blocco di un repository, inoltre, non dice se la stessa chiave sia stata copiata altrove.

La copertura dipende dal riconoscimento del segreto e dalle impostazioni del repository. «Protezione push predefinita» descrive l’inclusione dei nuovi rilevatori dove lo secret scanning è attivo; non equivale a una garanzia che ogni stringa simile a una chiave venga fermata in qualunque repository.

Le credenziali Anthropic nella tabella di GitHub

La tabella dei pattern supportati elenca cinque tipi di segreto Anthropic. Per ciascuno indica segnalazione al partner, avviso all’utente e supporto alla protezione push. La verifica di validità è indicata soltanto per la chiave API generale e quella amministrativa; per le due chiavi appena aggiunte al blocco predefinito non è prevista.

• Chiave API di servizio — anthropic_service_api_key. Protezione push, avviso all’utente e segnalazione al partner: sì. Verifica di validità: no. Se è già esposta, va sostituita nelle applicazioni o nei processi che la usano e poi disattivata.
• Chiave API utente — anthropic_user_api_key. Protezione push, avviso all’utente e segnalazione al partner: sì. Verifica di validità: no. La sostituzione coinvolge il titolare della chiave e le integrazioni che dipendono da essa.
• Chiave API generale — anthropic_api_key. Protezione push, avviso all’utente, segnalazione al partner e verifica di validità: sì. Se pubblicata, occorre distribuire una sostituta e revocare o disattivare quella esposta.
• Chiave amministrativa — anthropic_admin_api_key. Le stesse quattro capacità risultano supportate. La risposta all’esposizione deve considerare anche gli accessi amministrativi consentiti dalla credenziale.
• Identificativo di sessione — anthropic_session_id. Protezione push, avviso all’utente e segnalazione al partner: sì; verifica di validità: no. Non è una chiave API da sostituire nelle applicazioni: va gestita la sessione a cui si riferisce.

La colonna sulla protezione push indica che un pattern è supportato; l’annuncio del cambiamento specifica quali rilevatori sono stati inseriti ora nel blocco predefinito. Anche una verifica di validità supportata non sostituisce la risposta a un’esposizione: per i pattern di servizio, utente e sessione, l’avviso da solo non stabilisce se il segreto sia ancora utilizzabile.

Che cosa significano avviso e segnalazione al partner

Il messaggio mostrato a chi tenta un push bloccato riguarda quel tentativo di pubblicazione. Un avviso di secret scanning riguarda invece un segreto rilevato nel repository e permette a chi lo gestisce di esaminare l’esposizione. Per questo un push respinto e una credenziale già raggiungibile nella cronologia richiedono risposte diverse, anche se la stringa rilevata ha lo stesso formato.

La segnalazione al partner segue ancora un altro percorso. Quando un pattern Anthropic classificato come segreto del partner viene trovato in un repository pubblico, GitHub può inoltrarlo all’emittente perché possa revocarlo o ruotarlo. Questo passaggio non certifica che la credenziale sia stata disattivata. Chi la utilizza deve verificare direttamente la sostituzione e l’interruzione dell’accesso con la vecchia chiave.

Gli avvisi all’utente possono riguardare repository pubblici o privati coperti dallo scanning; la trasmissione automatica al partner descritta per i segreti pubblici ha un ambito diverso. Nella pratica conta dove il segreto è arrivato: un tentativo fermato prima della pubblicazione non ha lo stesso stato di una chiave individuata in commit già disponibili ad altri.

Se la chiave è già nella cronologia Git

Per una credenziale pubblicata, eliminare il file nella versione corrente non elimina i commit precedenti. La ricostruzione di iMasters distingue il nuovo blocco dei push dai segreti già presenti nella cronologia: questi ultimi richiedono un intervento sulla chiave esposta. Una copia del repository scaricata prima della cancellazione può conservare il valore originale.

La risposta parte dalla credenziale: identificare quale chiave è coinvolta, creare una sostituta dove necessario, aggiornare i sistemi che usano quella precedente e disattivare o revocare la vecchia. Per una chiave di servizio o utente bisogna considerare le integrazioni che la leggono; per una chiave amministrativa anche gli accessi che autorizza. L’identificativo di sessione richiede invece una decisione sulla sessione interessata.

Solo dopo aver impedito l’uso del segreto esposto ha senso valutare la pulizia della cronologia. Riscriverla richiede coordinamento con chi ha clonato il repository, perché i vecchi commit possono sopravvivere nelle copie locali ed essere inviati di nuovo. La revoca o la disattivazione della credenziale resta quindi il passaggio che interrompe l’accesso ottenibile con quel valore, mentre la modifica della cronologia riduce la presenza del segreto nelle copie che si riescono a controllare.

Leggi anche:

• Muse entra nel back office dei creator, ma non pubblica né spende da solo
• Kickstarter o Indiegogo: la stessa fee nasconde due pubblici diversi
• Claude Code o GitHub Copilot: i dati premiano compiti diversi, non un vincitore