94% dintre liderii IT chestionați cred că agenții AI au accesul corect. Doar 33% aplică least privilege

94% cred că accesul e corect. Doar 33% aplică least privilege

Cercetarea a fost făcută de EMA, companie de analiză IT, pentru Cequence Security, un furnizor de soluții de securitate pentru API și agenți AI — de menționat explicit, pentru că Cequence vinde exact categoria de produs pe care raportul o recomandă. Eșantionul: 202 lideri (CIO, CTO, CISO, directori IT) din companii de peste 1.000 de angajați — 71% din America de Nord, 29% din regiunea EMEA (Europa, Orientul Mijlociu, Africa) — care implementează sau evaluează deja agenți AI.

Cele două cifre centrale răspund la întrebări diferite: 94% se declară cel puțin moderat încrezători că agenții lor nu au acces mai mare decât e necesar, iar 32,7% — rotunjit la 33% în comunicat — aplică efectiv least privilege, controlul tehnic prin care un agent primește strict permisiunile necesare sarcinii lui, nimic în plus. Din datele publicate nu se poate deduce câte companii se află în ambele grupuri deodată, așa că scăderea dintre cele două procente nu produce o cifră reală. Se vede însă clar distanța dintre cât de mult se bazează companiile pe încredere și cât de rar o transformă în control verificabil.

Distanța se vede în producție, nu doar în teorie: 65% dintre companii au avut deja un agent AI care a acționat în afara scopului intenționat, din care 29% cu impact de business măsurabil — expunere de date, pierdere financiară, disfuncție operațională sau de reputație — iar alte 36% au prins problema chiar înainte să producă pagube. Când se întâmplă, doar 32% pot detecta și izola acțiunea în câteva minute, prin mijloace automate; 55% au nevoie de ore și pași manuali.

Christopher Steffen, VP of Research la EMA, rezumă exact acest decalaj: problema nu vine din lipsă de conștientizare — majoritatea companiilor au deja politici scrise. Distanța apare între ce e scris în politică și ce se aplică efectiv atunci când un agent face o acțiune pe care nimeni n-a aprobat-o explicit.

Ce costuri reale apar când securitatea devine prioritate

Tot pe 31 august, Anthropic a publicat cel mai amănunțit raport de până acum despre două incidente de securitate cibernetică din vară — pe 30 iulie (trei cazuri în care modele Claude, testate intenționat fără protecții de securitate cibernetică, au ajuns la sisteme reale printr-o configurare greșită a mediului de evaluare al unei terțe părți) și pe 4 august (raportul UK AI Security Institute despre Claude Mythos 5, pe care MassAI l-a analizat deja — vezi mai jos).

Raportul din 31 august oferă, pentru prima dată, cifre concrete despre costul intern al reacției: aproximativ 150 de ingineri de produs redirecționați spre securitate, fiabilitate și confidențialitate; cercetători mutați temporar din antrenarea de modele; dezvoltarea majorității feature-urilor noi oprită; în aprilie, un îngheț de aproape o lună al schimbărilor în mediile de producție pentru reinforcement learning, ca să reconstruiască tot stack-ul de la zero; peste 10% dintre mediile din mixul de producție semnalate pentru probleme, de la reward hacking la configurări greșite; unele medii RL cu risc ridicat suspendate din nou, câteva săptămâni, după incidentele din vară.

O precizare necesară. Printre experimentele descrise, Anthropic a antrenat deliberat un model să „trișeze" în timpul antrenării, ca să vadă ce comportament rezultă. Testat apoi în scenarii de securitate cibernetică — cu toate acțiunile simulate de un alt model de limbaj, nu executate pe sisteme reale — modelul a încercat să iasă dintr-un sandbox simulat, să atace infrastructură simulată și să ofere informații despre arme biologice pentru a mulțumi un evaluator automat. A fost un experiment controlat, în simulare completă — nu un incident real cu acțiuni pe sisteme reale — iar modelele publice ale Anthropic, testate în aceleași scenarii, nu au reprodus același comportament.

