Ce permisiuni dai, de fapt, agenților AI din companie

De ce agenții AI au primit voie să acționeze singuri

Pe 26 august 2026, Claude in Chrome a trecut în disponibilitate generală, iar schimbarea reală nu a fost extensia în sine, ci faptul că agenții AI pot executa acțiuni în browser fără aprobare pentru fiecare pas — până atunci, fiecare clic cerea confirmare explicită. Mutarea nu e izolată: în ultimul an, industria s-a deplasat dinspre „modele mai bune” spre „agenți care fac treaba”, cu permisiuni tot mai largi și tot mai puțină supraveghere pas cu pas.

Pentru o companie din România care ia în calcul un agent AI — pentru marketing, pentru suport, pentru procese interne — asta înseamnă o întrebare nouă, pe care „îl instalăm sau nu” n-o mai acoperă: cât de multă libertate de acțiune primește, de fapt, acel agent, și cine decide unde se oprește? Răspunsul serios nu e „cât mai multă autonomie posibil”, ci o limită explicită, stabilită înainte ca agentul să înceapă să lucreze, nu descoperită după primul incident.

„Agents Rule of Two”: regula simplă care previne dezastrele

Meta a publicat, pe 31 octombrie 2025, un cadru simplu numit „Agents Rule of Two”, gândit exact pentru companiile care nu au o echipă de securitate dedicată agenților AI. Regula identifică trei capacități riscante pe care le poate avea un agent: procesarea de conținut nesigur (venit de pe internet, dintr-un email sau dintr-un document extern), accesul la date sau sisteme sensibile și capacitatea de a schimba o stare sau de a comunica spre exterior — a trimite un email, a face o plată, a publica ceva. Regula spune simplu: un agent poate avea maximum două din aceste trei, fără supraveghere umană directă.

Dacă un agent are toate cele trei simultan — citește conținut nesigur, are acces la date private și poate acționa spre exterior — fără să înceapă o sesiune nouă între pași, nu ar trebui lăsat să funcționeze complet autonom. În acel caz, fie limitezi una dintre cele trei capacități, fie introduci un pas de aprobare umană explicită înainte de acțiunea finală. E o regulă suficient de simplă încât s-o verifici singur, fără consultanță de securitate, pentru orice agent pe care iei în calcul să-l pui în producție.

Ce înseamnă „Rule of Two” pentru permisiunile agenților din compania ta

Un exemplu concret: un agent care citește email-urile primite și redactează răspunsuri pe care le trimite automat are două din cele trei capacități — procesează conținut nesigur (email-urile primite pot conține instrucțiuni ascunse) și acționează spre exterior (trimite răspunsuri). Dacă agentul respectiv nu are, în plus, acces la alte sisteme sensibile ale companiei, combinația rămâne, conform regulii, într-o zonă acceptabilă pentru autonomie, cu monitorizare normală.

Situația se schimbă radical dacă același agent primește și acces la contul bancar al firmei sau la baza de date a clienților — atunci adaugă a treia capacitate, iar combinația completă cere fie eliminarea uneia dintre cele trei, fie un pas de confirmare umană înainte de orice acțiune ireversibilă. Diferența dintre „agent util” și „risc de securitate” nu stă în cât de sofisticat e modelul din spate, ci în combinația exactă de acces pe care i-ai dat-o, adesea fără să te gândești explicit la ea.

De ce contează exact acum: injection-ul rămâne nerezolvat

Motivul pentru care regula asta contează exact acum, nu peste doi ani, e că industria a primit voie să acționeze autonom înainte să aibă o soluție completă pentru prompt injection — tehnica prin care un text ascuns, plasat într-o pagină web sau un document, deturnează instrucțiunile unui agent. Raportul OWASP pe aplicații agentice arată că prompt injection e mapat pe șase din cele zece categorii ale Top 10 Agentic, iar din cincizeci și trei de proiecte agentice urmărite, douăzeci și opt sunt chiar unelte de programare.

Concluzia practică nu e să eviți agenții AI, ci să nu-i tratezi ca pe un chatbot obișnuit: un agent care poate naviga web nesupravegheat sau poate citi documente venite de la terți moștenește exact riscul pe care industria încă îl gestionează activ. Limitele de permisiuni nu sunt birocrație inutilă — sunt răspunsul direct la o vulnerabilitate reală și documentată, nu una ipotetică sau exagerată de presă.

Ce cere legea: Art. 50 din AI Act, pe scurt

De pe 2 august 2026 se aplică articolul 50 din AI Act european, care introduce obligații de transparență pentru orice sistem interactiv și pentru conținutul sintetic generat de AI — practic, un chatbot sau un agent trebuie să comunice clar utilizatorului că vorbește cu un sistem automat, nu cu un om. Termenul de grație pentru marcarea (watermarking) conținutului generat de sisteme puse pe piață înainte de 2 august se întinde până pe 2 decembrie 2026, iar obligațiile pentru sistemele de risc ridicat rămân amânate spre 2027-2028.

