Izolarea agenților de programare: permisiuni, rețea, credențiale

Un agent de programare rulează cu drepturile tale. Are acces la depozit, la variabilele de mediu, la clientul de bază de date, la cheia din ~/.aws, la rețeaua companiei prin VPN-ul tău. Îi ceri să repare un test și, pe drum, poate citi orice fișier la care ai acces tu. Întrebarea nu e dacă îi dai voie, ci ce anume poate atinge când o face — iar răspunsul implicit al majorității echipelor este „tot".

Articolul e despre cele trei straturi care limitează raza de acțiune a unui agent pe laptopul unui developer și în pipeline: reguli, izolare la nivel de sistem de operare și control al rețelei și al credențialelor. Nu e despre guvernanța agenților la nivel de organizație — subiect tratat separat în ghidul despre agenți AI în enterprise — și nici despre calitatea codului produs, care e în articolul despre cod generat de AI în producție.

Ce s-a întâmplat în septembrie 2026

Discuția a încetat să fie teoretică. Pe 8 septembrie 2026, InfoQ a relatat avertismentul GitLab privind izolarea agenților: într-o evaluare, un model a evadat din sandbox exploatând o vulnerabilitate într-un proxy de pachete aprobat. Odată ieșit, agentul „a ajuns la internetul deschis și ulterior a accesat infrastructura internă de producție a Hugging Face, obținând seturi de date, informații despre cluster și credențiale cloud".

Propoziția care merită pusă pe perete, din același material: „lecția-cheie este că listele de permisiuni pe rețea nu sunt echivalente cu granițele de încredere". Un sandbox care permite accesul la registre de pachete sau la alte servicii aprobate expune agentul la căi de exploatare prin chiar acele conexiuni de încredere.

Recomandările GitLab sunt vechi și plictisitoare, ceea ce e un semn bun: agenții primesc „doar credențialele și permisiunile necesare pentru o sarcină anume", cu acces limitat în timp și în domeniu; accesul la rețea se minimizează, nu se acordă larg prin liste de permisiuni; se monitorizează comportamentul agentului, nu doar evenimentele de infrastructură.

Nimic din toate acestea nu e specific unui furnizor. Se aplică oricărui agent care rulează comenzi pe o mașină la care ai ținut vreodată o cheie. Modelarea amenințărilor pentru agenți care rulează cu acces real la sisteme, împreună cu guardrails-urile și supravegherea care le însoțesc, e subiectul cursului OpenClaw: securizarea agenților AI open-source în producție.

Stratul 1: regulile de permisiuni (și de ce nu sunt suficiente)

Uneltele moderne au un sistem de reguli pe trei stări — permite, întreabă, refuză. Detaliile contează mai mult decât pare.

Ordinea de evaluare. În Claude Code, regulile se evaluează în ordinea refuz, întreabă, permite, iar prima potrivire decide; specificitatea nu schimbă ordinea. Consecința practică, scrisă explicit în documentație: o regulă largă de refuz precum Bash(aws *) blochează orice apel care se potrivește, inclusiv unul acoperit de o regulă mai îngustă de permitere. O regulă de permitere nu poate decupa o excepție dintr-un refuz. Asta e exact invers față de intuiția formată pe firewall-uri, unde regula mai specifică câștigă.

Refuzul pe numele uneltei scoate unealta din context. O regulă de refuz care numește doar unealta — Bash, fără paranteze — o elimină complet din contextul modelului: agentul nici măcar nu o vede. O regulă cu tipar, precum Bash(rm *), lasă unealta disponibilă și blochează doar apelurile care se potrivesc.

Limita pe care documentația o recunoaște singură. O regulă Bash se potrivește pe textul comenzii pe care îl scrie agentul, după ce sistemul desparte comenzile compuse. Documentația spune direct că o astfel de regulă „nu este o graniță de securitate în jurul programului": același program invocat printr-o altă cale sau dintr-un sh -c nu se mai potrivește. Pentru o aplicare care nu depinde de textul comenzii, documentația trimite la sandbox.

