OpenAI Astra trece pragul cyber „Critical”: guvernanță înainte de accesul agenților

OpenAI raportează că Astra a obținut 100% pe ExploitBench și rate mai mari de execuție arbitrară de cod decât GPT-5.6 Sol pe un benchmark privat cu vulnerabilități high-severity dezvăluite recent. Compania spune că Astra a găsit două vulnerabilități necunoscute anterior în timpul evaluării și că acestea sunt în curs de divulgare către maintaineri.

În testări conduse de experți, OpenAI afirmă că modelul a construit un lanț de compromitere a browserului care a evadat din sandbox și un lanț pentru sistemul de operare care a escaladat un utilizator local fără privilegii la root. Sunt rezultate semnificative, raportate de furnizor. System card-ul complet nu este încă public, produsele afectate nu sunt numite cât timp disclosure-ul continuă, iar cercetători independenți nu au reprodus public evaluarea completă.

OpenAI precizează că rezultatele publicate pentru Astra reflectă accesul prin Daybreak Blue, nu configurația implicită din producție. Compania spune că accesul cyber avansat va începe cu un grup mic de testeri și va fi extins ulterior prin Daybreak Blue, în timp ce refuzurile, clasificatoarele, monitorizarea și controalele pentru conturi cu risc mai mare restricționează utilizarea.

OpenAI mai spune că a întârziat părți ale dezvoltării și lansării pentru a întări protecțiile și că safeguard-urile pot întrerupe uneori activitate defensivă legitimă sau task-uri lungi. Astra nu a fost implicat în incidentul anterior de evaluare Hugging Face. Compania afirmă însă că a folosit lecțiile acelui incident pentru izolarea, monitorizarea și controlul workload-urilor din clasa Astra.

• Înregistrează fiecare agent AI cu instrumente ca workload și identitate, cu responsabil nominal, scop aprobat și dată de expirare sau reevaluare
• Acordă permisiunile minime necesare în repository, rețea, cloud și execuție; evită accesul administrativ moștenit
• Separă mediile de evaluare, dezvoltare și producție și blochează căile nerestricționate către sistemele terților
• Definește limite explicite de autorizare pentru testarea vulnerabilităților și cere aprobare umană înaintea acțiunilor cu impact, disclosure-ului sau schimbărilor în producție
• Păstrează prompturile, apelurile către instrumente, aprobările, rezultatele și evenimentele de securitate proporțional cu riscul și nevoile de investigație
• Ține cheile API și credențialele în sisteme controlate de secrete, rotește-le după comportament anormal și nu introduce secrete reutilizabile direct în prompturi

• Ce capabilități există în nivelul de produs ales și ce rezultate de benchmark nu se aplică configurației implicite?
• Ce poate accesa, executa, modifica sau exfiltra agentul și ce control independent poate opri sau observa fiecare acțiune?
• Cum gestionează furnizorul false positive-urile, întreruperea task-urilor, enforcement-ul conturilor, notificarea incidentelor și accesul la dovezi?
• Putem reconstrui o sesiune a agentului după un incident fără să depindem exclusiv de telemetria furnizorului?
• Ce decizii de risc privind furnizorul, confidențialitatea, proprietatea intelectuală și NIS2 trebuie aprobate înainte de producție?

NIS2 nu devine o certificare automată a produsului când un model trece un prag intern de capabilitate. Munca relevantă a organizației este managementul riscului: inventarul activelor și furnizorilor, controlul accesului, dezvoltarea sigură, gestionarea vulnerabilităților, procedurile de incident, continuitatea și supravegherea conducerii, proporționale cu serviciul care folosește agentul.

Awarely Monitor poate lega vulnerabilitățile și constatările tehnice privind AI de active, responsabili, termene și dovezi de verificare. Awarely Learning poate exersa cu dezvoltatorii, securitatea și managementul deciziile de autorizare și escaladare, iar Secretus poate proteja credențialele și transferurile sensibile din incident. Împreună susțin dovezile de guvernanță fără să înlocuiască protecțiile furnizorului AI, evaluarea independentă sau analiza juridică.