Securizarea apelurilor de instrumente ale chatbotului AI: Drepturi, confirmare și cale de rollback

Un chatbot pentru un site web se schimbă fundamental de îndată ce nu doar răspunde, ci are voie să declanșeze acțiuni. O solicitare de programare este încă ușor de gestionat. O anulare a unei programări, o modificare de adresă sau o rambursare schimbă însă starea reală a afacerii. Modelul de limbaj are voie să propună un apel de instrument (tool call) potrivit. Cu toate acestea, dacă acțiunea este permisă sau nu, trebuie să decidă un strat de aplicație separat, deterministic. Prin urmare, apelurile securizate de instrumente ale unui chatbot AI nu apar în urma unui system prompt deosebit de strict, ci prin funcții limitate, verificarea drepturilor pe server, o confirmare ușor de înțeles și o cale de executare controlată.

De ce un model de limbaj bun nu înlocuiește autorizarea

Un model lucrează cu probabilități. Poate înțelege greșit o intenție, poate adăuga un parametru sau poate reacționa la conținut manipulat. Descrierea riscurilor OWASP privind Excessive Agency menționează trei cauze tipice: prea multă funcționalitate, permisiuni prea extinse și prea multă autonomie. Prin urmare, problema nu este doar o introducere de date rău-intensionată. Chiar și o solicitare ambiguă sau o eroare plauzibilă a modelului poate pregăti o acțiune nedorită.

Prin urmare, cea mai importantă regulă de arhitectură este: modelul formulează o propunere, dar aplicația o autorizează și o execută. Un apel de instrument precum cancelAppointment este la început doar o intenție structurată. Abia o verificare de politică (policy check) verifică utilizatorul, tenant-ul, obiectul, acțiunea permisă, starea actuală și confirmarea necesară. Această separare completează protecția împotriva Prompt Injection la chatboturile pentru site-uri web; ea rămâne necesară chiar și atunci când nu a fost detectat niciun atac.

Clasificarea fiecărui instrument după efect, nu după nume

Echipele nu ar trebui să clasifice întregul chatbot în mod paușal ca fiind „sigur” sau „critic”. Decisiv este efectul fiecărui instrument în parte. O matrice simplă de risc oferă claritate:

• Lectură și puțin sensibil: Preluarea programului de lucru sau a informațiilor despre produse disponibile public.
• Lectură și date cu caracter personal: Afișarea stării unei comenzi sau a datelor clienților; pentru aceasta trebuie verificate identitatea, tenant-ul și legătura cu obiectul.
• Scriere, dar ușor reversibilă: Crearea unei solicitări interne de reapelare sau adăugarea unei note neobligatorii.
• Cu consecințe sau greu reversibilă: Anularea unei rezervări, modificarea datelor de contact, publicarea de conținut, trimiterea de mesaje sau inițierea de plăți.

Din această clasă rezultă drepturile, nivelul de confirmare, limitele și jurnalizarea (logging-ul). O aprobare paușală „Chatbotul are voie să folosească CRM-ul” este prea vagă. Mai bună este o listă de capacități concrete, cu parametri definiți și tranziții de stare permise.

Least Privilege începe cu delimitarea funcțiilor

OWASP Authorization Cheat Sheet recomandă principiul Least Privilege și Deny by Default. Pentru apelurile de instrumente, acest lucru înseamnă: un chatbot primește doar funcția și fragmentul de date care sunt necesare pentru pasul respectiv.

Instrumente mici în loc de interfețe universale

Un instrument getOrderStatus(orderId) este mai ușor de securizat decât un acces deschis la o bază de date. Un instrument requestCallback(topic, timeWindow) este mai ușor de controlat decât o funcție generală pentru trimiterea de mesaje arbitrare. Funcțiile libere de SQL, shell, URL sau e-mail măresc inutil impactul potențial. De asemenea, instrumentele de testare care nu mai sunt necesare ar trebui să dispară din catalogul de producție.

Executarea în contextul utilizatorului autentificat

