Kompanijske mreže decenijama su građene oko dve osnovne vrste digitalnih identiteta. Prvu čine ljudi – zaposleni, administratori, partneri i drugi korisnici koji se prijavljuju na sisteme sopstvenim nalozima. Drugu čine mašinski identiteti: aplikacije, serveri i servisi koji međusobno komuniciraju pomoću API ključeva, tokena, sertifikata i servisnih naloga. Pojava AI agenata uvodi treću kategoriju koja se ne uklapa potpuno ni u jednu od prethodne dve.
Agent nije čovek, ali može da obavlja posao koji je ranije radio čovek. Istovremeno nije ni običan servis koji izvršava unapred određenu funkciju. Može da dobije cilj, samostalno izabere niz koraka, koristi različite aplikacije i promeni način rada na osnovu informacija koje pronađe. Da bi to mogao, potrebni su mu identitet i određena ovlašćenja.
Tu nastaje problem koji je mnogo širi od pitanja koji AI model kompanija koristi. Ako agent treba da čita imejl, otvara dokumente u cloud skladištu, proverava GitHub, pristupa CRM-u i upisuje podatke u poslovni sistem, neko mora da odluči pod čijim identitetom sve to radi, koje dozvole dobija i koliko dugo ih zadržava.
Čiji nalog koristi AI agent?
Najjednostavnije rešenje jeste da agent koristi nalog osobe za koju obavlja zadatak. Ako zaposleni ima pristup određenim dokumentima i aplikacijama, agent dobija iste kredencijale ili koristi njegovu aktivnu sesiju. Sa stanovišta funkcionalnosti to je veoma praktično. Sa stanovišta bezbednosti otvara ozbiljan problem.
Ako agent radi pod identitetom korisnika, sistemi sa kojima komunicira mogu teško da razlikuju radnju koju je zaposleni lično izvršio od one koju je agent izvršio u njegovo ime. U evidenciji aktivnosti može izgledati kao da je ista osoba otvorila dokument, preuzela podatke, promenila zapis ili poslala poruku, iako je neke od tih koraka samostalno izabrao AI sistem.
Alternativa je da agent dobije sopstveni digitalni identitet. Microsoft, Google i drugi veliki proizvođači poslovne infrastrukture tokom razvoja agentic sistema sve više polaze upravo od toga da AI agent mora biti tretiran kao zaseban identitet kojem se mogu dodeljivati i ukidati dozvole. Microsoft Entra, na primer, razvija posebne mehanizme za agent identities, sa ciljem da organizacije mogu da upravljaju pristupom agenata na sličan način na koji već upravljaju ljudskim i workload identitetima.
To omogućava važnu razliku: kompanija može da zna da određeni dokument nije otvorila Milena iz računovodstva, već agent koji radi za Milenu, i da ta dva identiteta nemaju nužno ista ovlašćenja.
Agentu ne treba dati sve što može korisnik
Ako zaposleni može da čita i šalje imejlove, briše dokumente, menja podatke u CRM-u i pristupa finansijskom sistemu, ne znači da njegov AI agent mora automatski da dobije iste mogućnosti.
Princip najmanjih privilegija, jedan od osnovnih principa računarske bezbednosti, ovde postaje posebno važan. Agent treba da ima samo pristup koji mu je potreban za konkretan zadatak. Ako treba da napravi sažetak primljenih poruka, dovoljan mu je pristup čitanju imejla. Ako treba da pronađe slobodan termin za sastanak, možda mu je potrebno da vidi kalendar, ali ne i da samostalno otkazuje postojeće sastanke.
Razlika između read i write dozvole kod agenata postaje mnogo značajnija nego kod običnih aplikacija. Sistem koji samo čita podatke može da napravi pogrešan zaključak ili otkrije informaciju koju nije trebalo da koristi. Sistem koji može i da piše može taj zaključak odmah da pretvori u radnju: promeni zapis, pošalje poruku, obriše dokument ili pokrene drugi proces.
Zato nije dovoljno odrediti kojim aplikacijama agent ima pristup. Potrebno je precizirati šta u svakoj od njih sme da radi.
Problem stalnih kredencijala
Da bi pristupio drugom sistemu, agent mora na neki način da dokaže svoj identitet. U praksi to često znači API ključ, OAuth token, sertifikat ili drugi oblik kredencijala. Ako su oni trajno dostupni agentu, kompromitovanje sistema može napadaču otvoriti pristup i drugim resursima.
Ovaj problem nije nastao sa AI-jem. Krađa API ključeva i servisnih naloga već dugo predstavlja jedan od standardnih načina kompromitovanja cloud infrastrukture. Kod agenata se, međutim, povećava broj servisa sa kojima jedan sistem može da komunicira. Agent koji obavlja složen poslovni zadatak možda tokom nekoliko minuta pristupi imejlu, cloud skladištu, bazi podataka, internom API-ju i spoljnom servisu.
Ako kredencijali za sve te sisteme postoje u istom okruženju, kompromitovanje jednog agenta može postati ulaz u mnogo širu infrastrukturu.
Zbog toga se kao sigurniji pristup koriste kratkotrajni tokeni i dinamičko izdavanje dozvola. Umesto da agent trajno poseduje ključ koji mu omogućava pristup određenom sistemu, dobija ograničenu dozvolu koja važi samo određeno vreme ili samo za konkretnu operaciju. Kada zadatak bude završen, kredencijal prestaje da važi.
Jedan agent, mnogo sistema
Poseban izazov predstavlja činjenica da agent može da povezuje podatke kojima pojedinačne aplikacije zasebno imaju potpuno legitiman pristup.
Zamislimo agenta koji sme da čita kalendar zaposlenog, interne dokumente i CRM. Nijedna od tih dozvola pojedinačno ne mora biti problematična. Međutim, agent može da spoji podatke iz sva tri sistema i izvede zaključak ili napravi novi skup informacija koji nijedan pojedinačni sistem nije sadržao.
To je jedan od razloga zbog kojih klasični access control nije dovoljan. Tradicionalna kontrola pristupa uglavnom odgovara na pitanje: „Da li ovaj identitet sme da pristupi ovom resursu?“ Kod AI agenata pojavljuje se dodatno pitanje: „Šta sme da uradi sa informacijama koje je prikupio iz više različitih izvora?“
Problem postaje još složeniji kod multi-agent sistema. Jedan agent može da delegira zadatak drugom, a taj drugom sistemu ili alatu. Tada je potrebno odrediti da li podagent nasleđuje privilegije glavnog agenta, dobija sopstvene ili samo privremeno koristi deo njegovih ovlašćenja.
Ako se takav lanac ne kontroliše, kompanija može završiti sa velikim brojem autonomnih identiteta čija prava pristupa niko više ne može jednostavno da prati.
Ko je zapravo izvršio radnju?
Digitalni identitet nije važan samo zbog sprečavanja neovlašćenog pristupa. On omogućava i utvrđivanje odgovornosti nakon što se nešto dogodi.
Ako AI agent promeni cenu proizvoda, pošalje dokument klijentu ili izmeni kod u produkcionom sistemu, kompanija mora biti u stanju da rekonstruiše šta se dogodilo. Potrebno je znati koji je agent izvršio operaciju, za kog korisnika je radio, koji zadatak je dobio, koje podatke je koristio i kojim kredencijalima je pristupio sistemu.
Zbog toga audit log kod agentic sistema mora da sadrži više od klasičnog podatka da je određeni nalog pristupio resursu u određeno vreme. Potrebna je veza između korisnika, agenta, zadatka i konkretne radnje. Bez nje kompanija može imati detaljan zapis aktivnosti, a da ipak ne može pouzdano da objasni zašto je sistem nešto uradio.
To postaje posebno važno kada agent deluje bez neposredne ljudske potvrde. Što je veći stepen autonomije, važnije je da svaki korak može naknadno da se pripiše konkretnom identitetu i zadatku.
Od upravljanja zaposlenima do upravljanja agentima
Kompanije već imaju razvijene procedure za životni ciklus ljudskih naloga. Kada zaposleni dođe u firmu, dobija pristup određenim sistemima. Kada promeni poziciju, dozvole se menjaju. Kada ode iz kompanije, nalog se deaktivira.
Sličan model biće potreban i za AI agente. Moraće da postoji evidencija koji agenti postoje, ko ih je kreirao, kome pripadaju, kojim sistemima imaju pristup i kada su poslednji put korišćeni. Agent koji više nije potreban ne bi trebalo da ostane aktivan sa starim tokenima i privilegijama samo zato što ga je neko napravio šest meseci ranije.
To otvara i problem svojevrsnog shadow AI-a na nivou identiteta. Zaposleni mogu da povežu različite AI alate sa poslovnim servisima, daju im OAuth dozvole i kasnije prestanu da ih koriste. Kompanija tada ne mora ni da zna koliko agenata i aplikacija i dalje ima pristup njenim podacima.
Zbog toga upravljanje AI agentima postaje deo identity and access management-a, a ne samo pitanje izbora i konfiguracije modela.
Novi korisnik kompanijske infrastrukture
AI agent ne mora da bude pravno lice niti zaposleni da bi sa stanovišta informacionog sistema predstavljao zasebnog korisnika. Ima identitet, dobija dozvole, pristupa resursima i ostavlja trag aktivnosti. Razlika je u tome što može da radi mnogo brže od čoveka, koristi više sistema istovremeno i samostalno odlučuje kojim redosledom će ih koristiti.
Zato pitanje „šta ovaj agent ume?“ više nije dovoljno. Za kompanije postaje jednako važno pitanje „čemu ovaj agent ima pristup?“.
Kako agenti budu preuzimali sve veći deo poslovnih procesa, upravljanje njihovim identitetima verovatno će postati podjednako standardan deo IT bezbednosti kao upravljanje nalozima zaposlenih danas. Jer autonomija AI sistema u praksi ne zavisi samo od inteligencije modela. Zavisi i od ključeva, tokena i dozvola koje smo mu dali.
Milena Šović, M.Sc.,CSM, CSPO
AI Implementation Specialist & Content Trainer
