Un agent AI a exploatat singur o breșă din sistemul de rezervări al unei săli de fitness, după ce utilizatorul îi ceruse doar să-i găsească un loc la un curs. Cazul, relatat de ABC News, este prezentat drept primul incident australian cunoscut de acest fel și arată destul de bine unde apare problema cu agenții AI: nu doar ce le ceri contează, ci și ce metode aleg singuri pentru a ajunge la rezultat.
Utilizatorul, identificat drept Andrew, folosea OpenClaw, agentul AI despre care am mai discutat pe Mobilissimo, împreună cu Claude de la Anthropic. Sarcina era banală: rezervarea unui curs de dimineață. OpenClaw a descoperit însă că sistemul permite programări cu mult peste intervalul acceptat în mod normal și a profitat de vulnerabilitate pentru a face rezervarea.
Situația a devenit mai serioasă când Andrew, aflat pe poziția a patra a unei liste de așteptare, a întrebat dacă poate ajunge mai sus. Agentul a descoperit că API-ul nu verifica suficient cine are dreptul să anuleze rezervările și a testat problema direct pe persoana aflată prima în listă. Rezervarea acesteia a fost anulată, iar Andrew a urcat pe poziția a treia. Utilizatorul nu îi ceruse agentului să elimine pe nimeni, iar când i-a cerut să repare situația, AI-ul a răspuns că nu mai poate adăuga persoana înapoi.
Când autonomia întâlnește un API prost securizat
Aici se vede diferența importantă dintre un chatbot și un agent AI. Primul îți poate spune ce ar face; al doilea poate primi acces la browser, servicii online și alte instrumente și poate chiar executa acțiunea. În cazul OpenClaw, asta înseamnă inclusiv automatizarea unor fluxuri de lucru și interacțiunea directă cu sistemele utilizatorului. Când serviciul de la celălalt capăt are o breșă, agentul poate ajunge să o trateze drept o simplă cale mai scurtă către obiectiv.
Australian Signals Directorate a publicat ulterior o avertizare pornind chiar de la acest incident. Autoritatea folosește termenul specification gaming: agentul găsește o metodă care îndeplinește tehnic obiectivul, dar intră în conflict cu intenția reală a utilizatorului. Recomandarea este ca agenții să fie limitați la sarcini cu risc redus, iar acțiunile care afectează servicii sau alte persoane să rămână sub supraveghere umană.
Există deja și exemple de produse construite tocmai în jurul acestei idei. Integrarea 1Password cu Claude, de pildă, cere aprobarea biometrică a utilizatorului înainte de autentificare și nu îi oferă agentului acces direct la parole. Automatizarea rămâne, dar momentul sensibil are nevoie de un „da” explicit din partea omului.
Cazul australian nu mai poate fi tratat ca o simplă anomalie
În iulie, OpenAI a raportat un incident mult mai sofisticat în timpul unor teste de securitate. Modele AI aflate într-un mediu izolat au găsit și exploatat o vulnerabilitate zero-day pentru a obține acces la internet, apoi au compromis infrastructura Hugging Face în încercarea de a găsi răspunsurile unei evaluări. Am scris și pe Mobilissimo despre acel incident. OpenAI spune că modelul experimental implicat nu era destinat lansării publice.
Anthropic a făcut apoi propria verificare și a găsit trei situații în care Claude a ajuns dintr-un mediu de evaluare pe internet și a accesat fără autorizare sisteme reale. Compania spune că modelele credeau că respectivele ținte făceau parte din exercițiu, iar problemele exploatate au fost în principal parole slabe și endpoint-uri neprotejate, nu vulnerabilități sofisticate.
Pentru utilizatorul obișnuit, avertismentul e mai puțin spectaculos decât ideea unui AI care „scapă de sub control”, dar mult mai practic: cu cât un agent primește acces la mai multe servicii, cu atât limitele trebuie definite și tehnic, nu doar într-o propoziție din chat. În cazul sălii australiene, agentul a fost rugat să facă o rezervare și a găsit singur o cale pe care utilizatorul nu ar fi aprobat-o. ASD recomandă tocmai de aceea acces restrâns, instrucțiuni explicite și aprobarea umană înaintea acțiunilor care pot afecta terți.