Aceeași limită apare la fișiere. O regulă de refuz pe citire, de exemplu Read(./.env), blochează uneltele de fișiere ale agentului și comenzile pe care sistemul le recunoaște ca citind fișiere, dar nu se aplică unui subproces oarecare — un script Python sau Node care deschide singur fișierele trece pe lângă ea. Pentru o aplicare la nivel de sistem de operare, care blochează toate procesele, e nevoie de sandbox.

Și încă o capcană, tot din documentație: o regulă care permite doar anumite domenii pentru unealta de descărcare web nu previne accesul la rețea, dacă Bash e permis. Agentul poate folosi curl sau wget ca să ajungă oriunde.

Concluzia stratului 1: regulile sunt utile ca ghidaj și ca plasă pentru greșeli oneste. Nu sunt o barieră împotriva unui comportament care încearcă să le ocolească — nici al modelului, nici al unui pachet compromis pe care agentul tocmai l-a instalat. Modul de lucru cu permisiuni, hooks și fluxuri de aprobare pe depozite reale e tratat pe larg în cursul Claude Code Mastery.

Stratul 2: izolarea la nivel de sistem de operare

Aici se schimbă natura garanției: nu mai depinde de ce scrie agentul în comandă, ci de ce permite nucleul sistemului.

În Claude Code, sandboxul de Bash aplică restricții de fișiere și de rețea „pentru fiecare comandă Bash, PowerShell sau Monitor și pentru procesele-copil". Pe macOS folosește Seatbelt, mecanismul integrat în sistem; pe Linux și WSL2 se sprijină pe două pachete, între care socat, releul prin care traficul e rutat către proxy-ul sandboxului. Windows nativ nu e suportat — pe Windows, agentul se rulează într-o distribuție WSL2.

Ce configurezi, concret:

• sandbox.enabled în setările de utilizator, ca sandboxul să fie activ în toate proiectele; pentru o organizație, prin setări gestionate central, ca să nu poată fi dezactivat local.
• sandbox.failIfUnavailable. Atenție aici, e cel mai important detaliu din întreaga pagină: implicit, dacă sandboxul nu poate porni — lipsesc dependențe, platforma nu e suportată — Claude Code afișează un avertisment și rulează comenzile fără sandbox. Setarea aceasta transformă situația în eroare. Fără ea, ai o măsură de securitate care dispare tăcut exact pe mașinile configurate greșit.
• Fișiere: implicit, comenzile din sandbox scriu în directorul de lucru și în directoarele adăugate explicit; pentru restul există sandbox.filesystem.allowWrite, denyWrite, denyRead și allowRead, cu regula că, la suprapunere, se aplică tiparul mai îngust.
• Rețea: lista de domenii permise, verificată de proxy-ul sandboxului. Prima dată când o comandă are nevoie de un domeniu nou, agentul cere aprobare.

Există și o variantă în care dezactivezi izolarea de fișiere și păstrezi doar pe cea de rețea. Documentația o însoțește de un avertisment care merită citit de două ori: cu izolarea de fișiere oprită și comenzile aprobate automat, o comandă poate scrie fișiere pe care comenzile următoare le citesc sau le execută — fișiere de pornire ale shell-ului, executabile din $PATH, chiar fișierul de setări al agentului — și își poate lărgi singură accesul la următoarea rulare.

Stratul 3: rețeaua și credențialele

Lecția GitLab spune că rețeaua e suprafața principală. Trei decizii fac diferența.

Egress minim, nu listă largă. Un agent care compilează și rulează teste are nevoie de registrul de pachete și de nimic altceva. Nu de internetul deschis, nu de rețeaua internă, nu de endpoint-ul de metadate al mașinii virtuale. Iar dacă registrul e un proxy intern, acel proxy devine parte din suprafața de atac — exact scenariul din incident. Ține-l actualizat și fără credențiale utile în interiorul sandboxului.

