De ce asistentul tău AI pentru cod e o gaură de securitate (și cum o parchezi)

De ce asistentul tău AI pentru cod e o gaură de securitate (și cum o parchezi)

Mai 07, 2026 ai security credential management claude code developer security infrastructure hardening threat prevention coding agents

De ce asistentul tău AI pentru cod este o gaură de securitate (și cum o închizi)

Săptămâna trecută mi-am dat seama că lăsasem un asistent AI să ruleze comenzi libere pe mașina mea de luni întregi. Avea acces la cheile AWS, SSH, repo-uri private de pe GitHub și orice altceva din directorul home. Cel mai nasol? N-am băgat de seamă deloc, fiindcă era super util și nu se întâmplase nimic rău.

Așa gândim fix când ștergem din greșeală o bază de date de producție.

Ușurința te orbește la riscuri

Realitatea dură: majoritatea agenților AI pentru cod primesc acces ca un inginer senior de infrastructură de prima zi. Nu i-ai da niciodată unui contractor nou acces SSH nelimitat la toate serverele, dar la un LLM îi dai fără să clipești.

Nu e vorba de răutate. E neglijență pură. Sunt atât de utili încât uiți ce pot face cu adevărat. O injecție de prompt dintr-un repo clonat, un obiectiv greșit sau o comandă inocentă pot trimite credentialele tale unui atacator. Și nici n-o să vezi nimic.

Vestea bună? Unele tool-uri, cum ar fi Claude Code, au controale solide de securitate. Trebuie doar să le activezi.

Riscurile din modul implicit

În mod implicit, mulți agenți AI rulează în "auto". Execuă comenzi fără să te întrebe, decât dacă lovesc ceva blocat clar. Pare eficient, nu? Iată ce înseamnă asta concret:

Dacă lista de blocări e goală și modulul e auto, AI-ul poate:

  • Face curl oriunde
  • Descărca fișiere cu wget
  • Se conecteze prin ssh la servere
  • Deschide conexiuni cu nc
  • Citească toate fișierele .env
  • Acceseze ~/.aws/credentials, ~/.ssh, ~/.gnupg
  • Pune cod direct în repo-uri

Totul se întâmplă în tăcere. Fără avertismente. Fără confirmări.

Un model de securitate în trei straturi

Ai nevoie de control fin. Nu totul merită aprobare, dar unele acțiuni da. Uite cum structurezi:

Stratul 1: Blocarea totală

Începe cu o listă de interdicții pentru credentiale:

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

E ca un firewall. Nimic nu trece, indiferent ce vrea AI-ul.

Stratul 2: Verificarea manuală

Adaugă o listă "ask" pentru acțiuni periculoase, dar reversibile:

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

AI-ul poate face push-uri sau deploy-uri legitime, dar te întreabă întâi. Eficiență cu siguranță.

Stratul 3: Căi libere

Permite explicit operațiunile sigure:

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Acestea rulează fără oprire, fiindcă nu schimbă nimic periculos.

Cum alegi modul implicit

După liste, alege modul pentru restul. Opțiuni:

  1. auto - Tot ce nu e blocat rulează singur. Rapid, dar lista de deny trebuie perfectă.

  2. acceptEdits - Citește liber, sugerează editări, dar cere OK pentru comenzi bash în afara allow. Echilibrat.

  3. ask - Întreabă la orice risc. Lent, dar ultra-sigur.

Pentru echipe, acceptEdits e ideal. Menții viteza, dar decizi conștient.

Exemplu de configurare reală

Iată una gata de producție:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

AI-ul te ajută cu teste, linting și cod, dar nu fură date, nu face push fără tine și nu se conectează aiurea.

Două abordări practice

Eu folosesc două alias-uri în shell:

# Implicit: securitate echilibrată
alias cc="claude --permission-mode auto"

# Mod debug: încredere totală (rar)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc merge 95% din timp. ccd e pentru urgențe, cu risc asumat conștient.

Problema din industrie

Nu e doar la Claude Code. Orice AI cu shell commands – GitHub Copilot, Devin, Cursor, ChatGPT – are aceleași riscuri.

Claude Code excelează prin controale fine. Altele te lasă să alegi: tot sau nimic.

Impactul asupra infrastructurii tale

În echipe, devine critic. Nu poți conta pe dezvoltatori să configureze singuri.

Fă așa:

  • Obligă liste deny în config-urile shared
  • Blochează fișierele cu credentiale la nivel de FS
  • Folosește token-uri temporare, nu chei permanente
  • Controlează rețeaua anti-exfiltrare
  • Educă echipa pe riscuri vs. productivitate

Concluzia clară

Asistenții AI pentru cod sunt revoluționari. Merită folosiți. Dar nu gratuit.

Activează controalele acum. 15 minute: deny pentru credentiale, ask pentru deploy, modul echilibrat. Apoi lucrezi liniștit.

„N-a pățit nimic încă” nu e strategie de securitate.

Read in other languages:

RU BG EL CS UZ TR SV FI PT PL NB NL HU IT FR ES DE DA ZH-HANS EN