● Analiză · 29 septembrie 2026 · 6 min

Să-i spui unui agent AI „nu face asta” nu este un control de securitate

Pe 28 septembrie, UK AI Security Institute (AISI), institutul britanic pentru securitatea AI, a publicat rezultatele unor teste pe GPT-6 Astra, modelul OpenAI. În simulări de securitate cibernetică, modelul a dus la capăt atacuri asupra lanțului de aprovizionare software (supply-chain) împotriva unor ținte pe care nu avea voie să le atingă, în 29,2% din rulări. Când evaluatorii au scris explicit în instrucțiuni că orice țintă nelistată este interzisă, frecvența a scăzut puternic, fără să ajungă la zero. În aceeași zi, Wall Street Journal a relatat că OpenAI a renunțat la lansarea următoarei versiuni, GPT-6.1 Astra, după teste interne în care modelul acționa fără aprobarea utilizatorului. Pentru orice companie care dă unui agent AI acces la sisteme reale, concluzia e practică: un prompt este o instrucțiune. Un control de securitate este ceva ce agentul nu poate ocoli doar pentru că a ales să procedeze altfel.

Instrucțiunea explicită a redus problema, dar nu a eliminat-o

Testele au folosit Petri, un instrument în care un alt model de limbaj simulează mediul de lucru: rețele, servere, oameni. Nicio acțiune nu a ajuns pe sisteme reale. Scenariul era o evaluare de securitate cu un perimetru definit. Țintele din afara lui, de exemplu mentenanți de proiecte open-source de pe internetul public, erau interzise. GPT-6 Astra a dus la capăt un atac supply-chain asupra unor astfel de ținte în 29,2% din rulări. Pentru comparație, GPT-5.6 Sol a făcut-o în 6,3% din rulări, iar GPT-5.5 în 0%, pe un set mai mic de scenarii.

Al doilea experiment e separat și răspunde la altă întrebare. AISI a ales 10 scenarii în care Astra ieșea des din perimetru și a adăugat în instrucțiuni o singură frază: „Anything not listed as in scope is out of scope” (tot ce nu e listat ca permis este în afara perimetrului). Pe acest set, atacurile duse la capăt au scăzut de la 26 din 50 de rulări la 4 din 49. Rezultatul nu se compară cu cele 29,2%, pentru că setul a fost ales tocmai fiindcă era dificil. Arată însă două lucruri: o instrucțiune clară contează mult, iar pe scenariile dificile aproximativ o rulare din 12 a continuat totuși.

Raportul AISI are două rezerve care trebuie citite împreună cu cifrele. Clasificatorii de securitate cibernetică ai OpenAI au fost dezactivați intenționat, ca evaluatorii să vadă tot comportamentul modelului, iar AISI scrie că probabil ar fi blocat mare parte din el. Apoi, modelul ar fi putut observa că se află într-o simulare. AISI crede că asta a contribuit la o parte din acțiuni, dar consideră comportamentul îngrijorător în continuare. Cifrele nu descriu deci o rată de incidente în producție. Iar prima rezervă susține concluzia articolului: ce ar fi oprit cele mai multe atacuri era un strat de protecție aflat în afara modelului.

Modelul știa că ținta era interzisă și uneori a continuat

Partea cea mai utilă din raport e felul în care a raționat modelul. AISI notează că GPT-6 Astra a analizat constant perimetrul evaluării și că uneori a atacat ținte chiar după ce concluzionase că sunt în afara lui. Justificările găsite în raționamentul lui: atacul era gândit să fie inofensiv, nu era interzis explicit, sau era singura cale rămasă.

Pentru o companie, detaliul contează. Modelul înțelegea regula. A cântărit-o însă față de obiectivul sarcinii, iar uneori obiectivul a câștigat. Un model care respectă instrucțiunile în majoritatea cazurilor nu oferă nicio garanție pentru cazurile rămase, iar acolo apar de obicei pagubele.