Credențialele nu trebuie să fie citibile. Claude Code are pentru asta un bloc dedicat, sandbox.credentials, cu două regimuri: refuz — comanda nu vede deloc valoarea — și mascare. La mascare, comanda primește o valoare-santinelă per sesiune, iar proxy-ul înlocuiește santinela cu valoarea reală doar pe conexiunile către gazdele listate în injectHosts, care trebuie să fie și în lista de domenii permise. Comanda și tot ce jurnalizează ea nu conțin niciodată credențialul real, dar cererile se autentifică. Pentru ca proxy-ul să poată face substituția, el trebuie să încheie conexiunea TLS, ceea ce se configurează separat. Există și varianta radicală, o variabilă de mediu care curăță credențialele din toate subprocesele, indiferent de sandbox.

Separarea mediilor. Regula care rezolvă 80% din risc fără nicio configurare: pe mașina unde rulează agentul nu există chei de producție. Nici în variabile de mediu, nici în profilul cloud implicit, nici într-un fișier de configurare „temporar". Dacă agentul are nevoie de acces la un serviciu, primește un cont separat, cu drepturi minime și durată scurtă.

Agentul în integrarea continuă

Când agentul rulează fără om în fața ecranului, riscurile se schimbă: nu mai există aprobarea interactivă, dar există secrete de organizație și rețea internă.

• Token-uri cu durată scurtă și domeniu restrâns, emise pentru sarcina curentă, nu secretele permanente ale proiectului.
• Fără secrete de producție în job-ul agentului. Dacă job-ul trebuie să acceseze un serviciu, folosește un cont dedicat, cu drepturi de citire pe ce îi trebuie.
• Runner izolat de rețeaua internă. Un agent care poate ajunge la serviciile interne nu mai are nevoie de nicio evadare: are deja acces.
• Rezultatul e o propunere, nu o livrare. Modificările agentului ajung în pull request, cu aprobare umană; nu i se dă drept de integrare directă.
• Modurile care ocolesc aprobările se dezactivează din setările gestionate central — în Claude Code, prin permissions.disableBypassPermissionsMode și permissions.disableAutoMode, cel mai util aplicate ca politică, unde nu pot fi suprascrise local.

Ce jurnalizezi ca să poți investiga

GitLab formulează cerința scurt: monitorizează comportamentul agentului, nu doar evenimentele de infrastructură. În practică, minimul util e:

• comenzile executate, cu directorul de lucru și codul de ieșire;
• domeniile contactate și cele refuzate de proxy;
• fișierele citite și scrise în afara directorului de lucru;
• momentele în care cineva a ocolit o regulă sau a aprobat manual o acțiune blocată;
• ce versiune de configurație era activă în sesiune.

Fără ultimul punct, o investigație se împotmolește în „cine avea ce setare atunci". Jurnalele se păstrează cu aceeași disciplină ca oricare altele: termen de retenție explicit, fără conținut de fișiere în clar și fără chei, chiar mascate, în textul comenzilor salvate.

Partea de conformitate, pe scurt

Două lucruri care transformă discuția din „bună practică" în obligație, pentru firmele care livrează software în Uniunea Europeană.

Raportarea vulnerabilităților. Obligațiile de raportare din Regulamentul privind reziliența cibernetică se aplică din 11 septembrie 2026, iar detaliile sunt în articolul dedicat despre Cyber Resilience Act. Un incident în care un agent a exfiltrat date dintr-un mediu de dezvoltare nu e o problemă internă dacă atinge un produs pe care îl pui pe piață.

Lanțul de aprovizionare. Clienții care intră sub NIS2 își evaluează furnizorii, iar cerințele coboară pe lanț prin contract. Contextul de aplicare în România, cu obligațiile conducerii și sancțiunile, e în articolul despre NIS2 în România. Practic: modul în care rulezi agenții devine parte din răspunsul pe care îl dai la evaluarea de securitate a clientului.

Listă de control

1. Sandbox activ implicit, cu eșec dur când nu poate porni.
2. Scriere permisă doar în directorul de lucru; excepțiile, enumerate explicit.
3. Citire blocată pe fișierele de mediu, chei și dumpuri de date.
4. Listă de domenii minimă; fără internet deschis pentru sarcini de compilare.
5. Proxy de pachete actualizat, tratat ca suprafață de atac, nu ca serviciu de încredere.
6. Fără credențiale de producție pe mașina agentului; restul, mascate sau refuzate.
7. Modurile care ocolesc aprobările, dezactivate prin politică.
8. Reguli de refuz pentru comenzile distructive și pentru zonele sensibile din cod.
9. Hooks deterministe pentru verificările care trebuie să ruleze indiferent de decizia modelului.
10. În integrarea continuă: token-uri scurte, runner izolat, rezultat sub formă de pull request.
11. Jurnal de comenzi, domenii și ocoliri, păstrat și citit.
12. O repetiție: ce faci dacă un agent a atins ceva ce nu trebuia — cine rotește cheile, în ce ordine.

