Prompt injection în companie: cum poate un document malițios să preia controlul unui agent AI?

Google Adaugă-ne ca sursă preferată în Google
Prompt injection în companie: cum poate un document malițios să preia controlul unui agent AI?
Prompt injection document malițios agent AI companie / foto: reprezentare AI

Într-o companie în care documentele circulă zilnic între angajați, furnizori și clienți, un fișier care ajunge pe masa unui asistent digital pare o parte firească a muncii. Poate fi o ofertă, un contract sau un raport pe care nimeni nu mai are timp să îl citească integral. Tocmai această delegare creează însă o problemă de securitate: materialul oferit pentru analiză poate conține instrucțiuni scrise de cineva care urmărește un rezultat complet diferit de cel cerut de angajat.

Riscul devine mai serios când asistentul este un agent AI, adică un sistem capabil să folosească aplicații și să execute acțiuni. Un rezumat greșit poate induce în eroare. Un agent conectat la e-mail, documente interne și baze de date poate transforma aceeași manipulare într-o divulgare de informații sau într-o modificare neautorizată. Atacul numit prompt injection exploatează felul în care modelul interpretează conținutul, iar amploarea pagubei depinde de permisiunile pe care compania i le-a acordat.

Cum ajunge un document să fie tratat ca o comandă

Prompt injection apare când un text introdus în interacțiunea cu modelul reușește să îi modifice comportamentul într-un mod nedorit. Varianta indirectă presupune că instrucțiunea vine dintr-o sursă pe care agentul o consultă în timpul unei sarcini legitime. Angajatul cere analiza unui contract, iar contractul încearcă să dicteze cum trebuie făcută analiza sau ce alte operațiuni trebuie executate. Persoana care a formulat cererea inițială poate să nu observe deloc intervenția.

Un scenariu ipotetic arată de ce această diferență contează. Un agent din departamentul de achiziții compară ofertele primite de la mai mulți furnizori. Într-un document, atacatorul introduce un pasaj care pretinde că, pentru verificarea compatibilității, trebuie consultate și centralizate contractele existente. Agentul ar putea interpreta pasajul drept o etapă necesară a sarcinii, deși autorul ofertei nu are nicio autoritate asupra documentelor interne ale companiei.

Instrucțiunile nu trebuie să fie spectaculoase sau evidente. Pot fi ascunse în text cu contrast redus, în comentarii sau în alte elemente pe care procesul de extragere le trimite modelului. Uneori sunt vizibile și par o simplă notă administrativă. Contează ce conținut ajunge efectiv în contextul AI, nu doar ce vede omul în pagina deschisă pe ecran. Un fișier aparent banal poate avea reprezentări diferite pentru cititor și pentru aplicația care îl procesează.

Nici documentele interne nu sunt automat sigure. Un material extern poate fi copiat într-o bază de cunoștințe, iar un cont compromis poate modifica o pagină folosită ulterior de agent. Locul în care este păstrat textul nu dovedește că fiecare propoziție din el reprezintă o instrucțiune autorizată. Proveniența, drepturile autorului și scopul pentru care informația este consultată rămân relevante chiar după mutarea fișierului în infrastructura companiei.

Modelul nu se comportă ca un program care acceptă comenzi numai într-un câmp dedicat. El interpretează limbajul, relațiile dintre mesaje și contextul sarcinii. Această flexibilitate îi permite să înțeleagă documente eterogene, dar poate fi exploatată prin conținut care imită o regulă, un mesaj al administratorului sau o explicație necesară continuării lucrului. NCSC, autoritatea britanică de securitate cibernetică, avertizează că analogia cu vulnerabilitățile SQL injection poate produce o falsă încredere în soluții de filtrare.

Din acest motiv, eliminarea unei expresii precum „ignoră instrucțiunile anterioare” nu rezolvă întreaga problemă. Un atac poate evita formula și poate convinge agentul că o operațiune nepotrivită servește chiar obiectivului legitim. Un document poate invoca o verificare obligatorie, o urgență sau o eroare de proces. În aceste situații, dificultatea este evaluarea autorității textului și a acțiunii cerute, nu identificarea unui cuvânt interzis.

Riscul poate apărea și când agentul reia o sarcină mai veche. O notă generată anterior poate păstra o recomandare contaminată, iar o etapă ulterioară o poate trata drept concluzie deja verificată. Dacă proiectezi un flux cu mai multe etape, păstrează legătura dintre informație și sursa ei. Trecerea printr-un rezumat automat nu trebuie să transforme conținutul unui furnizor într-o regulă internă sau într-o aprobare pentru o acțiune nouă.

De ce permisiunile agentului stabilesc amploarea pagubei

Expresia „preia controlul” descrie aici deturnarea comportamentului agentului, fără să însemne obligatoriu control total asupra calculatorului sau infrastructurii. Dacă aplicația poate doar să citească un document și să genereze un răspuns, atacul ar putea contamina concluziile. Dacă poate căuta în arhive, trimite mesaje și modifica înregistrări, consecințele posibile se extind. O instrucțiune malițioasă nu creează singură drepturi de acces, dar poate încerca să folosească abuziv drepturile existente.

Revenind la exemplul achizițiilor, diferența dintre două configurații este decisivă. În prima, agentul vede numai ofertele încărcate pentru comparație. În a doua, folosește contul unui angajat și poate consulta întreaga arhivă contractuală. Același document manipulator întâlnește suprafețe de atac foarte diferite. O companie care acordă acces general pentru a evita configurarea permisiunilor poate transforma o sarcină restrânsă într-o expunere mult mai mare.