Backend-ul nu trebuie să se bazeze doar pe faptul că modelul transmite ID-ul corect al clientului. Trebuie să deducă utilizatorul și tenant-ul actual din sesiunea de încredere și să verifice din nou pentru fiecare obiect dacă există acces. Diferența practică dintre chatul public și zona protejată este explicată în detaliu în articolul despre identitate și accesul la date în portalul pentru clienți. Un cont general de serviciu cu acces complet este de obicei scurtătura greșită pentru acțiunile legate de utilizatori.

Validarea deterministă a parametrilor

Parametrii instrumentelor au nevoie de o schemă strictă: câmpuri permise, tipuri, lungimi, domenii de valori și reguli de stare. Un ID de programare trebuie să aparțină utilizatorului, o dată trebuie să fie într-un interval permis, iar o acțiune trebuie să se potrivească cu starea actuală. Câmpurile necunoscute sunt respinse. De asemenea, aplicația ar trebui să se asigure că numele instrumentului provine dintr-o listă permisă (allowlist) fixă și nu este executat dintr-un text generat liber.

Confirmarea trebuie să arate acțiunea reală

În cazul modificărilor cu consecințe majore, întrebarea „Sunteți sigur?” nu este suficientă. Ghidul OWASP privind autorizarea tranzacțiilor descrie principiul „What You See Is What You Sign”: utilizatorii ar trebui să poată recunoaște și confirma datele esențiale ale acțiunii concrete. Pentru un chatbot de pe un site web, acest lucru înseamnă, de exemplu:

• „Anulare programare pe 18 august la ora 14:30” în loc de „Confirmă modificarea”
• „Schimbă adresa de livrare pentru comanda ...84 în Viena” în loc de „Salvează datele”
• „Creează o solicitare de reapelare cu tema Factură” în loc de „Trimite solicitarea”

Confirmarea este legată pe partea de server exact de această schiță de acțiune. Dacă se schimbă destinația, suma, data, destinatarul sau alți parametri esențiali, aceasta expiră. Primește o perioadă scurtă de valabilitate și nu poate fi reutilizată pentru o a doua acțiune. Pentru operațiuni deosebit de critice, poate fi necesară suplimentar o reautentificare sau o aprobare din partea unui om. Modelul nu are voie să sară peste acest pas și nici să îl înlocuiască cu un răspuns formulat liniștitor.

Planificarea idempotenței, a limitelor și a căii de rollback

Chiar și un apel de instrument autorizat corect poate sosi dublat din punct de vedere tehnic: browserul repetă o solicitare, un timeout declanșează o reîncercare (retry) sau utilizatorul trimite din nou același mesaj. Instrumentele de scriere ar trebui de aceea să folosească un ID de idempotență pe server. Pentru același ID, aceeași acțiune este executată cel mult o singură dată; o reîncercare primește rezultatul deja cunoscut.

În plus, fiecare instrument are nevoie de limite adecvate: apeluri maxime pe sesiune, timeout-uri scurte, reîncercări limitate și o întrerupere în cazul unor lanțuri neobișnuite. Înainte de executare, backend-ul verifică din nou starea. Astfel, o rezervare deja anulată nu este procesată a doua oară. Acolo unde este posibil, o acțiune trebuie creată mai întâi ca schiță sau comandă rezervată. Pentru modificările directe inevitabile, trebuie să fie clar cum sunt acestea compensate, revocate sau predate unei echipe de suport. Un Degraded Mode și un plan de rollback pregătite previn necesitatea de a improviza în caz de defecțiune.

Jurnalizarea fără colectarea de secrete

Un jurnal de securitate ar trebui să poată răspunde cine, ce acțiune, pe ce bază a aprobat și cu ce rezultat a executat. Sunt utile un ID de actor pseudonimizat, instrumentul și versiunea, referința obiectului, versiunea politicii, decizia de autorizare, ID-ul de confirmare, ID-ul de idempotență, momentul și rezultatul. Parolele, tokenurile, istoricul complet al chatului și conținutul inutil cu caracter personal nu își au locul în acest jurnal.