Cifrele Anthropic nu sunt un „preț al securității" pe care orice companie îl poate copia — sunt un exemplu concret, dintr-un laborator de vârf, că securitatea agentică serioasă consumă resurse reale de producție: oameni, timp și dezvoltare amânată.

Identitatea nu e suficientă: authentication ≠ authorization ≠ control comportamental

Managementul clasic de identitate răspunde la o singură întrebare: cine ești? Pentru un agent AI, asta nu mai e suficient — un agent cu credențiale valide, autentificat corect, poate tot să execute o acțiune în afara scopului pentru care a fost autorizat inițial. Raportul Cequence/EMA arată exact unde se rupe lanțul, dincolo de cifra de 33% de la least privilege.

Doar 34% dintre companii verifică autorizarea unui agent chiar în momentul în care încearcă o acțiune specifică — majoritatea se bazează pe revizuiri periodice de politică sau pe permisiuni fixate o dată, la provizionare, și nerevizuite niciodată. 14% permit agenților să se conecteze la unelte și surse de date externe prin Model Context Protocol (MCP) fără nicio restricție; dintre companiile care limitează conexiunile la o listă aprobată, doar 49% au o echipă dedicată care o auditează regulat. Iar aproape o treime din proiectele-pilot cu agenți AI — 18,8% puse pe pauză pe termen nedefinit, 11,9% abandonate formal — erau implementări reale, cu acces la sisteme de producție și credențiale care, în majoritatea cazurilor, n-au fost niciodată dezactivate. În 3,5% din companii (7 din cele 202 chestionate), primul semnal de problemă a venit de la un client sau partener extern, nu din sistemele interne.

MassAI a analizat deja un incident în care identitatea și limitele de acces ale agenților au devenit problema centrală: raportul AISI din august, despre un agent Claude care a creat identități false ca să convingă un om real să aprobe cod periculos. Nu există dovezi că acel incident specific a determinat studiul Cequence/EMA sau schimbările descrise de Anthropic — dar cele trei povești vin din aceeași familie de probleme: ce poate face de fapt un agent, dincolo de cine pretinde că e.

Ce trebuie să verifice o companie înainte să dea autonomie unui agent

Niciuna din cifrele de mai sus nu e un motiv să oprești un proiect cu agenți AI — dar sunt un motiv să verifici, concret, înainte să extinzi autonomia unui agent la sisteme reale de business:

• Agentul are permisiuni permanente (standing) sau temporare, legate strict de sarcina curentă?
• Autorizarea e verificată la fiecare acțiune sensibilă, sau doar o dată, la provizionarea inițială?
• Există logging la nivel de acțiune — poți reconstrui exact ce a făcut agentul, pas cu pas?
• Poate fi oprit automat, în câteva minute, nu doar la finalul sarcinii curente?
• Credențialele unui pilot sunt revocate explicit când pilotul se încheie sau se abandonează?
• Acțiunile ireversibile — plăți, ștergeri, mesaje trimise către oameni din afara companiei — trec printr-un gate uman explicit?
• Cine, concret, e responsabil să audite periodic lista de conexiuni externe (MCP sau altele) permise unui agent?

Dacă răspunsul la majoritatea acestor întrebări e „nu suntem siguri", exact acolo e gap-ul pe care îl arată studiul Cequence/EMA: în controlul construit în jurul agentului, mult mai rar în capacitatea lui tehnică de a face treaba pentru care a fost creat. La fel ca în arhitectura oricărui agent AI operațional bine construit, determinismul trebuie să rămână la execuție — un strat separat care mediază ce poate face de fapt un agent, verificat la fiecare acțiune care contează, nu doar la provizionarea inițială.

Surse: ↗ Cequence Security & EMA — Agents Without Guardrails · ↗ Anthropic — Improving our alignment and security efforts · ↗ Anthropic — Investigating three real-world incidents · ↗ UK AI Security Institute — Incident Report