Ghid de securitate Claude Code: permisiuni, MCP, sandboxing

Chatboții tradiționali rulează din spatele unui API, așa că răul cel mai mare pe care îl pot face e să halucineze. Dar un agent AI de programare stă în repo-ul tău, în terminalul tău și (adesea) lângă credențialele tale din cloud, ceea ce îl aduce mult mai aproape de medii de dezvoltare privilegiate decât orice numeam cândva chatbot.

Întrebarea este cum să folosești Claude Code în siguranță fără să te încetinești. Permisiunile, controalele MCP și sandboxing-ul, cu un reglaj corect, te duc acolo.

În acest articol, îți arăt cum funcționează de fapt modelul de securitate al Claude Code, unde trebuie să fii atent și practicile care îl mențin util fără să îi oferi mai mult acces decât ai intenționat.

Dacă ești complet nou în Claude și Claude Code, înscrie-te la cursul nostru gratuit Claude Code 101 ca să prinzi bazele într-o după-amiază.

Înțelegerea modelului de securitate al Claude Code

Înainte să reglezi vreo regulă, ai nevoie de un model mental al a ceea ce controlează efectiv Claude Code.

Sunt cinci piese în mișcare: un sistem de permisiuni care decide ce e permis, controale de acces la instrumente care delimitează capabilități individuale, permisiuni MCP pentru integrări externe, sandboxing pentru izolare la nivel de sistem de operare și auditabilitate pentru revizuire ulterioară. Fiecare rezolvă o problemă diferită, dar se cumulează.

Sistemul de permisiuni

Sistemul de permisiuni este stratul static.

Declari ce poate face Claude în settings.json, folosind trei liste: allow, ask și deny. Regulile sunt evaluate în ordinea deny, apoi ask, apoi allow, iar prima potrivire câștigă. O regulă deny blochează apelul chiar dacă o regulă allow mai largă l-ar fi acoperit.

Dacă nicio regulă nu se potrivește, Claude revine la defaultMode al sesiunii (mai multe despre moduri în secțiunea următoare).

Controale de acces la instrumente

Permisiunile se atașează la instrumente, nu la agent ca întreg.

Claude Code are propriul set de instrumente integrate, de exemplu Bash pentru comenzi shell, Read, Edit și Write pentru operațiuni pe sistemul de fișiere, WebFetch pentru cereri HTTPS, WebSearch pentru căutări și altele câteva. Fiecare regulă numește un instrument și (opțional) un specificator între paranteze, precum Bash(git commit:*) sau Read(./.env).

Asta face posibil principiul „celui mai mic privilegiu”. Poți permite Bash(npm run:*) pentru teste fără să îi dai lui Claude acces complet la shell.

Permisiuni MCP

Serverele MCP extind Claude Code cu instrumente pentru care nu a fost proiectat inițial.

Fiecare server aduce propriul set de instrumente (un server GitHub adaugă instrumente pentru pull request, un server de baze de date adaugă instrumente de interogare etc.). Sistemul de permisiuni le acoperă și pe acestea, dar cu o sintaxă diferită - regulile folosesc forma mcp__servername__toolname în locul specificatorului în paranteze.

Ideea de reținut e că MCP cam dublează întrebarea, pentru că nu doar decizi ce poate face Claude cu shell-ul tău, ci și ce poate face cu fiecare sistem extern la care l-ai conectat.

Sandboxing

Sandboxing-ul este siguranța la nivel de OS sub instrumentul Bash.

Regulile de permisiuni îi spun lui Claude ce ar trebui să facă. Sandboxing-ul impune ce poate face, restricționând accesul la sistemul de fișiere și apelurile de rețea la nivel de sistem de operare. Pe macOS funcționează direct prin Seatbelt. Pe Linux și WSL2, trebuie să instalezi mai întâi bubblewrap și socat.