OWASP AI Agent Security Cheat Sheet recomandă date structurate de decizie pentru acțiunile cu risc ridicat și o separare între decizie și executare. Acesta este un lucru diferit față de tracing-ul tehnic complet: pentru auditul de securitate contează o dovadă scurtă și solidă a lanțului de aprobare. Stocarea și accesul ar trebui să se orienteze după necesitatea reală de verificare.

O arhitectură robustă în cinci straturi

1. Dialog și propunere: Modelul recunoaște intenția și generează o schiță structurată de acțiune, dar nu execută nimic direct.
2. Decizia de politică: O componentă deterministă verifică allowlist-ul instrumentului, utilizatorul, tenant-ul, obiectul, parametrii, clasa de risc și limitele.
3. Confirmare: Interfața arată datele esențiale ale acțiunii. Aprobarea este de scurtă durată și este legată de schița nemodificată.
4. Execuție: Un executor strict limitat verifică din nou autorizarea imediat înainte de apel și folosește un ID de idempotență.
5. Dovadă și reacție: Rezultatul, erorile și lanțul de aprobare sunt jurnalizate cu economie de date; alertarea, compensarea și predarea către un om sunt definite.

NIST AI RMF Core încadrează astfel de sarcini în Govern, Map, Measure și Manage. În practică, acest lucru înseamnă: stabilirea responsabilităților și a limitelor de risc, înțelegerea contextului de utilizare, testarea controalelor și reacția la abaterile observate.

Matrice de testare înainte de lansare

Testele pozitive singure nu sunt suficiente. Un instrument ar trebui să eșueze în siguranță chiar și în condiții nefavorabile. Cel puțin aceste cazuri aparțin unei matrice de testare repetabile:

• Un utilizator neautentificat sau neautorizat solicită acțiunea.
• O sesiune valabilă face referire la un obiect al altui tenant.
• Parametrii esențiali se modifică după confirmare.
• Aceeași solicitare se repetă din cauza unui timeout sau a unui dublu clic.
• Un instrument returnează instrucțiuni manipulate sau câmpuri suplimentare neașteptate.
• Un apel depășește limitele de timp, cantitate sau costuri.
• Sistemul țintă cade între verificare și executare.
• O permisiune este revocată cu puțin timp înainte de executare.

Sunt așteptate nu doar acțiuni reușite, ci și respingeri clare, date nemodificate și evenimente de securitate valorificabile. Înainte ca accesul de scriere să fie activat pentru utilizatorii reali, fluxul poate fi verificat în Shadow Mode cu solicitări realiste, fără a executa acțiunile propuse.

Lista de verificare pentru echipele de site-uri web

• Este fiecare instrument mic, dedicat unui scop și dintr-un allowlist fix?
• Sunt verificați utilizatorul, tenant-ul, obiectul și acțiunea pe partea de server?
• Se aplică Deny by Default și permisiuni tehnice minime?
• Văd utilizatorii toate datele esențiale înainte de acțiunile critice?
• Expiră confirmarea la modificări și după un timp scurt?
• Previne un ID de idempotență executarea dublă?
• Există limite, timeout, întrerupere, compensare și Human Handoff?
• Sunt excluse tokenurile, secretele și datele personale inutile din loguri?
• Acoperă matricea de testare erorile de drepturi, manipularea, reîncercările și defecțiunile?

Concluzie: Modelul propune, aplicația decide

Un chatbot de pe un site web capabil de acțiune nu trebuie să înceapă cu acces complet. Începeți cu o acțiune strict limitată, reversibilă și construiți lanțul de aprobare vizibil în jurul ei. Dacă delimitarea instrumentelor, autorizarea pe server, confirmarea concretă, idempotența și calea de rollback sunt concepute împreună, chatul rămâne util fără a oferi modelului rolul unui sistem de securitate. Pentru pasul următor, merită organizat un workshop cu echipele de produs, dezvoltare, suport și protecția datelor: alegeți o acțiune reală, încadrați riscul acesteia și definiți cazul de respingere sigură înainte de prima aprobare în producție.