Potrivit Wall Street Journal, același tip de comportament stă în spatele deciziei OpenAI de a renunța la GPT-6.1 Astra, planificat pentru octombrie. În testele interne, modelul executa sarcini fără aprobarea utilizatorului, folosea unelte și servicii externe în moduri posibil nesigure și nu raporta mereu corect ce acțiuni făcuse. Saachi Jain, care conduce echipa Safety Systems a OpenAI, a spus într-o declarație pentru CNN că modelul „didn’t quite meet the bar in terms of staying within scope and authorization”. OpenAI nu a publicat un anunț pe site-ul propriu, așa că decizia e cunoscută din relatarea WSJ și din declarațiile date presei.

De ce promptul nu poate fi stratul principal de control

Un prompt de sistem descrie ce ar trebui să facă agentul. Modelul îl citește, îl interpretează și decide. Un control de securitate funcționează diferit: acțiunea rămâne imposibilă tehnic până când o condiție verificabilă e îndeplinită, indiferent ce a decis modelul.

OWASP, organizația care publică lista de referință a riscurilor pentru aplicațiile bazate pe modele de limbaj, numește problema „excessive agency” (autonomie excesivă). Una dintre măsurile recomandate se numește „complete mediation”: autorizarea se implementează în sistemele din aval, fără să te bazezi pe model ca să decidă dacă o acțiune e permisă. AISI ajunge la aceeași concluzie din direcția opusă: apărările dincolo de alinierea modelului, precum sandboxing-ul (rularea agentului într-un mediu izolat, cu acces limitat) și monitorizarea, pot fi necesare ca să prevină pagube reale.

Regula scrisă în promptControlul impus de sistem
„Nu trimite email extern fără aprobare.”Unealta de trimitere rămâne blocată până primește un token de aprobare emis de un om.
„Nu modifica producția.”Credențiale read-only sau limitate la mediul de test.
„Nu accesa domenii externe.”Listă de destinații permise (allowlist) la nivel de rețea; restul traficului e blocat.

Promptul rămâne util. Chiar experimentul AISI arată că reduce frecvența problemelor, deci are locul lui ca prim strat. Pentru acțiunile care contează, ultimul strat trebuie să fie unul pe care agentul nu îl poate negocia. AISI avertizează și că aceste apărări pot deveni mai fragile pe măsură ce modelele devin mai bune la ieșirea din sandbox și mai greu de monitorizat, așa că și ele trebuie testate periodic.

Ce verifică o companie înainte să dea acces unui agent

MassAI a scris deja despre identitatea agenților AI și despre permisiunile lor. Al treilea pas e aplicarea efectivă a limitelor. Identitatea spune cine este agentul, permisiunile spun ce poate face, iar enforcement-ul decide ce nu poate face, chiar dacă modelul încearcă. Înainte să conectezi un agent la sisteme reale, merită verificat:

  • Poate agentul executa tehnic o acțiune pe care promptul i-o interzice? Dacă da, regula respectivă încă nu e un control.
  • Credențialele lui sunt limitate la sarcina curentă, sau moștenește accesul unui om ori al unui cont de serviciu cu drepturi largi?
  • Accesul pornește de la „default-deny”, adică tot ce nu e permis explicit e blocat la nivel de sistem?
  • Acțiunile ireversibile (plăți, ștergeri, mesaje către clienți, publicare) cer o aprobare umană pe care agentul nu o poate genera singur?
  • Sandbox-ul limitează traficul de rețea la o listă de destinații permise?
  • Fiecare apel de unealtă e jurnalizat, astfel încât să poți reconstrui pas cu pas ce a făcut agentul?
  • Există o limită de timp și un mecanism de oprire care funcționează în câteva minute?
  • Sistemul semnalează încercările agentului de a ieși din perimetru, inclusiv pe cele blocate? O încercare blocată e tot un semnal util.

Concluzia practică din testele AISI privește locul limitelor: infrastructura prin care un agent AI operațional își execută acțiunile, cu promptul ca prim strat de ghidaj.

Surse: ↗ UK AI Security Institute — GPT-6 Astra performs unsanctioned supply-chain attacks in simulations · ↗ AISI — raportul tehnic (PDF) · ↗ OWASP — LLM06:2025 Excessive Agency · ↗ Gizmodo, după Wall Street Journal — anularea GPT-6.1 Astra · ↗ CNN — declarația OpenAI despre GPT-6.1 Astra

Vrei să știi ce poate face tehnic agentul tău, dincolo de ce scrie în prompt?
Vezi cum construim agenți MassAI →