Cele două straturi funcționează similar, dar acoperă scenarii diferite. Permisiunile îl opresc pe Claude să încerce ceva, iar sandboxing-ul oprește reușita încercării dacă un prompt injection convinge totuși pe Claude să încerce.

Auditabilitate

Ultima piesă este să poți vedea ce s-a întâmplat.

Comanda /permissions listează fiecare regulă activă și fișierul de setări din care provine, ca să poți răspunde la „de ce a rulat Claude asta?”. Hook-urile (PreToolUse, PostToolUse și altele) îți permit să înregistrezi fiecare apel de instrument în propriul sistem. Pentru echipe, exportatorii OpenTelemetry trimit date despre utilizare și apeluri de instrumente în orice stack de observabilitate folosești deja.

Permisiuni și controlul accesului în Claude Code

Majoritatea siguranței vine din setările de permisiuni, așa că aici vei petrece cel mai mult timp reglând.

Acces la fișiere

Implicit, Claude poate citi și edita fișiere în directorul din care l-ai lansat.

Citirea e controlată de instrumentul Read, iar editarea de Edit și Write. Fiecare acceptă un tipar de cale între paranteze, folosind sintaxă în stil gitignore; de exemplu, Read(**/.env) se potrivește oricărui fișier .env la orice adâncime, iar Edit(src/**) acoperă tot ce e sub src/.

Un deny pe Read acoperă instrumentele de fișiere ale Claude Code (Read, Grep, Glob, LS), dar e doar un efort de bună practică. Un script Python sau Node rulat prin Bash poate totuși deschide fișierul, pentru că acea citire se întâmplă prin shell, nu prin instrumentul Read al lui Claude. Dacă un secret contează, combină deny pe Read cu deny pe Bash pentru cat, head și tail pe acele căi.

Pentru a extinde accesul dincolo de directorul de lucru, folosește additionalDirectories în settings.json. Așa îi dai lui Claude acces la o bibliotecă partajată în afara repo-ului sau la un fișier de configurare din directorul tău home, fără să renunți complet la granița directorului de lucru.

Executarea comenzilor

Instrumentul Bash e cel pe care trebuie să-l delimitezi cel mai atent.

O regulă Bash simplă permite orice comandă. O regulă „îngustată”, precum Bash(npm run:*), permite doar invocările care se potrivesc. Modelul cu două puncte și asterisc e cel corect aici, iar Claude Code înțelege operatorii shell, așa că o regulă ca Bash(safe-cmd:*) nu va potrivi safe-cmd && rm -rf /.

Unele comenzi rulează fără prompt în orice mod, pentru că sunt tratate implicit ca read-only. Lista acoperă ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd și formele read-only ale git. Nu poți micșora manual această listă, dar poți adăuga o regulă ask sau deny pentru oricare dintre ele ca să suprascrii implicitul.

Pentru orice nu e pre-aprobat, Claude cere confirmare în modul implicit. Promptul arată comanda exactă și îți permite să o aprobi o dată, să aprobi toate apelurile viitoare care se potrivesc unui model sau să refuzi.

Moduri de permisiune

Regulile de permisiuni sunt statice, dar modurile de permisiuni schimbă modul în care se comportă apelurile nepereche.

Sunt cinci:

• default: cere aprobare la prima utilizare a fiecărui instrument.

• acceptEdits: aprobă automat editările de fișiere din directorul de lucru și tot controlează comenzile shell. Util când ai încredere în editări, dar nu în shell.

• plan: Claude poate citi și analiza, dar nu poate edita fișiere sau rula comenzi. Modul potrivit pentru code review sau sesiuni de planificare.

• dontAsk: respinge automat orice nu e explicit în allow list.

• bypassPermissions: sare peste orice prompt. Sigur doar în medii complet izolate, ca un container sau VM.

Poți comuta între cele trei moduri principale cu Shift+Tab în timpul sesiunii sau poți alege unul ca implicit în settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Pentru echipe, setările gestionate îți oferă un strat pe care utilizatorul nu îl poate suprascrie. Fișierul urmează același format JSON și se găsește într-o cale de sistem:

• /Library/Application Support/ClaudeCode/managed-settings.json pe macOS

• /etc/claude-code/managed-settings.json pe Linux

• C:\ProgramData\ClaudeCode\managed-settings.json pe Windows

Regulile deny din setările gestionate se aplică în toate proiectele de pe mașină, ceea ce îți permite să impui reguli precum „nimeni nu citește fișierele .env” sau „nimeni nu rulează bypassPermissions” în toată organizația.

Principiul din spatele tuturor acestora este cel al celui mai mic privilegiu, același pe care l-ai aplica oricărui cont de serviciu. 

Ar trebui să începi cu setul minim de permisiuni care permite munca și să le lărgești doar când te lovești de un zid. Ghidarea Anthropic merge în aceeași direcție - revizuiește schimbările pe care le face Claude, auditează-ți regulile cu /permissions și ține setările specifice proiectului în controlul versiunilor, ca echipa să fie aliniată asupra a ceea ce poate lucra Claude.

Sandboxing în Claude Code

Cu cât îi permiți mai mult lui Claude să ruleze autonom, cu atât are mai mult sens sandboxing-ul.

Instrumentul Bash are cea mai mare expunere, deoarece comenzile shell pot citi orice fișier pe care îl poți citi și pot modifica orice pentru care au permisiuni de scriere. Sandboxing-ul impune granițe la nivel de OS pentru fiecare comandă Bash și procesele sale copil, astfel încât Claude poate rula mai liber în interiorul graniței fără să îi aprobi fiecare apel. Anthropic a construit asta special pentru a susține rulări autonome mai sigure.

Un detaliu important: sandbox-ul acoperă doar Bash și procesele copil. Nu restricționează instrumentele Read, Edit sau Write, iar acelea trec în continuare prin sistemul de permisiuni.

Sandboxing nativ

Sandbox-ul nativ este integrat în Claude Code și se activează cu /sandbox.

Pe macOS, sandboxing-ul folosește cadrul Seatbelt încorporat și nu ai nimic de instalat. Pe Linux și WSL2, instalezi bubblewrap pentru izolarea sistemului de fișiere și socat pentru proxy-ul de rețea. Windows nativ nu este suportat, deci rulezi Claude Code într-o distribuție WSL2.

Granița sistemului de fișiere e ușor de înțeles. Citirile funcționează peste tot, cu excepția căilor refuzate, iar scrierile funcționează doar în directorul de lucru și în căile suplimentare pe care le permiți. Dacă încerci să scrii în ~/.bashrc din interiorul sandbox-ului, vei primi „Operation not permitted” înainte ca Claude să știe măcar că a eșuat.

Granița de rețea e oarecum diferită. Traficul de ieșire trece printr-un server proxy care rulează în afara sandbox-ului, care verifică fiecare cerere față de lista ta allowedDomains. Domeniile noi declanșează în schimb un prompt de permisiune, astfel încât vezi exact către ce vrea să ajungă Claude.

O configurație funcțională arată așa:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

În uzul intern al Anthropic, sandboxing-ul reduce prompturile de permisiune cu 84%.

Containere de dezvoltare

Containerele Dev sunt următorul pas în izolare.

Anthropic are un devcontainer de referință pentru Claude Code care configurează un mediu Ubuntu, montează repo-ul tău și oferă agentului un shell de lucru. Avantajul față de sandboxing-ul nativ este reproductibilitatea, pentru că toți din echipă primesc același mediu, cu aceleași instrumente și aceeași configurare.

Dar dezavantajul este costul de operare. 

Adaugi build-ul containerului, montarea fișierelor și (uneori) un ciclu de feedback mai lent când folosești containere. Pentru un singur dezvoltator, sandbox-ul nativ e de obicei suficient. Pentru echipe sau CI, această configurare merită.

Izolare bazată pe Docker

Pentru sesiuni autonome de lungă durată, Docker poate mări și mai mult granița sandbox-ului.

De obicei, configurarea arată așa:

• Imagine de bază minimă: elimină managerii de pachete și uneltele de rețea de care sarcina nu are nevoie.
• Utilizator non-root: Claude nu rulează niciodată ca root, deci nu poate modifica fișiere de sistem sau instala pachete globale.
• Sistem de fișiere root read-only: montează rădăcina containerului ca read-only, cu doar directoare specifice de output inscriptibile.
• Proxy de egress: direcționează traficul de ieșire printr-un proxy care permite registrul de pachete (npm, PyPI) și respinge restul, astfel încât comenzi precum npm install să funcționeze, dar un curl arbitrar nu.
• Limite de resurse: setează limite pentru CPU, memorie și I/O, astfel încât un proces să nu poată doborî host-ul.

Docker Sandboxes oferă fiecărui sandbox propriul microVM cu un daemon Docker privat. Daemonul host nu poate vedea nici măcar sandbox-urile în docker ps. Granița e mai aproape de o mașină virtuală decât de un container, ceea ce închide majoritatea căilor de evadare din containere care îi preocupă pe dezvoltatori.

Strategii de sandboxing pentru enterprise

Pentru organizații, întrebarea este cum să stratifici tehnicile de sandbox, nu dacă să le folosești.

Iată cum abordează majoritatea:

• Regulile de permisiuni intră în managed-settings.json și nu pot fi suprascrise de dezvoltatori individuali.

• Sandboxing-ul nativ rulează sub stratul de permisiuni.

• Containerele Dev sau Docker rulează sub acesta.

• Pentru scenarii de încredere maximă (acces la producție, gestionare de secrete), ultimul strat este un VM dedicat fără montare a sistemului de fișiere al host-ului.

Claude Code pe web este o versiune gestionată a aceleiași idei. Fiecare sesiune rulează într-un VM gestionat de Anthropic, credențiale sensibile precum token-urile git sunt plasate în afara sandbox-ului într-un proxy, iar granița e impusă de infrastructură.

Securitatea MCP în Claude Code

MCP este partea din Claude Code care crește cel mai repede.

Fiecare server MCP la care te conectezi cam multiplică ceea ce poate face Claude, dar multiplică și suprafața pe care o poate atinge un prompt injection sau o dependență compromisă. 

De exemplu:

• Un server MCP GitHub îi oferă lui Claude acces la pull request-uri.
• Un server MCP pentru baze de date îi oferă schema și interogările tale.
• Un server Slack îi oferă canalele tale.

Nimic din toate acestea nu e o problemă, dar înseamnă că MCP are nevoie de propria guvernanță. Conținutul extras printr-un instrument MCP (o pagină web sau un răspuns de API) poate conține instrucțiuni injectate pe care Claude le execută ca și cum le-ai fi tastat tu. De asemenea, fiecare server adaugă un credential și o cale de autentificare care trebuie gestionate separat.

Permisiuni pentru instrumente

Instrumentele MCP folosesc o convenție de denumire diferită față de instrumentele integrate.

Formatul regulii este mcp__servername__toolname, fără specificator între paranteze. De exemplu, mcp__github__create_pull_request îi permite lui Claude să apeleze exact acel instrument, iar un deny pe mcp__github__delete_repo îl blochează pe cel periculos. Listele allow, ask și deny funcționează la fel ca pentru Bash sau Read.

Se aplică și aceleași reguli de prioritate - mai întâi deny, apoi ask, apoi allow. Un deny în managed-settings pe mcp__github__delete_* e valabil în orice proiect de pe mașină.

Permisiuni pentru resurse

Serverele MCP pot expune resurse pe lângă instrumente.

O resursă este o bucată de date pe care serverul o pune la dispoziția lui Claude pentru citire (un fișier într-un server de project management sau un rând într-un server de baze de date). Accesul la resurse trece prin același control de încredere ca apelurile de instrumente, iar o conexiune MCP nouă rulează un pas de verificare a încrederii înainte ca oricare dintre instrumentele sau resursele sale să fie accesibile.

Implicitul corect este să tratezi resursele ca un alt instrument. Dacă n-ai acorda credentialul, nu acorda nici accesul la resurse.

Servere MCP aprobate

Anthropic Directory listează conectori pe care Anthropic i-a revizuit conform criteriilor sale de listare.

Pentru organizații, un model bun este folosirea unei liste interne de permise. Există două setări care îți oferă controlul:

• allowedMcpServers: un tipar glob al serverelor pe care dezvoltatorii le pot adăuga în proiectele lor (de exemplu, company-* pentru a permite doar serverele întreținute intern).

• deniedMcpServers: un tipar al serverelor care nu pot fi adăugate, chiar dacă dezvoltatorul încearcă.

Pentru servere obligatorii care ar trebui să fie prezente în fiecare sesiune, un fișier managed-mcp.json plasat în setările gestionate este modalitatea de a le distribui. Dezvoltatorii nu pot elimina sau modifica intrările.

O setare de evitat în repo-urile partajate este enableAllProjectMcpServers, care aprobă automat fiecare server MCP definit în .mcp.json. E convenabil pentru lucru solo și periculos pentru orice e versionat, deoarece un PR malițios poate adăuga un server nou în .mcp.json și să îl facă să ruleze fără prompt.

Acces la instrumente cu cel mai mic privilegiu

Același principiu ca la permisiunile Bash, doar aplicat la MCP.

Întrebarea de pornire este ce credential are fiecare server. Un server MCP de baze de date ar trebui să se conecteze la o replică de citire cu acces doar pentru citire, nu la primar cu drepturi de scriere. Un server MCP de API ar trebui să folosească un token limitat la cel mai mic set necesar de endpoint-uri, nu un token personal cu acces complet la org. Și tot așa.

Subagenții sunt o altă modalitate de a delimita accesul MCP. O definiție de subagent în .claude/agents/ poate declara exact ce instrumente are acces (folosind sintaxa mcp:<server>:<tool>), astfel încât un „deploy-agent” primește serverul de infrastructură, iar un „review-agent” primește doar Read, Grep și Glob. Agentul nu poate apela instrumente care nu i-au fost date.

Guvernanță MCP

Pentru o echipă sau organizație care rulează Claude Code la scară, MCP are nevoie de aceeași formă de guvernanță ca orice altă integrare de producție.

Asta înseamnă un registru de servere aprobate cu proprietari nominalizați, trasee de audit end-to-end ale invocărilor de instrumente (ce instrumente MCP au fost apelate, de către cine, cu ce parametri) și o revizuire periodică a listei de aprobare. Exportatorii OpenTelemetry din Claude Code îți oferă datele de audit într-un format care se integrează în orice stack de observabilitate folosești deja.

Pentru organizații mari, un gateway MCP centralizat este versiunea cea mai curată a acestui model. 

Dezvoltatorii se conectează la gateway în loc să înregistreze servere individuale. Gateway-ul gestionează autentificarea, impune acces bazat pe rol la nivel de instrument și emite un singur traseu de audit. De asemenea, rezolvă proliferarea credențialelor, pentru că un singur set de credențiale la gateway înlocuiește situația în care fiecare dezvoltator deține o copie a fiecărui API key.

Gestionarea secretelor și a datelor sensibile

Claude Code poate citi orice poți citi și tu, ceea ce face secretele accesibile.

Implicit, Claude Code poate citi orice fișier pe care contul tău de utilizator îl poate citi. Asta include fișierele .env din proiect, credențialele AWS din ~/.aws/, cheile private SSH din ~/.ssh/, token-urile GitHub din fișierul rc al shell-ului tău și variabilele de mediu din orice subproces pe care îl creează Claude. Este perfect normal și intenționat.

Ține secretele în afara workspace-ului

Primul pas este să te asiguri că secretele nu sunt în directorul pe care îl citește Claude.

.env sunt cele mai comune. Stau în rădăcina proiectului, sunt încărcate de fiecare unealtă de dev și conțin exact valorile pe care nu le vrei într-un context Claude (URL-uri de baze de date și chei API). 

Iată câteva modele pe care le poți folosi:

• Mută secretele într-un director în afara arborelui de lucru, de exemplu ~/.config/myapp/secrets.env, și încarcă-le printr-un manager de mediu sau o configurare direnv care indică spre fișierul extern.

• Pentru lucru containerizat, păstrează un folder .secrets/ în afara bind mount-ului, astfel încât fișierul să fie invizibil din interiorul containerului.

• Adaugă Read(**/.env) și Read(**/.env.*) în lista ta permissions.deny și combină-le cu deny-uri Bash(cat:*/.env) ca un script shell să nu poată citi ce nu poate citi instrumentul Read.

