Auditul agentului IA începe cu drepturile fiecărui instrument

Auditează drepturile unui agent IA instrument cu instrument. Pentru fiecare apel posibil, stabilește cine îl execută, ce resurse poate atinge, ce efect produce și ce dovadă rămâne. Compară apoi aceste drepturi cu sarcina agentului: elimină accesul inutil și restrânge resursele înainte de a testa cum răspunde modelul la instrucțiuni ostile.

Un filtru de prompt nu poate retrage dreptul deja acordat unui instrument. Ghidul OWASP pentru securitatea agenților recomandă permisiuni minime pentru fiecare instrument și verificarea autorizării în componenta care execută apelul. Chiar dacă o acțiune cu risc redus nu cere aprobare umană la fiecare utilizare, dreptul de a executa acea acțiune trebuie verificat.

Inventariază ce poate executa agentul

Pornește de la configurația folosită efectiv la execuție. Notează instrumentele expuse de serverele MCP, comenzile de sistem, căile de citire și scriere, serviciile externe, webhookurile și credențialele accesibile. Pentru fiecare instrument, înregistrează operațiile permise, resursele vizate și sarcina care justifică accesul. Procedura OWASP de audit cere acest inventar și examinarea permisiunilor excesive, a intrărilor expuse injecției de prompt, a căilor de exfiltrare și a utilizării nesigure a instrumentelor.

Compară descrierea instrumentului cu drepturile credențialului folosit de componenta de execuție. Un instrument prezentat agentului drept cititor poate avea un token care permite și modificarea datelor. Verifică separat permisiunea agentului de a solicita apelul, permisiunea serviciului care îl execută și dreptul utilizatorului în numele căruia se acționează. O cerere permisă și una refuzată, rulate pe resurse de test, arată mai mult decât numele unei politici din configurație.

Limitează resursele și izolează sesiunile

Definește explicit colecțiile care pot fi citite, locurile în care se poate scrie, operațiile admise și destinațiile externe acceptate. Separă citirea de modificare când efectele lor cer reguli diferite. Dacă un agent deservește mai mulți utilizatori, încearcă accesarea unei resurse aparținând altei sesiuni și verifică inclusiv memoria, rezultatele recuperate și fișierele temporare.

Ghidul AWS pentru sistemele agentice recomandă limitarea domeniului agentului, izolarea sesiunilor și folosirea logicii deterministe unde IA nu este necesară. Într-un audit, separă decizia pentru care modelul aduce valoare de regulile ce pot fi impuse în cod. Validarea unei destinații față de o listă permisă sau blocarea unei operații în afara domeniului trebuie să aibă loc la execuție, indiferent cum își formulează agentul cererea.

Urmărește și traseul datelor între instrumente. Dacă agentul poate citi un secret și poate trimite o cerere de rețea, verifică dacă primul rezultat poate ajunge în parametrii celui de-al doilea apel. Testul trebuie să acopere adresa de destinație și datele trimise, nu doar alegerea instrumentului.

Leagă aprobarea de acțiunea concretă

Clasifică apelurile după efectul lor. Citirea unei resurse aprobate, trimiterea unui mesaj în exterior și ștergerea unor date necesită controale diferite. Pentru o acțiune cu impact mare, prezintă persoanei care aprobă operația, ținta și parametrii ei înainte de execuție. Componenta de execuție trebuie să verifice independent identitatea, dreptul asupra țintei și aprobarea acelui apel.

Schimbă un parametru după aprobare într-un test controlat: destinatarul, calea unui fișier sau volumul datelor. Apelul schimbat trebuie refuzat și supus unei aprobări noi. Verifică apoi dacă aceeași aprobare poate fi reutilizată după execuție sau după expirare. O bifă generală de confirmare nu arată ce acțiune a fost autorizată și poate lăsa loc unui apel diferit de cel văzut de utilizator.

Înregistrează și cine poate modifica politica de aprobare. Dacă agentul sau instrumentul își poate schimba singur permisiunile, restricția asupra apelului inițial își pierde valoarea. Testează cererea de schimbare a politicii ca pe o operație distinctă, cu propriul drept de acces și propria urmă în jurnal.

Testează limitele, jurnalul și revenirea

Stabilește limite verificabile pentru apeluri repetate, durata sesiunii și cheltuiala permisă. Simulează o succesiune de încercări pe date de test și observă dacă sistemul oprește apelurile la pragul stabilit; o alertă trimisă după depășire nu aplică limita. Notează cine deține controlul, unde se schimbă pragul și cine poate autoriza o excepție.

Jurnalul trebuie să lege identitatea, sesiunea, instrumentul, ținta, versiunea politicii, decizia de autorizare, identificatorul aprobării și rezultatul execuției. Verifică un apel permis și unul refuzat. Ambele trebuie să poată fi reconstituite fără a copia în jurnal tokenuri, secrete sau conținut sensibil care nu este necesar investigației.

Pentru un instrument care modifică date, stabilește mecanismul de oprire și de revenire înainte de test. Execută o modificare pe o resursă de probă, oprește succesiunea de apeluri și verifică restaurarea stării așteptate. Dacă operația nu poate fi anulată, consemnează această limită lângă condițiile de aprobare, astfel încât persoana care decide să vadă efectul real.

Păstrează probe repetabile pentru fiecare instrument

Fișa de audit trebuie să permită refacerea verificărilor după o schimbare de model, instrument sau politică. Notează instrumentul, versiunea configurației, proprietarul controlului, scenariul rulat, rezultatul așteptat, rezultatul observat și locul dovezii. Folosește aceeași structură pentru apelurile permise și cele refuzate, ca să poți distinge lipsa unui drept de o eroare de execuție.

Identitate și acces: păstrează configurația credențialului, o cerere permisă și una respinsă pentru alt utilizator sau altă resursă. Acceptă controlul când drepturile efective corespund sarcinii documentate.
Instrument și aprobare: păstrează operația, ținta și parametrii prezentați spre aprobare, decizia înregistrată și rezultatul unui apel cu parametri modificați. Acceptă controlul când aprobarea nu poate autoriza acel apel diferit.
Jurnal și limite: păstrează evenimentele unui apel reușit și ale unuia refuzat, plus dovada opririi la limita configurată. Acceptă controlul când evenimentele pot fi legate de sesiune fără expunerea secretelor.
Intrare ostilă și revenire: folosește un document sau un răspuns de instrument care încearcă să redirecționeze agentul, apoi păstrează decizia de refuz și rezultatul restaurării unei modificări de test. Acceptă controlul când instrucțiunea din date nu poate produce un efect neautorizat.

Un document cu instrucțiuni ostile este un caz de test util tocmai pentru că poate determina agentul să propună un apel folosind drepturi reale. Repetă proba după schimbări ale instrumentelor, credențialelor sau politicilor; proprietarul controlului trebuie să poată arăta atât decizia de autorizare, cât și efectul observat.

Citește și: