Prompt injection la chatboturile pentru site-uri web: Protecție pentru RAG, instrumente și date

Un chatbot pentru site-uri web nu procesează doar întrebări inofensive. Vizitatorii pot încerca să-i rescrie regulile, să dezvăluie instrucțiuni interne sau să declanșeze acțiuni neautorizate. Și mai greu de detectat sunt comenzile care nu se află direct în chat, ci sunt ascunse într-o pagină web explorată (crawlată), într-un document încărcat sau într-un sistem terț conectat.

Oricine dorește să limiteze prompt injection la chatboturile web nu se poate baza doar pe un prompt de sistem formulat deosebit de strict. Este necesară o arhitectură pe mai multe niveluri: introducerile și sursele sunt tratate ca fiind nesigure, permisiunile sunt restricționate tehnic, ieșirile sunt verificate înainte de procesarea ulterioară, iar acțiunile riscante sunt confirmate de un cod deterministic sau de un om.

Ce înseamnă prompt injection la un chatbot web

OWASP descrie prompt injection ca fiind o introducere care modifică neintenționat comportamentul sau ieșirea unui model de limbaj. Un atac de tip prompt injection direct vine direct de la utilizator, de exemplu ca o solicitare de a ignora regulile anterioare. Un atac de tip prompt injection indirect este ascuns în conținuturi externe pe care sistemul le preia ulterior: pagini web, documente de cunoștințe, e-mailuri, date despre produse sau fișiere.

Această distincție este importantă pentru administratorii de site-uri web. Un chatbot dedicat exclusiv întrebărilor frecvente (FAQ) are o suprafață de atac mai mică decât un sistem care explorează continuu pagini web, caută în documente interne, citește date CRM sau poate executa funcții. Generarea augmentată prin recuperare (Retrieval-Augmented Generation sau RAG) îmbunătățește baza de cunoștințe a răspunsurilor, dar nu elimină riscul de injection. Chiar și o bază de surse bine întreținută poate conține instrucțiuni manipulate sau interpretate greșit.

Evaluarea riscului după funcții, nu după numele modelului

Întrebarea decisivă nu este doar „Ce model folosim?”, ci „Ce impact poate avea un răspuns manipulat?”. Creați o hartă simplă a funcțiilor și datelor pentru chatbot:

• Ce surse publice și interne are voie să citească?
• Ce date cu caracter personal, confidențiale sau critice pentru afacere sunt accesibile?
• Poate genera doar text sau poate de asemenea să creeze tichete, lead-uri, e-mailuri, programări sau comenzi?
• Ce acțiuni modifică sistemele externe?
• Ce decizii sunt preluate automat, fără ca un om să le verifice?

Cu cât drepturile de citire, drepturile de scriere și gradul de automatizare sunt mai mari, cu atât devin mai importante limitele tehnice din afara modelului. Sinteza existentă privind greșelile frecvente ale chatboturilor IA vă ajută la evaluarea generală. Pentru prompt injection, trebuie să documentați în plus fluxurile de date, limitele de încredere și drepturile de acțiune.

Delimitarea clară a patru zone de încredere

Un model practic de securitate distinge patru zone, chiar dacă din punct de vedere tehnic acestea sunt procesate în aceeași aplicație.

Zona 1: Reguli de sistem și politici

Aici sunt definite rolul, scopul permis, limitele răspunsurilor și regulile de escaladare. Aceste reguli oferă ghidaj modelului, dar nu reprezintă un control de acces de încredere. OWASP avertizează în mod expres împotriva tratării prompturilor de sistem ca un secret sau mecanism de securitate. Datele de autentificare, cheile de conexiune și informațiile interne sensibile nu au ce căuta aici.

Zona 2: Date introduse de vizitatori

Fiecare mesaj din chat este considerat nesigur. Limitați lungimea, tipurile de fișiere și funcțiile permise; normalizați datele introduse pentru procesarea tehnică și marcați-le clar în prompt ca date ale utilizatorului. Un filtru poate detecta tipare de atac cunoscute, dar nu trebuie să blocheze la grămadă întrebările legitime. Un vizitator care întreabă despre „ignore previous instructions” într-o documentație de securitate poate avea o solicitare legitimă.

Zona 3: Surse preluate și context RAG

