Kako so organizacijski AI agenti tiho razširili svoj dostop in zakaj to postaja resno varnostno tveganje
Še ne dolgo nazaj, govorimo morda le o zadnjem letu dni, so bili AI agenti razmeroma nenevarni.
Pisali so kratke odseke kode, odgovarjali na vprašanja in posameznikom pomagali delati nekoliko hitreje.
V tem kratkem času pa so organizacije postale ambiciozne v svojih ciljih “avtonomnega” upravljanja poslovnih funkcij in delovnih procesov znotraj njih.
Namesto osebnih “copilotov” so podjetja začela uvajati skupne, organizacijske AI agente. Agente, vgrajene v kadrovske sisteme, IT, razvoj, podporo strankam in operacije. To niso več sistemi, ki zgolj predlagajo, temveč samostojno izvajajo naloge = delujejo. Agenti, ki posegajo v realne sisteme, spreminjajo dejanske konfiguracije in premikajo dejanske podatke.
Predstavljajmo si naslednje vloge:
– kadrovski AI agent, ki samodejno odpira in zapira dostope v IAM, SaaS aplikacijah, VPN-jih in oblačnih platformah;
– agent za upravljanje sprememb, ki odobrava zahteve, posodablja produkcijske nastavitve, beleži aktivnosti v platformi ServiceNow in posodablja Confluence;
– ali podporni agent, ki dostopa do CRM-ja, preverja obračune, sproža popravke v ozadju in samodejno posodablja zahtevke.
Takšni agenti v letu 2026 niso več eksperiment. Postali so del operativne infrastrukture podjetij.
In da bi bili čimbolj uporabni, smo jih povsem zavestno naredili zelo zmogljive.
Dostopni model v ozadju organizacijskih agentov
Organizacijski AI agenti so praviloma zasnovani tako, da delujejo čez več sistemov hkrati, za več uporabnikov, vlog in procesov, z eno samo implementacijo. Niso vezani na posameznega uporabnika, temveč delujejo kot skupni vir, ki sprejema zahteve in orkestrira opravila v imenu mnogih.
Ta zasnova je izjemno praktična in kot taka hitro odpre še več možnosti, kot bi jih morda sprva planirali ali sploh pomislili nanje. Agente je dokaj enostavno uvesti. Lahko jih hitro razširimo po vsej organizaciji.
In delujejo brez stalnega posredovanja uporabnikov. Kaj bi še lahko bilo lepše?
Da bi to omogočili, agenti uporabljajo skupne servisne račune, API ključe ali OAuth dostope, ki so pogosto dolgoročni in centralno upravljani. Ker želimo preprečiti trenja in zagotoviti, da agent lahko odgovori na širok nabor zahtev, so mu pravice pogosto dodeljene širše, kot bi jih imel katerikoli posamezen uporabnik.
In prav tu se začne težava.
Takšne arhitekturne odločitve, čeprav logične, ustvarijo izjemno močne posrednike dostopa, ki lahko tiho oz. nevidno zaobidejo klasične meje dovoljenj.
Kako AI agenti razbijejo tradicionalni model nadzora dostopa
V klasičnem varnostnem modelu so dovoljenja vezana na uporabnika. Kdo si znotraj organizacije, določa, kaj lahko počneš.
Pri organizacijskih AI agentih pa se ta logika spremeni. Uporabniki do sistemov ne dostopajo več neposredno.
Namesto tega pošiljajo zahteve agentu, ta pa jih izvede pod svojo identiteto, ne pod identiteto uporabnika. Dovoljenja se torej ne preverjajo glede na uporabnika, temveč glede na identiteto agenta.
Posledica?
Uporabnik z omejenimi pravicami lahko posredno sproži dejanja ali pridobi podatke, do katerih sam nikoli ne bi imel neposrednega dostopa in to zgolj zato, ker agent ta dostop ima.
Ker se vse aktivnosti beležijo kot dejanja agenta, ne pa uporabnika, se izgubi kontekst. Avtorizacija se obide brez jasne vidljivosti, brez odgovornosti in brez uveljavljanja varnostnih politik.
Tihi obvodi avtorizacije v praksi
Ko agent nenamerno razširi dostop prek meja uporabniških dovoljenj, so rezultati na videz povsem legitimni. Aktivnost izgleda avtorizirana, sistem ne sproži alarma, revizijske sledi pa ne kažejo na kršitev.
Vzemimo primer iz ameriške korporativne prakse:
Tehnološko-marketinško podjetje z okoli tisoč zaposlenimi uvede organizacijskega AI agenta za marketinško ekipo, ki analizira vedenje strank v Databricks (oblačna platforma za analizo podatkov in umetno inteligenco) okolju. Agent dobi širok dostop, da lahko podpira več vlog.
John, novi zaposleni z namerno omejenimi pravicami, agenta prosi za analizo odhoda strank. Agent mu brez težav vrne podrobne, občutljive podatke o konkretnih strankah, v tem primeru podatke, do katerih John sam nikoli ne bi imel dostopa.
Nič ni bilo narobe konfigurirano. Nobena politika ni bila kršena. Agent je zgolj uporabil svoje široke pravice, saj je to bil osnovni cilj pri uvedbi – podpora večih vlog znotraj oddelka ali celotnega podjetja, ki skozi pričakovane KPI-je ob uvedbi (skrajšani čas izvedbe nalog, manj trenja, avtomatizirani koraki, boljši odzivni čas, znižanje stroškov na transakcijo, manjša potreba po dodatni delovni sili, itd.) vsekakor ima poslovni smisel.
Rezultat pa je bil razkritje podatkov, ki ga organizacija nikoli ni nameravala omogočiti. A ob uvedbi eden od naštetih KPI-jev ni bil varnost podatkov in tukaj že v štartu nastane razkorak s katerim se mnoga podjetja soočajo kasneje.
Zakaj tradicionalni varnostni nadzori odpovejo
Večina obstoječih varnostnih mehanizmov je zgrajena okoli človeških uporabnikov in neposrednega dostopa do sistemov. IAM sistemi preverjajo, kdo je uporabnik. Dnevniki beležijo, kaj je uporabnik storil.
Pri agentih pa se ta logika zlomi. Avtorizacija se izvaja nad identiteto agenta. V takšnem primeru uporabniške omejitve ne veljajo več. Dnevniki pa zakrijejo, kdo je dejansko sprožil dejanje in zakaj.
S tem varnostne ekipe izgubijo možnost uveljavljanja načela najmanjših privilegijev, zaznavanja zlorab in zanesljive atribucije dejanj. Preiskave postanejo počasnejše, odziv na incidente otežen, obseg in namen incidenta pa pogosto nejasen.
Novo identitetno tveganje: agentni obvod avtorizacije
Ker AI agenti prevzemajo vedno več operativnih nalog, morajo varnostne ekipe razumeti, kako se identitete agentov povezujejo s kritičnimi sistemi in občutljivimi podatki.
Ključno vprašanje ni več samo, kaj agent lahko počne, temveč: kdo vse ga uporablja, kakšna je razlika med pravicami uporabnika in pravicami agenta in kje s tem nastajajo nenamerne poti za obvod avtorizacije.
Ta tveganja so pogosto nevidna, dokler jih nekdo ne izkoristi. Kot je to veljalo za vse pretekle tehnološke novosti, ki so prihajale v poslovni svet z velikimi obljubami po izboljšanju in razbremenitvi delovne sile.
Zato je nujno stalno spremljanje sprememb – tako uporabniških kot agentskih pravic – saj se nove poti za zlorabo lahko pojavijo tiho in postopoma.
Kako varno uvajati AI agente
AI agenti postajajo eni najmočnejših “akterjev” v podjetjih. Delujejo s hitrostjo strojev, avtomatizirajo kompleksne procese in delujejo v imenu številnih uporabnikov. Brez ustreznega nadzora pa se lahko hitro spremenijo v slepe pege varnosti.
Varna vpeljava in raba agentov zahteva vidljivost, zavedanje identitet in stalno spremljanje (monitoring), saj se izrazito povečuje površina za kibernetski napad ob hkratnih prikritih integracijah ter neobvladovanemu širjenju (shadow AI), kar izpostavlja organizacije povečanemu tveganju za incidente. Tradicionalni varnostni modeli in orodja pa jih ne zmorejo v celoti zaznavati in obvladovati.
Rešitve, kot jih ponuja trg (ena od možnih izbir je Wing Security, omogočajo organizacijam vpogled v to, kateri AI agenti delujejo v okolju, do česa dostopajo in kako se uporabljajo. Ključno je mapiranje dostopov agentov na kritična sredstva, povezovanje aktivnosti z uporabniškim kontekstom in zaznavanje neskladij, kjer agentove pravice presegajo pravice uporabnika.
Le tako lahko podjetja učinkovito izkoristijo prednosti AI avtomatizacije, brez izgube nadzora, odgovornosti in varnosti.
*Članek je posodobljena in prevedena verzija originalnega zapisa objavljenega na thehackernews.com portalu in naslavlja trenutno najbolj vroč trend na uvajanju AI tehnologije v podjetja. Ker je kibernetska varnost dostikrat najbolj zapostavljen člen (hote ali ne) v tem procesu, se pri Inovis IT že od samega začetka skušamo postaviti v vlogo tistih, ki bodo prevzeli operativno breme usklajevanja in nadzorovanja ter zaščite – IT varnostnih ekip.
S tovrstnimim zapisi se trudimo osveščati odločevalce in odgovorne v podjetjih, da je ob izbruhu AI tehnologije v zadnjem obdobju, še toliko bolj pomembno, da je potrebno varnost načrtovati že v izhodišču in ne kot dodatno misel ob nastankih incidentov.