Kod klasičnog softvera zaustavljanje programa uglavnom znači prekid procesa. Kod AI agenta problem može biti znatno složeniji. Agent je možda već pokrenuo druge procese, poslao zahteve spoljnim servisima, napravio podagente, dobio privremene kredencijale ili zakazao operacije koje će biti izvršene kasnije. Pritisnuti dugme „stop“ zato ne mora da znači da je zaustavljeno i sve što je sistem prethodno pokrenuo.
Ovo pitanje postaje važnije kako AI sistemi dobijaju veću autonomiju. Agent koji samo generiše tekst može da se prekine bez velikih posledica. Agent koji koristi terminal, menja kod, upravlja cloud resursima, šalje imejlove ili komunicira sa drugim agentima ostavlja trag aktivnosti izvan samog modela. Ako počne da se ponaša neočekivano, kompanija mora biti sposobna ne samo da prekine njegovo zaključivanje već i da mu trenutno oduzme mogućnost daljeg delovanja.
Zbog toga se izraz kill switch često koristi kao jednostavan naziv za mnogo složeniji skup bezbednosnih mehanizama. Pouzdano zaustavljanje autonomnog sistema ne zahteva samo jedno dugme, već kontrolu procesa, mreže, identiteta, kredencijala i svih spoljnih operacija koje je agent pokrenuo.
Zašto „stop“ nije uvek dovoljno
Zamislimo agenta koji dobije zadatak da proveri problem u produkcionom sistemu. Tokom rada analizira logove, pokreće nekoliko skripti, poziva cloud API, otvara issue na GitHub-u i delegira deo analize drugom agentu. U jednom trenutku administrator primećuje da sistem počinje da menja resurse koje nije trebalo da dira i prekida glavni proces.
Ako je arhitektura loše postavljena, deo aktivnosti može da se nastavi. Podagent možda radi kao zaseban proces. API zahtev koji je već poslat može biti obrađen bez obzira na to što je glavni agent ugašen. Zakazani posao može da se izvrši nekoliko minuta kasnije, a token koji je agent koristio može ostati validan satima ili danima.
To nije specifično samo za veštačku inteligenciju. Distribuirani računarski sistemi decenijama imaju problem sa zaustavljanjem procesa koji su pokrenuli druge procese. AI agenti, međutim, povećavaju složenost zato što sami odlučuju koje će alate koristiti i koliko će novih aktivnosti pokrenuti tokom izvršavanja zadatka.
Zato je važno razlikovati zaustavljanje modela od zaustavljanja agenta. Model može prestati da generiše sledeći korak, a posledice njegovih prethodnih odluka mogu ostati aktivne u drugim sistemima.
Prva linija odbrane je izolacija
Jedan od načina da se posledice ograniče jeste da agent od početka radi u izolovanom okruženju. Sandbox ili kontejner može da ograniči fajlove kojima sistem pristupa, procese koje može da pokrene i mrežne destinacije sa kojima može da komunicira.
OpenAI Codex, na primer, koristi sandbox okruženja i različite nivoe odobravanja za operacije koje izlaze iz unapred definisanih granica. Anthropic je kod Claude Code-a takođe uveo sandboxing koji ograničava pristup fajl-sistemu i mreži. Cilj nije samo sprečavanje namernog napada već i smanjivanje posledica greške ili pogrešno protumačenog zadatka.
Izolacija omogućava i efikasniji prekid rada. Ako se svi procesi koje agent pokreće nalaze unutar jednog kontrolisanog okruženja, administrator može da ugasi ceo kontejner ili virtuelnu mašinu umesto da pokušava da pronađe svaki pojedinačni proces.
Problem nastaje kada agent izađe iz tog okruženja. Čim dobije pristup spoljnim API-jima, cloud servisima ili drugim poslovnim sistemima, deo kontrole prelazi izvan sandbox-a. Tada samo njegovo gašenje više nije dovoljno.
Ukidanje kredencijala kao pravi kill switch
Ako agent ima sopstveni digitalni identitet, jedan od najefikasnijih načina zaustavljanja jeste ukidanje njegovih kredencijala. Čak i ako neki njegov proces nastavi da radi, bez važećeg tokena više ne može da pristupi zaštićenim servisima.
Zbog toga su kratkotrajni kredencijali posebno važni kod autonomnih sistema. Agentu koji treba da obavi zadatak tokom deset minuta nije potreban API ključ koji važi godinu dana. Može da dobije privremeni token koji automatski prestaje da važi nakon završetka zadatka ili koji administrator može trenutno da opozove.
To menja i način na koji treba projektovati pristup resursima. Ako deset agenata koristi isti servisni nalog i isti API ključ, zaustavljanje jednog od njih postaje teško bez prekidanja rada svih ostalih. Ako svaki agent ima zaseban identitet i sopstvene kredencijale, njegovo isključivanje može biti precizno.
Upravo zato identity and access management postaje sastavni deo kontrole AI agenata. Kill switch nije samo funkcija modela. On mora da postoji i na nivou identiteta koji agent koristi.
Mreža kao druga tačka prekida
Agent koji izgubi pristup internetu ili kompanijskoj mreži može nastaviti lokalno da obrađuje podatke, ali više ne može da šalje zahteve drugim sistemima. Zbog toga je mrežna izolacija još jedan važan mehanizam za hitno zaustavljanje.
U praksi to može značiti blokiranje outbound saobraćaja, prekid određene mrežne sesije ili premeštanje sistema u izolovani segment mreže. Ako postoji sumnja da je agent kompromitovan prompt injection napadom ili da pokušava da pristupi resursima koji nisu deo zadatka, mrežni pristup može biti ukinut pre nego što se završi detaljna analiza incidenta.
Ovakav pristup je posebno važan zato što se ponašanje agenta može promeniti tokom rada. Sistem koji je prvih nekoliko minuta obavljao očekivane operacije može kasnije, nakon čitanja spoljnog dokumenta ili nailaska na neočekivanu situaciju, početi da koristi alate na drugačiji način.
Zbog toga kontrola mreže ne bi trebalo da bude samo početna konfiguracija. Potrebna je mogućnost da se pristup menja ili potpuno ukine dok agent već radi.
Šta sa podagentima?
Multi-agent sistemi dodatno komplikuju problem. Glavni agent može da podeli zadatak na nekoliko delova i delegira ih drugim agentima. Svaki od njih može imati sopstveni kontekst, proces i pristup određenim alatima.
Ako se zaustavi samo glavni agent, nije nužno da se automatski zaustave i svi podagenti. Zbog toga sistem mora da zna poreklo svakog procesa: ko ga je pokrenuo, kojem zadatku pripada i koje resurse koristi.
Jedno moguće rešenje jeste hijerarhijsko upravljanje životnim ciklusom. Podagent postoji samo dok postoji zadatak roditeljskog agenta, a prekid glavnog procesa automatski poništava njegove tokene, mrežne sesije i dozvole. Time se sprečava nastanak „siročića“ – procesa koji nastavljaju da rade i nakon što je sistem koji ih je pokrenuo ugašen.
To je posebno važno ako agenti mogu dalje da delegiraju zadatke. Bez jasne hijerarhije jedan početni zahtev može da proizvede čitavo stablo procesa koje je teško ručno pronaći i zaustaviti.
Zaustavljanje pre nego što nastane šteta
Najbolji kill switch je onaj koji ne mora da bude aktiviran tek nakon ozbiljnog incidenta. Zbog toga sistemi mogu imati unapred definisane granice čije prekoračenje automatski zaustavlja agenta ili zahteva ljudsku potvrdu.
To mogu biti ograničenja broja API poziva, količine potrošenih resursa, vremena izvršavanja ili broja fajlova koje agent sme da promeni. Mogu se definisati i rizične operacije koje se nikada ne izvršavaju bez dodatnog odobrenja, kao što su brisanje podataka, promena produkcione konfiguracije ili slanje novca.
Takva ograničenja imaju još jednu funkciju: sprečavaju nekontrolisanu potrošnju. Agent ne mora da bude kompromitovan da bi napravio problem. Dovoljno je da uđe u petlju u kojoj neprestano pokušava da izvrši zadatak, poziva modele i spoljne servise i tako stvara troškove bez korisnog rezultata.
Praćenje rada zato mora da bude povezano sa mogućnošću automatskog prekida. Ako sistem samo beleži da se agent ponaša neuobičajeno, ali ne može da mu oduzme pristup, observability ima ograničenu vrednost.
Ko sme da pritisne dugme?
Postoji i organizacioni problem. Ako kompanija koristi veliki broj agenata, mora unapred da bude određeno ko ima ovlašćenje da ih zaustavi. Administrator infrastrukture možda može da ugasi server, bezbednosni tim da opozove kredencijale, a vlasnik poslovnog procesa da odluči da se zadatak prekine. Ako svako kontroliše samo jedan deo sistema, reakcija na incident može biti spora.
Zato procedura za hitno zaustavljanje mora biti definisana pre nego što agent dobije pristup važnim resursima. Potrebno je znati šta se gasi, koji tokeni se opozivaju, koji spoljni poslovi se otkazuju i kako se proverava da nijedan proces nije ostao aktivan.
Nakon toga sledi još jedan važan korak: stanje sistema ne treba odmah vratiti na prethodno samo zato što je agent zaustavljen. Potrebno je utvrditi šta je već promenio i da li neke od tih promena treba poništiti.
Kontrola nije jedno dugme
Ideja fizičkog crvenog dugmeta kojim se autonomni AI trenutno zaustavlja privlačna je zbog svoje jednostavnosti, ali stvarni sistemi ne funkcionišu tako. Što agent ima više alata i veću autonomiju, njegovo zaustavljanje postaje problem upravljanja čitavom infrastrukturom.
Pouzdana kontrola zato zahteva nekoliko nezavisnih mehanizama: mogućnost prekida procesa, izolaciju izvršnog okruženja, ukidanje kredencijala, blokiranje mrežnog pristupa i gašenje svih podagenata i poslova koje je sistem pokrenuo.
Pravo pitanje zato nije da li AI agent ima dugme „stop“. Važnije je da li kompanija, kada ga pritisne, može pouzdano da utvrdi da je agent zaista prestao da deluje.
Milena Šović, M.Sc.,CSM, CSPO
AI Implementation Specialist & Content Trainer
