O investigație de securitate publicată la 5 noiembrie 2026 atrage atenția asupra unui risc mai puțin vizibil în dezvoltarea software asistată de inteligență artificială: comenzile aprobate permanent de un asistent AI pot ajunge să conțină parole și chei de acces, iar fișierele care le păstrează pot fi publicate accidental pe GitHub. Compania Apiiro a identificat 1.122 de copii publice ale unui fișier de configurare Claude Code care conțineau cel puțin un secret.
Descoperirea nu reprezintă, în sine, dovada unei compromiteri a infrastructurii Anthropic și nici nu demonstrează că toate credențialele găsite sunt încă valide. Problema documentată este una de gestionare a secretelor și a versiunilor de cod: o aprobare aparent banală poate crea o copie suplimentară, în text clar, a unei informații sensibile.
Ce au descoperit cercetătorii Apiiro
În analiza publicată la 5 noiembrie, cercetătorii au examinat 104.185 de copii publice ale fișierului .claude/settings.local.json, distribuite în 103.617 repository-uri GitHub. Dintre acestea, 1.122 de fișiere, adică aproximativ 1,1%, au fost clasificate drept conținând credențiale. În copiile curente au fost identificate 1.379 de secrete distincte.
Atunci când au inclus istoricul Git, configurațiile comune și transcrierile agenților, cercetătorii au raportat un total de 2.539 de secrete distincte în 1.994 de repository-uri. Acest total extins nu trebuie confundat cu numărul fișierelor afectate din analiza inițială.
Printre datele identificate se numără 379 de parole pentru baze de date, 122 de chei Supabase de tip service-role, 43 de credențiale SSH, 42 de tokenuri pentru GitHub, GitLab sau npm și 23 de chei AWS. Materialele au fost asociate cu 63 de organizații, în principal companii din domeniul software. Cifrele reprezintă constatările Apiiro, nu un bilanț verificat al accesărilor neautorizate.
Cum poate opțiunea 'Yes, and don't ask again' să expună o parolă
Claude Code solicită permisiunea utilizatorului înainte de executarea multor comenzi în terminal. Dacă dezvoltatorul selectează opțiunea 'Yes, and don't ask again', asistentul poate salva o regulă care permite repetarea comenzilor potrivite fără o nouă confirmare. Documentația Anthropic confirmă că aprobările persistente pentru comenzi Bash sunt păstrate în .claude/settings.local.json.
Unele reguli folosesc tipare generale, însă altele pot păstra comanda exactă care a fost aprobată. Dacă în comandă apare direct o parolă, un token API sau un șir de conectare la o bază de date, valoarea respectivă poate fi copiată în fișierul de configurare. Informația sensibilă rămâne astfel disponibilă în text clar chiar și după ce operațiunea inițială s-a încheiat.
De exemplu, un dezvoltator care verifică accesul la o bază de date de test poate rula o comandă cu parola introdusă ca argument. Aprobarea permanentă a acelei comenzi poate păstra parola în lista de permisiuni. Dacă fișierul este ulterior inclus într-un commit și încărcat într-un repository public, secretul poate deveni accesibil oricui.
De ce protecția Git implicită nu este suficientă
Claude Code încearcă să prevină această situație. Potrivit documentației oficiale, atunci când generează fișierul într-un repository Git, adaugă o regulă de excludere în configurația globală Git a dezvoltatorului. Aceasta este utilă local, dar nu se transmite automat altor colaboratori, dispozitive sau copii ale proiectului.
Regula globală nu înlocuiește intrarea corespunzătoare din .gitignore-ul repository-ului și nu rezolvă situația în care fișierul era deja urmărit de Git. Apiiro a observat că, în 539 dintre cele 1.105 repository-uri afectate analizate în acest sens, un commit care modifica fișierul îl menționa pe Claude drept coautor. Acest fapt indică participarea agentului la commit, nu intenția de a divulga date.
Ce se întâmplă dacă fișierul este șters de pe GitHub?
Ștergerea fișierului din versiunea curentă nu elimină automat copiile din istoricul Git. Cercetătorii au identificat 734 de secrete prezente numai în versiuni istorice ale fișierului și 211 fork-uri ale unor repository-uri care păstrau aceleași credențiale. Clonele, arhivele și artefactele de build pot menține expunerea chiar dacă fișierul principal nu mai este vizibil.
Din acest motiv, ordinea corectă a intervenției este importantă: mai întâi se revocă sau se schimbă credențialele expuse, apoi se tratează istoricul repository-ului și copiile existente. Curățarea Git nu poate invalida o cheie API deja publicată.
De ce unele instrumente de scanare ratează aceste secrete
În cadrul cercetării, Gitleaks a semnalat 564 dintre cele 1.122 de fișiere considerate afectate, iar TruffleHog a semnalat 643. Un număr de 215 fișiere nu a fost detectat de niciunul dintre cele două instrumente. Explicația este că parolele introduse într-o comandă nu au întotdeauna formatul recognoscibil al unei chei generate de un furnizor cloud.
Acest lucru arată limitele unei verificări bazate exclusiv pe semnături. O organizație care utilizează agenți AI trebuie să includă în controalele sale și fișierele de permisiuni, transcrierile comenzilor, notele de predare a lucrului și configurațiile locale, nu doar tradiționalele fișiere .env.
Cum verifici dacă propriul repository este afectat
1. Verifică fișierele urmărite de Git. În proiect, comanda git ls-files -- .claude/settings.local.json .claude/settings.json arată dacă aceste căi sunt prezente în index. Examinează local regulile salvate fără să trimiți parolele în conversații, tichete sau capturi de ecran.
2. Verifică și istoricul. Comanda git log --all -- .claude/settings.local.json te ajută să identifici commit-urile care au modificat fișierul. Include în audit branch-urile, versiunile mai vechi, fork-urile și arhivele publicate. Faptul că fișierul nu se mai află pe ramura principală nu dovedește că nu a fost expus.
3. Rotește imediat credențialele identificate: parole pentru baze de date, tokenuri de acces, chei cloud, credențiale SSH și alte secrete relevante. Verifică jurnalele de acces, limitele permisiunilor și eventualele sesiuni care trebuie invalidate. Nu aștepta finalizarea curățării istoricului pentru a revoca un token.
4. Dacă fișierul este deja urmărit, îl poți scoate din index cu git rm --cached .claude/settings.local.json și poți adăuga .claude/settings.local.json în fișierul .gitignore al proiectului. Acest pas previne viitoare commit-uri accidentale, însă nu șterge versiunile anterioare și nici fork-urile.
5. Evită introducerea secretelor direct în comenzile aprobate permanent. Utilizează variabile de mediu sau un manager de secrete, cu referințe de tipul $DB_URL, fără valori sensibile în text clar. Acordă permisiuni minime, preferă credențiale cu durată limitată și verifică periodic regulile persistente ale agentului.
Recomandări pentru echipele de securitate și organizații
Controalele de securitate trebuie extinse către directoarele și fișierele utilizate de agenți: .claude/, .cursor/, .gemini/ și jurnalele conversațiilor tehnice. Scanarea înainte de commit și în fluxurile CI trebuie să acopere atât versiunea curentă a codului, cât și istoricul Git, cu reguli suplimentare pentru parole care apar în argumente de terminal.
Merită definite reguli clare privind comenzile care pot fi aprobate permanent, folosirea credențialelor de producție, separarea mediilor de test și gestionarea incidentelor. Dacă un secret a ajuns public, prioritatea revine conturilor care oferă acces la servere sau baze de date accesibile din internet.
Întrebări frecvente
A fost compromisă platforma Claude Code?
Informațiile publicate descriu salvarea locală a unor comenzi sensibile și publicarea lor ulterioară în repository-uri. Nu constituie dovada unei breșe în infrastructura centrală Anthropic.
Sunt toate cele 2.539 de secrete încă funcționale?
Nu se poate afirma acest lucru. Apiiro nu a testat sistematic autentificarea cu toate credențialele. Cercetătorii spun că una dintre organizațiile notificate a confirmat că o cheie fusese activă. Expunerea unei credențiale și exploatarea efectivă sunt situații diferite.
Dacă repository-ul este privat, riscul dispare?
Nu complet. Vizibilitatea privată reduce expunerea publică, însă fișierul poate ajunge în arhive, imagini de container, copii sincronizate sau pe stații de lucru compromise. Secretul trebuie protejat indiferent de vizibilitatea codului.
Este suficient să adaug fișierul în .gitignore?
Nu. O regulă .gitignore nu elimină fișierele deja urmărite și nu modifică istoricul. Dacă un secret a fost public, acesta trebuie revocat ori schimbat, iar copiile și versiunile anterioare trebuie evaluate separat.
Concluzie: securitatea agenților AI începe cu gestionarea secretelor
Incidentul documentat de Apiiro arată cum o funcție concepută pentru productivitate poate genera un risc atunci când aprobările persistente includ date sensibile. Nu este suficient ca sursa unei parole să fie protejată: trebuie controlate și locurile în care aceasta poate fi copiată de instrumentele de dezvoltare.
Pentru dezvoltatori și organizații, principiile rămân esențiale: privilegii minime, secrete în afara codului și a comenzilor salvate, verificarea istoricului Git și rotația rapidă a credențialelor expuse.
Surse și verificarea informațiilor
Cercetarea originală: Apiiro, 'Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub', 5 noiembrie 2026: https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again/
Documentația oficială Anthropic despre fișierele de configurare și permisiunile Claude Code: https://code.claude.com/docs/en/settings
Relatare suplimentară: The Hacker News, 7 noiembrie 2026: https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html