Când discutăm despre securitatea modelelor lingvistice, subiectul rămâne la fel de actual ca în primele zile ale internetului public: cine face ce, în ce mod și cât de sigur este. Această relatare se concentrează pe Anthropic și pe funcția lor de creare de fișiere din Claude, analizată în principal de cercetătorul independent Simon Willison, într-un context care cuprinde atât măsuri tehnice, cât și responsabilități transferate utilizatorilor.
Anthropic a pus în aplicare un set clar de măsuri pentru a diminua riscurile asociate funcției de creare de fișiere din Claude, însă unele recomandări lasă o parte semnificativă din responsabilitate în sarcina utilizatorului. Compania a introdus un clasificator destinat detectării injecțiilor de prompt și întreruperii execuției când astfel de atacuri sunt depistate. Utilizatorilor Pro și Max le-a fost eliminată opțiunea de partajare publică a conversațiilor care folosesc această funcționalitate, iar clienții Enterprise beneficiază de izolare în sandbox, astfel încât mediile de rulare să nu fie împărțite între organizații. Totodată, Anthropic a scurtat durata sarcinilor și timpul de rulare al containerelor ca apărare împotriva buclelor de activitate malițioasă. Administratorii de echipă și cei Enterprise pot decide dacă activează această funcție pentru organizațiile lor, iar lista de domenii permise pentru Claude include api.anthropic.com, github.com, registry.npmjs.org și pypi.org.
Cu toate acestea, sfatul oficial al companiei, monitorizați Claude în timp ce folosiți funcția și opriți-l dacă observați accesări neașteptate, a atras critici. Willison a susținut pe blogul său că această recomandare echivalează cu externalizarea problemei către utilizatori, adică responsabilitatea securității ajunge, în practică, la persoana care folosește instrumentul. El rămâne rezervat în utilizarea funcției pentru date pe care nu dorește sub nicio formă să le scurgă către terți, chiar dacă riscul pare mic, și a semnalat, de asemenea, vulnerabilități similare în versiunea Claude pentru Chrome, lansată recent ca previzualizare pentru cercetare.
Contextul mai larg este relevant: mulți experți observă o tendință de „lansezi rapid și securizezi ulterior”, pe fondul unei competiții acerbe între furnizorii de AI. Willison, care a documentat pe larg problema injecțiilor de prompt și care a popularizat chiar termenul, atrage atenția de ani de zile că aceste vulnerabilități persistă la aproape trei ani de la primele semnale. În septembrie 2022 el avertiza că anumite sisteme nu ar trebui construite până când nu există soluții robuste; constatarea recentă este că, totuși, astfel de sisteme au fost dezvoltate.
Anthropic declară că desfășoară un proces continuu de testare a securității și red-teaming pentru această funcție, iar documentația le recomandă organizațiilor să evalueze protecțiile în raport cu propriile cerințe de securitate înainte de a decide activarea. Compania a actualizat relatarea pe 10 septembrie 2025, la ora 9:50, pentru a corecta informații despre eforturile de red-teaming și pentru a detalia mai bine măsurile de atenuare implementate.
Măsurile concrete menționate în text includ clasificatorul anti-injecții, dezactivarea partajării publice pentru Pro și Max, izolarea în sandbox pentru Enterprise, limitarea duratei și a timpului de rulare al containerelor, precum și allowlist-ul de domenii precum api.anthropic.com, github.com, registry.npmjs.org și pypi.org. Willison rămâne precaut și recomandă evitarea utilizării funcției pentru date sensibile dacă există orice posibilitate ca o instrucțiune malițioasă să pătrundă.
Reflectând asupra securității AI în acest caz, problema nu este doar una tehnică, ci și de responsabilitate: cine decide când un produs este suficient de sigur pentru utilizarea în lumea reală? Numele invocate, Anthropic și Simon Willison, împreună cu detaliile tehnice despre allowlist și izolare în sandbox arată că există eforturi serioase, dar și puncte vulnerabile care necesită atenție constantă. Sisteme precum Claude ridică întrebări concrete despre echilibrul între inovația rapidă și necesitatea protejării datelor, mai ales pentru clienții enterprise care manipulează documente sensibile. Cum ți-ai administra tu riscul dacă ai controla accesul la această funcție pentru echipa ta?
da, dar serios? le dai utilizatorilor rolul de gardian… si mai zic si „monitorizati”. LOL.
eu as zice: off pt orice doc sensibila. nu e ok sa te bazezi pe om sa observe o iesire ciudata la timp. ce daca e noaptea? ce daca e cineva neatent?
sandbox si allowlist sunt ok, dar nu-s solutii magice. scurtezi timpul de run, bine, dar tot pot scapa chestii in loguri sau la 3rd parties. Willison are dreptate, nu-i paranoia.
pt enterprise: teste interne, red-teaming real, nu doar checkbox. si daca totusi activezi, backup, auditing, si sa nu fie default on. asta e.
ok, dar cade pe user. prefer model cu guardrails serioase, gen DeepMind’s interpretability work, plus SELinux sandbox, nu doar allowlist.