Folosește un manager de secrete

Pentru orice dincolo de proiecte demo, locul potrivit pentru secrete este un manager de secrete.

Modelul e același indiferent de furnizor (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Secretele sunt plasate în manager. Shell-ul sau runtime-ul le obține la cerere și le expune doar procesului care are nevoie de ele. Claude nu vede niciodată valoarea efectivă.

Pentru Claude Code în mod specific, asta înseamnă setarea CLAUDE_CODE_SUBPROCESS_ENV_SCRUB pentru a elimina credențialele Anthropic și ale furnizorilor de cloud din subprocese sau folosirea sandbox.credentials pentru a deselecta variabile specifice pentru comenzile sandboxate. Prima împiedică pe Claude să-ți treacă ANTHROPIC_API_KEY într-un script de build, iar a doua acoperă cazul mai larg al oricărei variabile de mediu sensibile care ajunge într-o comandă shell.

Restricționează accesul la repository

A treia opțiune este la nivel de repo.

Dacă un dezvoltator nu are nevoie de acces de scriere la configurația doar-de-producție, nici sesiunea lui Claude Code nu are. Sună evident, dar implicitul pentru majoritatea echipelor este că dezvoltatorii au acces mai larg decât folosesc de rutină, iar Claude moștenește totul.

Iată doi pași pe care îi poți face:

• Separă configurația de producție într-un repo distinct cu acces mai strict, astfel încât mediul de dev în care lucrează Claude să nu aibă secretele de producție de la bun început.

• Folosește token-uri cu scop restrâns pentru orice serviciu cu care interacționează Claude. De exemplu, un token GitHub pentru code review nu are nevoie de repo:delete.

Securitatea Claude Code pentru echipe

Un dezvoltator solo poate schimba settings.json cum vrea. O echipă nu, pentru că securitatea generală este doar la nivelul celei mai slabe configurații de pe cea mai slabă mașină. Pentru implementări la nivel de echipă și organizație, Claude Code are un strat separat de controale pe care un admin le împinge în jos și utilizatorii individuali nu le pot suprascrie.

Setări gestionate

Setările gestionate sunt fundația.

Fișierul este localizat într-o cale de sistem care necesită acces de admin pentru a scrie:

• /Library/Application Support/ClaudeCode/managed-settings.json pe macOS

• /etc/claude-code/managed-settings.json pe Linux

• C:\ProgramData\ClaudeCode\managed-settings.json pe Windows

Setările din acest fișier au prioritate față de setările la nivel de utilizator și proiect. O regulă deny pusă aici este un deny în fiecare proiect de pe mașină, iar dezvoltatorul nu o poate elimina editând propriul settings.json. Majoritatea organizațiilor distribuie fișierul prin MDM (Mobile Device Management) sau același canal de configurare pe care îl folosesc pentru alte unelte de dev.

Iată câteva setări utile la nivelul gestionat:

• permissions.deny pentru căi sensibile și comenzi periculoase

• defaultMode setat la default sau plan (niciodată bypassPermissions)

• allowManagedPermissionRulesOnly: true pentru a bloca setul de permisiuni

• enableAllProjectMcpServers: false pentru a cere aprobare explicită MCP

• Configurație pentru exportatorul OpenTelemetry pentru logging

Politici de permisiuni partajate

O echipă care cade de acord asupra a ceea ce poate face Claude ar trebui să țină la versiune acel acord.

Setările la nivel de proiect sunt localizate în .claude/settings.json la rădăcina repo-ului. Orice e versionat aici se aplică oricui rulează Claude în acel repo. Fișierul e locul potrivit pentru allow/deny specifice proiectului.

Ținând cont de asta, există o împărțire între setările gestionate și cele de proiect pe care trebuie s-o cunoști:

• Setările gestionate conțin politica organizației (nimeni nu rulează bypassPermissions, nimeni nu citește .env).

• Setările de proiect conțin convențiile de workflow (testele acestui repo rulează cu npm test; scriptul de deploy al acestui repo este interzis).

Guvernanța echipei

Pentru o lansare la nivel de echipă, stratul de politică are nevoie de un responsabil.

Majoritatea echipelor care rulează Claude Code la scară ajung la un grup mic, de obicei securitate și platform engineering, care deține setările gestionate, lista de permise MCP, scripturile hook și pipeline-ul OpenTelemetry. Același grup revizuiește cererile de excepții și ajustează politica pe măsură ce apar noi cazuri de utilizare.

Ar trebui să ai aceste piese în scris:

• Care repo-uri sunt în scop și care nu, cu moduri pe nivel de risc (un repo cu date reglementate probabil rulează Claude în modul plan, în timp ce un repo de site de marketing poate rula în acceptEdits).
• Cine poate acorda excepții și cum sunt urmărite acestea.
• O cadență de revizuire (trimestrial e comună) în care echipa revizitează regulile de permisiuni, serverele MCP și datele despre incidente.

Jurnalizare pentru audit

Claude Code emite evenimente OpenTelemetry pentru fiecare decizie privind instrumente, conexiune la server MCP, schimbare de mod de permisiune și cerere API. Nu curge niciun fel de date până când un admin configurează endpoint-ul OTLP în setările gestionate.

Iată un bloc minim de setări gestionate pentru telemetrie:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Implicit, conținutul prompturilor și parametrii instrumentelor sunt excluși din export, astfel încât evenimentele pe care le colectezi sunt metadate, nu conversația completă. Pentru a include textul prompturilor, setezi OTEL_LOG_USER_PROMPTS=1. Pentru a include argumentele instrumentelor (de obicei dorite pentru audit), setezi OTEL_LOG_TOOL_DETAILS=1. Ambele decizii au implicații de confidențialitate, așa că majoritatea echipelor le tratează ca alegeri deliberate de politică și își configurează backend-ul de telemetrie să filtreze sau să mascheze înainte de stocare.

Monitorizarea utilizării

Același flux OpenTelemetry din spatele auditului stă și la baza monitorizării utilizării.

Claude Code exportă metrici pentru utilizarea de token-uri, cost pe cerere, număr de sesiuni și ratele deciziilor privind instrumentele. Agregate, acestea îți arată ce echipe obțin cea mai mare valoare, ce fluxuri de lucru produc cele mai multe respingeri și ce modele generează costuri. Back-end-uri precum Datadog, Honeycomb, SigNoz, Elastic și Splunk ingestionează formatul standard OTLP.

Un vârf în evenimentele permission_decision cu decision=deny poate însemna că Claude încearcă prea mult, dar poate însemna și că regulile de allow ale echipei sunt prea restrictive.

Greșeli frecvente de securitate în Claude Code

Un set mic de configurări greșite apare în majoritatea incidentelor Claude Code. Îți arăt acum care sunt și ce să faci în privința lor.

Permisiuni prea largi

Cea mai rapidă metodă de a toci sistemul de permisiuni este să permiți prea mult.

Prompturile per comandă adaugă fricțiune, iar soluția ușoară e un allow larg Bash(*) sau setarea defaultMode: bypassPermissions. Ambele anulează mare parte din ce face sistemul de permisiuni.

Ar trebui să delimitezi regulile allow la instrumentele și comenzile pe care chiar le folosești (de exemplu Bash(npm test:*) și Bash(git status)) și să lași restul să revină la un prompt. Primești mai multe prompturi la început, dar în câteva sesiuni ai pus pe allow comenzile pe care le folosești, iar prompturile aproape dispar.

Acces MCP nerestricționat

A doua greșeală este conectarea serverelor MCP fără a verifica ce credențiale folosesc sau la ce pot ajunge.

De obicei se întâmplă pentru că cineva activează enableAllProjectMcpServers, conectează câteva servere din directorul public MCP și nu mai revine să le revizuiască. Când un server cu un credential slab scurge ceva sensibil, conexiunea e suficient de veche în configurare încât nimeni nu își mai amintește aprobarea.

Soluția e aceeași ca la permisiuni. Folosește o listă explicită de permise prin allowedMcpServers, un managed-mcp.json intern pentru serverele de care au nevoie toți și o cadență de revizuire a listei.

Fără sandboxing

Dacă sandboxing-ul este oprit, sistemul de permisiuni e singurul lucru între Claude și sistemul tău de fișiere.

E în regulă pentru sesiuni interactive scurte, unde aprobi oricum fiecare comandă. Nu e în regulă pentru rulări autonome, pentru sesiuni în care ai lărgit regulile allow sau pentru orice muncă ce atinge cod din surse externe.

/sandbox îl pornește. Dacă dependențele nu sunt instalate, meniul îți arată pe care să le instalezi pentru platforma ta. Odată pornit, prompturile de permisiune scad, iar OS-ul prinde cazurile pe care regulile tale allow nu le acoperă.

Acceptarea oarbă a schimbărilor

acceptEdits e și convenabil, și periculos.

Când Claude rescrie o funcție și îl monitorizezi, auto-acceptul e ok. Când Claude iterează peste 30 de fișiere într-o oră, tinzi să nu mai citești dif-urile și să începi să ai încredere în agent. Acolo pot apărea problemele.

Iată două obiceiuri pe care să le adopți:

• Fă mereu commit înainte să lași pe Claude să ruleze autonom, astfel încât calea de revenire să fie la un git reset distanță.

• Revizuiește diff-ul înainte de fiecare commit scris de Claude, nu diff-ul cumulativ la finalul sesiunii.

Ignorarea traseelor de audit

O echipă care rulează Claude Code fără telemetrie nu poate răspunde la întrebarea „care sesiune a făcut asta?”. Evenimentele se acumulează local pe fiecare mașină și acolo rămân. Prima dată când ai nevoie de un traseu de audit e și cel mai prost moment să descoperi că nu l-ai configurat.

Minimul util este exportul evenimentelor tool_decision, permission_decision și api_request către orice stack de observabilitate folosește echipa deja. De acolo, construiești dashboard-uri și alerte după cum apar cazurile de utilizare.

Concluzie

Cel mai rău scenariu pentru un chatbot este un răspuns prost. Dar pentru un agent de programare, este o comandă shell care rulează împotriva producției cu credențialele tale.

De aceea contează cei trei piloni:

• Permisiunile decid ce are voie să facă Claude
• Controalele MCP decid la ce sisteme externe poate ajunge
• Sandboxing-ul decide ce se întâmplă când primele două nu sunt suficiente

Fiecare acoperă un mod de eșec pe care celelalte nu îl acoperă. Împreună, definesc granița reală în care lucrează Claude.

Dacă vrei să te certifici în AI generativă, aici găsești comparații, cursuri de top, sfaturi de pregătire și întrebări frecvente pentru Cele mai bune certificări în AI generativă în 2026.