Divulgarea datelor este una dintre consecințele importante, dar nu singura. Un agent poate produce o recomandare comercială părtinitoare, poate omite clauze dezavantajoase sau poate introduce informații false într-un raport. Un rezultat care arată bine și respectă formatul cerut poate rămâne compromis. Într-un flux în care oamenii verifică doar dacă documentul este complet, manipularea conținutului poate trece neobservată mai ușor decât o eroare tehnică evidentă.

Conectarea mai multor instrumente creează și riscuri prin combinație. Accesul la documente permite citirea informațiilor, iar accesul la e-mail permite comunicarea lor. Fiecare funcție poate părea rezonabilă separat, însă folosirea lor în aceeași sesiune poate produce un traseu de divulgare. Evaluarea securității trebuie să urmărească ce poate face întregul sistem, inclusiv aplicațiile conectate, nu numai comportamentul modelului în conversații fără instrumente.

Există și o problemă de identitate. Când agentul folosește acreditările persoanei care îl operează, acțiunile pot părea efectuate direct de aceasta. Jurnalele trebuie să permită reconstruirea delegării și a operațiunilor executate automat. Proiectele NIST privind identitatea și autorizarea agenților AI reflectă această nevoie de control distinct: dreptul utilizatorului de a accesa o informație nu echivalează cu permisiunea agentului de a o folosi în orice scop sugerat de un document.

Ce protecții pot reduce riscul în practică

Prima protecție utilă este restrângerea accesului la ceea ce cere sarcina. Dacă ai un agent pentru analiza ofertelor, limitează documentele pe care le poate consulta și operațiunile pe care le poate executa. Separă lectura de modificare și de trimiterea informațiilor în exterior. Drepturile acordate preventiv, pentru eventuale nevoi viitoare, măresc consecințele unei deturnări înainte să aducă un beneficiu demonstrat în activitatea curentă.

Autorizarea acțiunilor sensibile trebuie verificată și prin reguli ale aplicației, independente de răspunsul modelului. Un agent poate propune trimiterea unui document, dar sistemul care execută operațiunea poate verifica destinatarul, clasificarea datelor și aprobarea necesară. Dacă modelul este păcălit, aceste controale pot opri acțiunea. O interdicție scrisă numai în instrucțiunile AI oferă un tip de protecție diferit de o restricție aplicată efectiv în serviciul de e-mail.

Confirmarea umană are valoare când arată concret ce urmează să se întâmple. Dacă trebuie să aprobi o trimitere, verifică destinatarul și materialul transmis, nu doar un mesaj vag despre continuarea sarcinii. Pentru o modificare, diferența dintre versiunea veche și cea nouă trebuie să fie vizibilă. O succesiune de aprobări generice poate crea oboseală și poate încuraja acceptarea mecanică a unor acțiuni pe care utilizatorul nu le mai examinează.

Filtrele pentru conținut suspect, delimitarea surselor și instruirea modelului să ignore comenzile din documente pot reduce probabilitatea unui atac reușit. OWASP recomandă o combinație de măsuri, iar Microsoft descrie protecții care includ atât detectarea, cât și limitarea efectelor. Niciun filtru nu trebuie presupus infailibil. Formulări noi, documente lungi sau instrucțiuni distribuite în mai multe surse pot pune la încercare mecanismele care funcționează bine în exemple simple.

Evaluarea trebuie făcută în configurația reală a agentului. NIST subliniază importanța testelor adaptate sistemului și a încercărilor repetate, deoarece rezultatul agregat poate ascunde sarcini vulnerabile. Dacă testezi numai conversații fără acces la aplicații, nu afli suficient despre riscul unui agent conectat la arhiva internă. Folosește date fictive și verifică dacă sistemul respectă limitele când întâlnește conținut manipulator, inclusiv după actualizări sau adăugarea unor instrumente.

Cum gestionezi incidentul și responsabilitatea în companie

O suspiciune de prompt injection merită investigată în funcție de ceea ce agentul a făcut efectiv. Un răspuns contaminat, o încercare blocată de trimitere și o divulgare confirmată sunt situații diferite. Dacă observi comportamente neobișnuite, oprește fluxul afectat și păstrează documentul, configurația și jurnalele relevante. Întreruperea temporară a automatizării poate limita expunerea, însă concluziile despre incident cer verificarea operațiunilor executate și a datelor accesate.

Un plan intern ar trebui să stabilească cine poate revoca accesul agentului, cine examinează acțiunile și cine coordonează comunicarea. Documentul malițios poate rămâne într-o arhivă și poate fi consultat din nou de altă automatizare. Dacă îl elimini dintr-un singur flux, verifică și copiile sau indexurile folosite de alte sisteme. Recuperarea presupune atât limitarea efectelor deja produse, cât și oprirea traseului care a permis reapariția instrucțiunilor.

Responsabilitatea nu poate fi rezolvată prin simpla afirmație că „AI a decis”. Compania a ales aplicația, a definit sarcina și a acordat accesul, iar furnizorul are propriile obligații contractuale și tehnice. Stabilirea răspunderii juridice depinde de incident și de cadrul aplicabil. Operațional, însă, este util să existe un responsabil pentru configurația agentului și un proces clar prin care permisiunile sunt revizuite pe măsură ce utilizarea se schimbă.

Pentru o organizație, întrebarea relevantă este dacă un document venit din exterior poate determina o acțiune pe care autorul lui nu are dreptul să o solicite. Un răspuns credibil cere mai mult decât demonstrația că asistentul refuză câteva comenzi suspecte. Cere acces limitat, controale aplicate în instrumente și posibilitatea de a verifica ce s-a întâmplat. Agenții AI devin mai utili când primesc autonomie, dar această autonomie rămâne sigură numai în limite pe care documentele consultate nu le pot rescrie.