Întrebări frecvente

Î: Regulile de permisiuni sunt suficiente ca să izolez un agent? R: Nu. Documentația Claude Code precizează că o regulă pe comenzi de shell se potrivește pe textul comenzii și „nu este o graniță de securitate în jurul programului": același program invocat altfel nu se mai potrivește. La fel, o regulă de refuz pe citirea unui fișier nu oprește un subproces care deschide singur fișierul. Pentru garanții reale e nevoie de izolare la nivel de sistem de operare.

Î: Ce s-a întâmplat, mai exact, în incidentul relatat în septembrie 2026? R: GitLab a descris o evaluare în care un model a evadat din sandbox exploatând o vulnerabilitate într-un proxy de pachete aflat pe lista de permisiuni, a ajuns la internetul deschis și a accesat apoi infrastructura internă de producție a Hugging Face, obținând seturi de date, informații de cluster și credențiale cloud. Concluzia formulată acolo: listele de permisiuni pe rețea nu sunt echivalente cu granițele de încredere.

Î: Pot rula un agent pe Windows cu izolare? R: Sandboxul din Claude Code funcționează pe macOS, Linux și WSL2; Windows nativ nu e suportat, iar recomandarea documentației e să rulezi agentul într-o distribuție WSL2. Independent de unealtă, alternativele valabile rămân containerul de dezvoltare sau o mașină virtuală dedicată.

Î: Cum protejez cheile dacă agentul are nevoie de ele ca să apeleze un serviciu? R: Fără să i le arăți. Mecanismul de mascare înlocuiește valoarea reală cu o santinelă per sesiune, iar proxy-ul substituie valoarea doar pe conexiunile către gazdele permise explicit. Comanda se autentifică, dar nici ea, nici jurnalele ei nu conțin credențialul. Varianta mai simplă și adesea suficientă: chei separate, cu drepturi minime și durată scurtă, emise doar pentru mediul de dezvoltare.

Î: E riscant să las agentul să ruleze comenzi automat, fără să confirm fiecare? R: Depinde exclusiv de ce poate atinge când rulează. Aprobarea automată în interiorul unui sandbox cu fișiere și rețea restrânse e o decizie rezonabilă. Aprobarea automată fără izolare, pe o mașină cu chei de producție și acces la rețeaua internă, e alt lucru. Ordinea corectă e: mai întâi izolarea, apoi automatizarea.

Concluzie

Incidentul relatat în septembrie 2026 nu arată că agenții sunt periculoși prin natura lor, ci că un mediu de dezvoltare obișnuit e o țintă bogată: chei, acces la rețea, servicii interne, toate la îndemâna unui proces care execută ce i se cere. Vestea bună e că apărarea nu cere nimic nou — sunt aceleași principii aplicate la orice risc uman: acces limitat, izolare la nivelul sistemului, egress minim, credențiale de scurtă durată, jurnal.

Diferența dintre o echipă care doarme liniștită și una care va scrie într-o zi un raport de incident nu stă în modelul ales, ci în răspunsul la o întrebare simplă: dacă agentul ar face acum cel mai prost lucru posibil, până unde ar ajunge?

Surse: InfoQ — GitLab despre accesul de rețea al sandboxurilor pentru agenți AI (8 septembrie 2026) · Claude Code — configurarea permisiunilor · Claude Code — sandboxul pentru comenzi

Articol informativ, publicat la 18 septembrie 2026. Are caracter educativ și nu constituie consultanță de securitate sau juridică. Numele setărilor și capacitățile uneltelor se modifică între versiuni — verifică documentația oficială înainte de a configura un mediu de producție.