De asemenea, conținutul explorat, fișierele PDF și rezultatele serviciilor externe rămân date, nu instrucțiuni. Separați vizibil conținutul acestora de contextul de control, salvați originea și momentul preluării și permiteți doar sursele aprobate. Articolul despre menținerea la zi a bazei de cunoștințe a chatbotului IA arată cum interacționează inventarul surselor, frecvența de explorare și procesul de QA.

Zona 4: Instrumente, acțiuni și ieșiri

Apelurile de funcții nu trebuie executate doar pentru că modelul generează un text corespunzător. Un controller deterministic verifică numele funcției, parametrii, permisiunile, contextul sesiunii și sistemele țintă permise. Ieșirile modelului care sunt utilizate ulterior ca HTML, Markdown, SQL, cale de fișier sau parametri API au nevoie de validarea și codificarea adecvate contextului respectiv.

Principiul cel mai mic privilegiu limitează impactul

În prezent, prompt injection nu poate fi exclus în mod fiabil printr-o singură măsură. De aceea, aplicația trebuie construită astfel încât o încercare de manipulare reușită să aibă un impact cât mai redus. OWASP și Microsoft recomandă în acest scop principiul celui mai mic privilegiu (Least Privilege).

• Utilizați identități tehnice separate pentru citire și scriere.
• Acordați acces doar la datele necesare pentru scopul concret al chatbotului.
• Limitați funcțiile la scheme de parametri mici și clar definite.
• Folosiți permisiuni cu durată scurtă de viață dacă o acțiune are nevoie de ele.
• Solicitați o confirmare explicită pentru pașii riscanți sau ireversibili.
• Nu lăsați niciodată autorizarea pe seama textului liber al modelului.

Un chatbot de suport poate, de exemplu, să pregătească o schiță de tichet, dar nu ar trebui să stabilească automat destinatari, priorități sau drepturi de acces interne arbitrare. Un chatbot de colectare de lead-uri poate primi date de contact structurate fără a obține drepturi de citire asupra întregului CRM.

Verificarea și izolarea surselor RAG

Atacurile indirecte de prompt injection transformă fluxul de surse într-o parte a arhitecturii de securitate. O pagină manipulată poate părea inofensivă din punct de vedere vizual și totuși să conțină text pe care un model îl interpretează ca pe o instrucțiune. În cazul sistemelor multimodale, imaginile sau alte formate de fișiere pot juca de asemenea un rol.

De aceea, introduceți un flux de intrare a surselor cu reguli de aprobare: domenii și secțiuni de documente permise, proprietari trasabili, versionare, verificări malware și de fișiere, precum și o revizuire pentru conținuturile noi sau modificate neobișnuit. Marcați pasajele preluate în contextul modelului ca fiind în mod explicit untrusted content (conținut nesigur). Un rezultat al căutării poate furniza informații, dar nu trebuie să modifice regulile de sistem sau permisiunile instrumentelor.

De asemenea, verificați dacă răspunsul este într-adevăr susținut de surse. Ghidul privind calitatea răspunsurilor chatbotului IA cu Golden Set și teste RAG descrie fundamentarea (groundedness) și compararea cu sursele. Această verificare a calității completează controalele de securitate, dar nu le înlocuiește.

Filtrele de intrare și ieșire sunt un nivel de protecție, nu întreaga soluție

Serviciile specializate de protecție pot detecta încercările de atac directe și indirecte. De exemplu, Microsoft Prompt Shields distinge atacurile din datele introduse de utilizator de instrucțiunile ascunse din documente. În ghidul său de securitate, Google recomandă de asemenea măsuri de protecție împotriva prompt injection, sarcini mai restrânse, identificatori de utilizator, limite de volum și supraveghere umană în cazul riscurilor mai mari.

Astfel de filtre oferă semnale probabilistice. Prin urmare, planificați un comportament în trepte: blocare, răspuns sigur, comutare la un mod restrâns sau transfer către un operator uman. Jurnalizați clasa deciziei și versiunea tehnică, dar evitați stocarea inutilă a textului integral. În cazul datelor cu caracter personal, se aplică în plus domeniile de verificare descrise în articolul despre chatboturile IA și GDPR. Acest articol nu constituie consultanță juridică.

Validarea ieșirilor modelului înainte de procesarea ulterioară

Datele de intrare sigure nu garantează o ieșire sigură. OWASP include manipularea necorespunzătoare a ieșirilor ca un risc separat: textul generat de model poate ajunge ulterior în HTML, scripturi, interogări de bază de date sau căi de fișiere. De aceea, tratați de asemenea fiecare ieșire a modelului ca fiind inițial nesigură.