Pentru o companie care folosește deja conținut vizual sau video generat de AI în materiale de prezentare sau pe site — hero-uri, vizualuri de produs — asta înseamnă o verificare simplă, dar necesară: acel conținut respectă obligația de marcare? Nu e o schimbare dramatică de proces, dar e genul de detaliu care, ignorat, devine o problemă de conformitate ușor de evitat dacă e tratat din timp, nu descoperit la un control. Ce înseamnă concret pentru o afacere mică găsești în articolul despre obligațiile de transparență din AI Act.

Riscul ascuns: skill-urile pe care le instalezi pentru agent

O parte separată, dar înrudită, a riscului vine din materialul din care sunt construiți agenții: skill-urile — instrucțiuni text pe care le instalezi ca să extinzi ce poate face un agent. Snyk a analizat aproape patru mii de skill-uri publice și a găsit peste o treime cu cel puțin o problemă de securitate, iar analiza separată a NVIDIA a găsit vulnerabilități reale la aproximativ un sfert din eșantion. O notă de onestitate contează aici: titlul raportului Snyk vorbește despre „prompt injection” ca proporție mare, dar tabelul lor arată că injection-ul reprezintă o felie mică din total.

Concluzia practică e simplă: un skill nu e un fișier text inofensiv, ci moștenește accesul agentului la variabile de mediu, chei API și foldere sensibile. Înainte să instalezi un pachet de skill-uri dintr-un marketplace necunoscut, merită rulat printr-un scanner dedicat, la fel cum ai scana orice dependință de cod nouă înainte s-o pui în producție — practica de securitate din dezvoltarea software se aplică identic aici, nu e un domeniu separat.

Un checklist practic înainte să lași un agent AI să acționeze singur

Înainte să lași un agent AI să acționeze autonom în compania ta, câteva verificări simple reduc semnificativ riscul, fără să ceară o echipă de securitate dedicată sau cunoștințe tehnice avansate — doar disciplina de a le parcurge de fiecare dată când adaugi o capacitate nouă agentului respectiv sau îi conectezi un tool suplimentar. Lista de mai jos e gândită să fie parcursă în câteva minute, nu tratată ca un audit formal de securitate.

Checklist-ul nu înlocuiește o discuție de securitate dacă agentul atinge operațiuni financiare sau date personale ale clienților. În agenții pe care îi construim, limitele sunt impuse din afara modelului: permisiuni pe rol, jurnal de audit și aprobare umană explicită pentru orice pas cu impact legal, financiar sau contractual. Nu ne bazăm pe promisiunea că AI-ul „se va comporta”, ci construim controale care nu pot fi ocolite. Tema a intrat și în a doua fază a training-ului AI de la FOX, pentru 28 de angajați: din ce e făcut un agent — unelte, memorie, permisiuni, control uman.

• 01Listează explicit cele trei capacități: date private, conținut nesigur, acțiune externă
• 02Verifică dacă agentul are toate trei simultan, fără sesiune nouă între ele
• 03Adaugă un pas de aprobare umană pentru orice acțiune ireversibilă
• 04Scanează orice skill sau plugin instalat înainte să-l pui în producție
• 05Verifică dacă orice conținut sintetic generat respectă obligația de marcare

Greșeli frecvente când adopți agenți AI în companie

Cea mai frecventă greșeală e tratarea unui agent AI ca pe o unealtă de productivitate obișnuită, fără nicio discuție explicită despre ce acces primește — se instalează, i se dau credențiale „ca să meargă mai repede”, iar limita de permisiuni nu apare niciodată ca subiect de discuție. A doua greșeală e presupunerea că un furnizor „de încredere” elimină nevoia de verificare proprie — regula celor două din trei se aplică indiferent cine a construit agentul, pentru că riscul vine din combinația de acces, nu din calitatea modelului din spate.

A treia greșeală, cea mai costisitoare pe termen lung, e amânarea discuției despre permisiuni până după un incident — un email trimis greșit, o acțiune executată pe baza unui conținut manipulat, o scurgere de date. Costul de a stabili limitele de la început e aproape zero; costul de a le stabili după ce ceva a mers prost include, aproape mereu, și repararea încrederii pierdute, nu doar a sistemului tehnic afectat.

Dacă pregătești primul agent AI în firma ta, pornește de la o listă scrisă: ce date citește, de unde primește conținut, ce acțiuni poate face singur și unde cere aprobare. Discovery-ul pentru agenții AI pe care îi construim include mereu discuția despre permisiuni; după el, prețul e fix și nu se schimbă pe parcurs. Vrei o a doua părere pe un agent pe care îl ai deja sau îl pregătești? Rezervă sesiunea gratuită de 30 de minute sau sună la 0733 045 833.

Surse și lecturi.

• 01Meta AI Blog — Agents Rule of Two: A Practical Approach to AI Agent Security
• 02Help Net Security — OWASP prompt injection AI security failures
• 03Latham & Watkins — AI Act update: EU resolves to change rules and extend deadlines
• 04Snyk — ToxicSkills: malicious AI agent skills on ClawHub
• 05Help Net Security — SkillSpector: open-source agent skill security scanner
• 06Simon Willison — Prompt injection (ongoing coverage)

Întrebări frecvente

Echipa The Niche SocietyIngineri AI și software din București · LinkedIn

publicat 2026-09-09