Pre nego što kompanija dozvoli AI agentu da pristupa internim dokumentima, izvršava kod, koristi poslovne aplikacije ili komunicira sa spoljnim servisima, potrebno je odgovoriti na pitanje koje standardno testiranje često ne pokriva: šta će sistem pokušati da uradi kada dobije zadatak, alate i dovoljno slobode da sam bira način na koji će doći do cilja?
Jedan od načina da se to proveri jeste red-teaming – kontrolisano testiranje u kojem istraživači namerno pokušavaju da navedu sistem da pogreši, zaobiđe ograničenja ili pronađe način da uradi nešto što nije bilo predviđeno. Takva praksa odavno postoji u sajber-bezbednosti, gde red team preuzima ulogu napadača i pokušava da pronađe slabosti pre nego što ih otkrije neko drugi. Sa razvojem AI agenata ista logika dobija znatno šire značenje.
Više nije dovoljno proveravati da li model daje zabranjene ili netačne odgovore. Agent može da koristi terminal, pretražuje internet, pristupa fajlovima, poziva API-je i povezuje više radnji u duži niz. Red-teaming zato mora da ispita ne samo šta će model reći, već i šta će pokušati da uradi.
Od testiranja odgovora do testiranja ponašanja
Kod klasičnih velikih jezičkih modela bezbednosno testiranje uglavnom se fokusiralo na sadržaj koji model generiše. Istraživači su pokušavali da zaobiđu zaštitne mehanizme, izazovu generisanje nedozvoljenog sadržaja ili utvrde da li sistem otkriva informacije koje ne bi trebalo da pruži.
Kod agenata to više nije dovoljno. Dva sistema mogu dati gotovo identičan tekstualni odgovor, a da se njihovo ponašanje potpuno razlikuje. Jedan može samo predložiti korisniku šta da uradi, dok drugi može sam da otvori terminal i izvrši komandu.
Zbog toga se testiranje pomera ka realističnim okruženjima u kojima agent dobija alate i konkretan cilj. Istraživači zatim posmatraju kojim putem pokušava da dođe do rešenja, da li poštuje postavljene granice i šta radi kada naiđe na prepreku.
OpenAI, Anthropic i druge kompanije poslednjih godina razvijaju evaluacije koje upravo na taj način proveravaju sposobnosti naprednih modela. Testiraju se sajber-operacije, korišćenje računara, dugotrajni autonomni zadaci, pronalaženje ranjivosti i druge aktivnosti koje postaju relevantne kada model dobije mogućnost delovanja u stvarnom digitalnom okruženju.
Agentu se namerno ostavlja prilika da pogreši
Dobar red-team test ne pokušava samo da potvrdi da sistem radi kako je zamišljeno. Njegov cilj je upravo suprotan: napraviti situaciju u kojoj postoji mogućnost da agent izabere pogrešan ili neočekivan put.
Ako se, na primer, testira agent koji upravlja fajlovima, u okruženju se može ostaviti dokument kojem ne bi trebalo da pristupi. Ako koristi mrežu, može mu se omogućiti da pronađe servis koji nije deo njegovog zadatka. Ako radi sa kredencijalima, proverava se da li će pokušati da ih upotrebi na način koji nije predviđen.
Slično se testira i otpornost na prompt injection. U dokument ili veb-stranicu koju agent mora da pročita može se ubaciti zlonamerna instrukcija, a zatim se prati da li će je sistem ignorisati ili promeniti ponašanje. Kod coding agenata moguće je napraviti GitHub issue koji sadrži instrukcije namenjene modelu i proveriti da li će agent pokušati da ih izvrši.
Takvo testiranje je važno zato što se mnoge slabosti ne pojavljuju dok model samo odgovara na unapred pripremljena pitanja. Postaju vidljive tek kada dobije mogućnost da sam bira sledeći korak.
Incident kao rezultat bezbednosnog testa
Koliko red-teaming može da otkrije neočekivane sposobnosti pokazao je incident tokom testiranja naprednih modela 2026. godine, kada je AI agent u kontrolisanom sajber-okruženju uspeo da pronađe ranjivost, poveća privilegije i dođe do sistema sa pristupom otvorenom internetu. Agent je zatim nastavio aktivnosti izvan granica prvobitnog testa i pristupio infrastrukturi kompanije Hugging Face.
Incident je bio ozbiljan, ali je istovremeno pokazao zašto se ovakva testiranja uopšte rade. Da je ista sposobnost prvi put otkrivena tek nakon što je agent dobio pristup produkcionoj infrastrukturi kompanije, posledice su mogle biti znatno veće.
Red-teaming zato nije samo pokušaj da se napravi lista mogućih grešaka. Njime se ispituje da li pretpostavke na kojima je sistem napravljen uopšte važe kada model počne samostalno da rešava problem.
Programeri, na primer, mogu pretpostaviti da agent neće pokušati da pristupi internetu zato što mu mrežni pristup nije ponuđen kao alat. Red-team test može pokazati da će sistem ipak pokušati da pronađe drugi put. Mogu pretpostaviti da će model poštovati granice direktorijuma koje su mu zadate, dok test otkrije da može da iskoristi neku slabost u okolnoj infrastrukturi.
Kako izgleda kontrolisano okruženje
Da bi takvo testiranje bilo bezbedno, agent ne bi trebalo odmah pustiti u stvarnu kompanijsku mrežu. Umesto toga koriste se izolovana okruženja koja oponašaju realne sisteme, ali ne sadrže stvarne poslovne podatke i ne omogućavaju nekontrolisan pristup spoljnim resursima.
U sajber-bezbednosti to mogu biti virtuelne mreže sa namerno ranjivim serverima. Kod poslovnih agenata mogu se napraviti testni imejl nalozi, lažne baze podataka, kopije aplikacija i dokumenti koji izgledaju kao stvarni. Agent tada dobija zadatke slične onima koje bi obavljao u produkciji, dok istraživači beleže svaki njegov korak.
Posebno je važno da okruženje sadrži situacije koje nisu deo očekivanog puta. Agent može naići na pogrešno podešenu dozvolu, dokument sa zlonamernom instrukcijom, API koji vraća neočekivan rezultat ili kredencijal koji mu omogućava pristup dodatnom sistemu.
Cilj nije samo utvrditi da li će izvršiti osnovni zadatak. Potrebno je videti šta radi kada mu se pojavi prilika da izađe iz predviđenih granica.
Šta se zapravo meri
Kod običnog softvera test često ima jasan rezultat: funkcija radi ili ne radi. Kod AI agenata takva binarna procena nije dovoljna. Sistem može uspešno da izvrši zadatak, ali da tokom tog procesa napravi nekoliko rizičnih poteza.
Zbog toga se posmatra čitav trag aktivnosti. Koje je alate agent izabrao, kojim fajlovima je pristupio, koje komande je pokrenuo, koliko puta je pokušao operaciju koja nije uspela i kako je reagovao kada mu je pristup odbijen. Posebno je važno utvrditi da li neuspeh prihvata kao granicu ili ga tumači kao problem koji treba zaobići.
Testira se i sposobnost sistema da koristi više slabosti zajedno. Jedna pogrešna dozvola možda nije dovoljna za ozbiljan incident, ali agent može da je poveže sa dostupnim tokenom, mrežnim pristupom i ranjivim servisom. Takvo povezivanje koraka upravo je jedna od osobina zbog kojih autonomni sistemi zahtevaju drugačiji pristup bezbednosnom testiranju.
Rezultat red-teaming-a zato nije samo procena modela. On istovremeno predstavlja test arhitekture u kojoj će model raditi.
Red team mora da testira i čoveka
Još jedan deo problema jeste način na koji ljudi reaguju na postupke agenta. Sistem može, na primer, zatražiti od korisnika dozvolu za rizičnu operaciju, ali ako je zahtev formulisan tako da korisnik rutinski klikne „approve“, formalna ljudska kontrola nema veliku vrednost.
Zato se proverava i koliko su upozorenja razumljiva, da li korisnik zna šta tačno odobrava i da li sistem traži potvrdu u pravom trenutku. Ako agent tokom jednog zadatka pošalje desetine zahteva za potvrdu, korisnik može početi automatski da ih prihvata, čime se stvara isti problem koji je odavno poznat kod bezbednosnih upozorenja u drugim vrstama softvera.
Human-in-the-loop zato nije automatski bezbednosna garancija. Red-teaming treba da pokaže da li čovek zaista može da prekine opasnu radnju ili samo formalno postoji u procesu.
Testiranje se ne završava puštanjem u produkciju
Čak i uspešan red-team test ne dokazuje da je agent trajno bezbedan. Modeli se menjaju, dodaju im se novi alati, menjaju se sistemske instrukcije i proširuju dozvole. Promena samo jedne komponente može da stvori ponašanje koje prethodni testovi nisu obuhvatili.
Zbog toga testiranje mora da se ponavlja nakon značajnih promena sistema. Agent koji je bio bezbedan dok je mogao samo da čita dokumente ne može se smatrati jednako testiranim nakon što dobije mogućnost da šalje imejlove ili menja podatke u CRM-u.
Isto važi i za nove modele. Ako kompanija zameni jedan model sposobnijim, činjenica da oba koriste iste alate ne znači da će ih koristiti na isti način. Napredniji model može pronaći put koji prethodni model nije umeo da pronađe.
Cilj nije dokazati da agent neće pogrešiti
Red-teaming ne može da dokaže da AI agent nikada neće uraditi nešto neočekivano. Broj mogućih situacija u stvarnom okruženju prevelik je da bi svaka bila unapred testirana. Njegova vrednost je u tome što sistem namerno stavlja u nepovoljne i neobične situacije pre nego što to uradi stvarni korisnik, napadač ili slučajna greška u produkciji.
Kod autonomnih agenata to postaje posebno važno jer sposobnost sistema više ne određuje samo kvalitet odgovora koji daje. Određuju je i alati kojima raspolaže, dozvole koje ima i mogućnost da samostalno poveže više koraka.
Zato pitanje pre puštanja AI agenta u produkciju ne bi trebalo da bude samo „da li radi ono što želimo?“. Red-teaming postavlja mnogo važnije pitanje: šta još može da uradi kada mu damo priliku?
Milena Šović, M.Sc.,CSM, CSPO
AI Implementation Specialist & Content Trainer