Solicitați un format structurat strict pentru fluxurile automatizate și validați-l în raport cu o schemă. Utilizați liste albe (allowlists) pentru numele funcțiilor și sistemele țintă. Codificați textul vizibil pentru contextul de ieșire respectiv. Eliminați câmpurile neașteptate, URL-urile externe și parametrii din afara valorilor permise. Datele sensibile ar trebui să treacă din nou printr-o verificare proprie a politicilor înainte de afișare sau transmitere.

Testarea prompt injection cu un set de teste de securitate

Completați setul Golden de bază cu cazuri de testare de tip adversarial. Testele trebuie să verifice sistemul real din producție, inclusiv procesele de recuperare (retrieval), instrumentele și logica permisiunilor, nu doar modelul de bază. Un set util include:

• încercări directe de a înlocui regulile sau de a solicita instrucțiuni interne;
• variante multilingve, codificate și distribuite în mai multe mesaje;
• întrebări de specialitate inofensive care conțin cuvinte cheie similare și nu trebuie blocate eronat;
• pasaje manipulate într-o sursă de cunoștințe de test;
• nume de funcții neautorizate, parametri suplimentari și adrese țintă străine;
• încercări de a afișa date confidențiale sau conținutul sesiunilor anterioare;
• teste pentru ieșiri HTML, Markdown și linkuri;
• căi de anulare, transfer (handoff) și confirmare pentru acțiunile riscante.

Nu măsurați doar dacă un filtru se declanșează. Verificați rezultatul final: A fost împiedicată o acțiune neautorizată? Datele confidențiale au rămas protejate? A funcționat în continuare o solicitare legitimă? A fost jurnalizat transparent un caz suspect?

Plan practic de implementare pentru echipele web

1. Stabilirea domeniului de aplicare: Documentați sursele de date, instrumentele, drepturile de scriere și țintele externe.
2. Separarea zonelor de încredere: Marcați tehnic regulile de sistem, datele introduse de utilizatori, conținutul RAG și ieșirile acțiunilor.
3. Reducerea drepturilor: Eliminați accesările neutilizate și împărțiți acțiunile de scriere în funcții mici.
4. Adăugarea validării: Introduceți limite de intrare, ieșiri structurate, liste albe și codificare specifică contextului.
5. Stabilirea confirmării: Securizați acțiunile riscante și fluxurile de date sensibile prin intervenție umană (Human-in-the-Loop).
6. Rularea setului de teste: Verificați cazurile de control directe, indirecte și legitime înainte de fiecare lansare relevantă.
7. Monitorizarea funcționării: Revizuiți în mod regulat evenimentele filtrelor, acțiunile respinse, modificările neobișnuite de surse și alarmele false.

Listă de verificare: Protecție împotriva prompt injection

• Promptul de sistem nu conține secrete și nu înlocuiește autorizarea.
• Textul utilizatorului și sursele externe sunt considerate nesigure în mod implicit.
• Sursele RAG au aprobare, origine, versiune și proprietari responsabili.
• Instrumentele respectă principiul celui mai mic privilegiu și acceptă doar parametri validați.
• Acțiunile riscante necesită o confirmare verificabilă.
• Ieșirile modelului sunt verificate înainte de HTML, API, CRM sau alte sisteme țintă.
• Filtrele de securitate sunt evaluate luând în calcul falsurile pozitive și falsurile negative.
• Testele de atac direct și indirect sunt executate regulat și după fiecare modificare.

Concluzie

Prompt injection nu este o simplă problemă de prompt engineering. Pentru chatboturile web, o protecție rezistentă apare doar atunci când aplicația tratează introducerile, sursele, ieșirile și acțiunile ca zone de încredere separate. Filtrele pot detecta atacurile, însă principiul celui mai mic privilegiu, validarea deterministică și confirmarea umană sunt cele care limitează efectele posibile.

Începeți cu harta funcțiilor și datelor pentru chatbotul dumneavoastră. Eliminați drepturile inutile, izolați conținutul RAG și testați întregul parcurs până la acțiunea externă. Astfel, chatbotul rămâne util, fără ca textul liber generat de model să decidă asupra permisiunilor sau modificărilor critice pentru afacere.

Surse

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance