DOVOLJENO ŠE NE POMENI NAROČENO

Aprila 2026 je Microsoft objavil splošno razpoložljivost platforme Entra Agent ID. AI-agenti lahko z njo dobijo lastne identitete, pravice in pravila dostopa, njihov življenjski cikel pa je mogoče upravljati podobno kot pri drugih identitetah v organizaciji. Microsoft pri tem ločuje tudi različne oblike odgovornosti. Sponzor je povezan s poslovnim namenom agenta ter odločitvami o njegovem dostopu in življenjskem ciklu, medtem ko je tehnični lastnik ločena vloga. [1][2] NIST je februarja odprl podoben problem nekoliko širše. V konceptnem dokumentu o identiteti in avtorizaciji programskih ter AI-agentov je med odprtimi vprašanji navedel njihovo identifikacijo, avtorizacijo, revizijo in nezatajljivost dejanj. Razlog je precej praktičen. Agent, ki uporablja poslovne sisteme, ni več samo program, ki pripravi odgovor. Lahko bere podatke, uporablja orodja, kliče API-je in v nekaterih okoljih tudi neposredno spreminja stanje sistema. [3]

Zato potrebujemo identiteto in pravice. Vendar ostane tudi pri pravilno urejenih pravicah vprašanje, ki ga klasični model dostopa ne razreši vedno sam od sebe: ali konkretno dejanje še sodi v nalogo, ki smo jo agentu pravkar dali?

Ko nobena varnostna kontrola ni odpovedala

Vzemimo agenta v finančni službi. Pri svojem delu sme brati podatke o računih in dobaviteljih, pripravljati plačilne naloge ter jih ob ustreznih pogojih posredovati v nadaljnji postopek. Takšna dovoljenja sama po sebi niso problematična. Brez njih ne bi mogel opravljati dela, za katerega je bil uveden.

Uporabnik mu naroči, naj pregleda zapadle račune in pripravi gradivo za sestanek. Agent podatke poišče, preveri dobavitelje in razvrsti obveznosti. Nato ugotovi, da lahko za nekatere račune pripravi tudi plačilne naloge, zato naredi še ta korak.

Sistem pri tem ni nujno naredil nič narobe. Identiteta je veljavna, dovoljenje obstaja, uporabljena funkcija je dovoljena in zahtevo sprejme tudi ciljni sistem. Ni ukradenega gesla, prevzete seje, skritega navodila v dokumentu ali ranljivosti, ki bi jo kdo izkoristil.

Razlika je drugje. Naročen je bil pregled. Agent pa je iz dovoljenih možnosti izbral tudi dejanje, ki že posega v postopek izvedbe. Pri človeku takšno razliko pogosto rešujejo poznavanje postopka, organizacijska pravila in razumevanje posledic. Če del odločitve prepustimo agentu, mora biti meja dovolj jasna tudi za sistem, ki njegovo dejanje dovoljuje.

Pravica opisuje možnosti, naloga pa njihov trenutni obseg

Avtorizacija določa, katere operacije sme identiteta izvajati. Agent lahko na primer dobi možnost branja dokumentov, spremembe zapisa, pošiljanja sporočil ali uporabe določenega API-ja. To je temeljna varnostna meja in načelo najmanjših privilegijev pri agentih zaradi njihove sposobnosti hitrega izvajanja več zaporednih korakov ni nič manj pomembno kot pri uporabnikih ali aplikacijah.

Microsoft pri Agent ID zato priporoča omejevanje dostopa na vire, funkcije in obsege, ki jih agent dejansko potrebuje. Pri občutljivejših pravicah priporoča tudi časovno omejene dostope, odobritve in druge načine, pri katerih višji privilegij ni nujno stalno prisoten. [4]

Toda tudi dobro odmerjena vloga agenta je praviloma širša od posamezne naloge. Agent, ki sme pošiljati elektronsko pošto, tega ne potrebuje pri vsaki analizi poštnega predala. Agent, ki sme spreminjati dokumente, pri nalogi primerjave dveh različic potrebuje predvsem branje. Finančni agent lahko legitimno potrebuje funkcijo priprave plačila, čeprav mu je v konkretnem primeru naročeno samo poročilo.

Najmanjši privilegij zato problema ne izniči. Zmanjša prostor možnih posledic, ne pove pa nujno, kateri del tega prostora pripada trenutni nalogi.

Ta problem poznamo že brez umetne inteligence

Razlika med široko pravico in konkretno operacijo ni novost. Dobro jo pokaže OAuth 2.0 Rich Authorization Requests, opisan v RFC 9396.

Klasični OAuthov scope lahko pove, da ima odjemalec pravico do določene vrste dostopa. Pri nekaterih postopkih je to premalo. RFC kot primer navaja avtorizacijo plačila, kjer niso pomembne samo pravice za plačevanje, ampak tudi znesek, valuta, prejemnik in drugi podatki konkretne transakcije. Parameter authorization_details omogoča, da se takšne podrobnosti prenesejo skupaj z zahtevo za avtorizacijo. [5]

RFC 9396 ni standard za določanje namena AI-agentov. To je pomembna meja primerjave. Pokaže pa arhitekturno možnost, ki je za agente zelo zanimiva: dostopa ni treba opisovati samo z vprašanjem, kaj neka identiteta na splošno sme. Avtorizacijo je mogoče približati konkretnemu dejanju in njegovim parametrom.

Pri agentu bi podobna logika pomenila razliko med »sme uporabljati funkcijo za plačila« in precej ožjim »v okviru te naloge sme pripraviti predlog plačila za te račune, do te faze postopka in v tem časovnem obdobju«.

Kako bo takšna meja tehnično izvedena, je drugo vprašanje. Lahko je del politike, del delovnega toka, kratkotrajnega žetona, potrditve, omejitve orodja ali kombinacije več kontrol. Pomembneje je, da obstaja zunaj proste interpretacije modela.

Problem nastane pri sestavljanju povsem dovoljenih korakov

Pri običajni avtomatizaciji je velik del postopka zapisan v programu. Razvijalec vnaprej določi, kateri korak sledi kateremu in pod katerimi pogoji. Agentni sistemi so zanimivi prav zato, ker lahko del poti oblikujejo med izvajanjem. Iz cilja sklepajo, katera orodja potrebujejo, uporabljajo rezultate prejšnjih korakov ter na njihovi podlagi izbirajo naslednje dejanje. OWASP pri tveganju Excessive Agency opozarja, da lahko škodljive posledice nastanejo zaradi preširokih funkcij, dovoljenj ali avtonomije, sprožijo pa jih lahko tudi dvoumna povsem benigna navodila ali napačen modelski sklep. Zlonameren napadalec torej ni nujni pogoj. [6]

Tu je pomembna še ena podrobnost. Posamezno dejanje je lahko popolnoma smiselno in dovoljeno. Tudi naslednje. Težava postane vidna šele v zaporedju.

Agent prebere podatke, jih primerja, ugotovi najbolj verjeten naslednji korak, uporabi funkcijo, za katero ima dovoljenje, in rezultat uporabi kot podlago za naslednje dejanje. Vsaka operacija posebej lahko prestane klasično preverjanje pravic. Šele pogled na začetno nalogo pokaže, da se je postopek nekje razširil dlje, kot je bilo naročeno.

Pri agentih zato ni vedno dovolj nadzorovati samo posameznega klica orodja. Pomembna postaja tudi povezava med klicem in nalogo, zaradi katere je agent sploh začel delovati.

Potrditev mora opisati posledico

Pri občutljivem dejanju je očitna rešitev človeška potrditev. Agent pripravi predlog, človek ga pregleda in dovoli nadaljevanje. Takšen model je uporaben, vendar le, če je iz potrditve jasno, kaj bo dejansko sledilo.

Generično vprašanje »Ali želite nadaljevati?« je za ta namen precej slabo. Uporabniku pove predvsem to, da nek proces še ni končan. Če mora odločiti o posledici, potrebuje podatke o posledici.

Pri plačilu so to lahko prejemnik, znesek in račun. Pri spremembi konfiguracije objekti in vrednosti, ki bodo spremenjeni. Pri elektronski pošti naslovniki in končno sporočilo. Pri brisanju datotek dejanski seznam datotek. S tem človek ne potrjuje agentove razlage lastnega namena, temveč operacijo, ki jo bo sistem izvedel. Razlika se zdi majhna, vendar je pomembna. Če je agent že napačno razumel prvotno navodilo, ni posebej koristno, da nam pred izvedbo samo še lepo povzame svojo napačno razlago.

Dobro zasnovan postopek lahko zato dopušča veliko samostojnosti pri korakih, katerih posledice so povratne ali omejene, ter zahteva novo, natančnejšo odločitev tam, kjer dejanje pomembneje spremeni zunanji sistem.

Revizijski zapis potrebuje tudi povezavo z nalogo

Pri preiskavi dogodka nas bo zanimalo, kateri agent je neko operacijo izvedel. Lastna identiteta agenta je pri tem pomemben napredek, saj omogoča razlikovanje njegove dejavnosti od dejavnosti uporabnika ali splošne aplikacijske identitete.

Toda podatek, da je agent A ob 10.43 uporabil API B in spremenil objekt C, še vedno opisuje predvsem tehnično izvedbo. Če isti agent opravlja več različnih nalog, potrebujemo za razumevanje dogodka tudi odgovor, zakaj je bila konkretna operacija sploh sprožena.

NIST zato pri agentnih identitetah poleg identifikacije in avtorizacije odpira tudi vprašanja revizije ter nezatajljivosti dejanj. Microsoft pa pri Agent ID gradi model, v katerem imajo agenti lastno identiteto, sledljiv življenjski cikel, nadzor dostopa in določeno poslovno odgovornost. [2] [3]

To še ne pomeni, da današnje platforme že ponujajo univerzalen zapis celotne poti od uporabnikovega navodila do vsake poznejše operacije. Prav zato je pri načrtovanju agentnih sistemov koristno razmisliti, ali lahko po dogodku rekonstruiramo vsaj povezavo med izvorno zahtevo, agentom, uporabljenim pooblastilom, orodjem in končno posledico. Če te povezave ni, lahko revizijski dnevnik zelo natančno pove, kaj je naredil agent, precej težje pa pojasni, zakaj je bilo to dejanje v tistem trenutku upravičeno.

Avtonomija potrebuje mejo, ne neprekinjenega nadzornika

Agent, ki mora za vsak prebran dokument ali vsak klic API-ja čakati človeka, hitro izgubi velik del razloga za svoj obstoj. Varnostni odgovor zato ne more biti preprosto dodajanje potrditvenega okna pred vsak korak.

Tudi druga skrajnost ni dobra. Če agent dobi vsa dovoljenja svoje celotne vloge in mora pri vsaki nalogi sam presoditi, katere izmed njih je človek tisti trenutek mislil uporabiti, smo del varnostne politike prenesli v razumevanje naravnega jezika.

Meja je odvisna od posledice. Branje podatka, priprava osnutka, objava dokumenta, sprememba produkcijske konfiguracije in izvedba finančne transakcije niso primerljive operacije. Pri prvih je lahko širša samostojnost sprejemljiva. Pri drugih je lahko smiselno pooblastilo omejiti na konkretnejše objekte, čas, znesek, vrsto dejanja ali dodatno odobritev.

To ni problem, ki bi ga rešil samo boljši model. Boljši model lahko navodilo pravilneje razume, vendar dovoljenje za dejanje še vedno določa sistem okoli njega.

Ko »sme« postane premalo natančen odgovor

Agentne identitete rešujejo pomemben del problema. Organizacija mora vedeti, kateri agenti obstajajo, kdo je odgovoren za njihov namen in življenjski cikel, do katerih virov dostopajo ter katere pravice imajo. Brez tega bi hitro dobili novo vrsto nepreglednih servisnih identitet, le da bi te lahko precej samostojneje uporabljale svoja dovoljenja.

Naslednje vprašanje se pojavi šele potem, ko je ta del urejen.

Če agent neko operacijo sme izvesti, iz česa sistem ve, da jo sme izvesti tudi v okviru naloge, ki jo opravlja ta trenutek?

V tradicionalnih avtomatizacijah je velik del odgovora nosila vnaprej določena programska pot. Pri agentih se lahko del te poti sestavi sproti. Zato bo pri občutljivejših procesih pomembno vedno natančneje povezovati identiteto in pravico tudi s konkretno delegacijo, transakcijo ali odločitvijo.

Sistem mora vedeti, kaj agent sme. Pri nekaterih dejanjih pa bo moral vedeti tudi, zakaj to sme prav zdaj.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZNajmanjši privilegij omeji prostor možnih dejanj, vendar mora sistem posebej omejiti tudi trenutni namen oziroma obseg konkretne agentske naloge.

RAZISKAVE0

DOKUMENTACIJA6

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-25

Viri

1. 01PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn, »Microsoft Entra releases and announcements«, april 2026. Objava splošne razpoložljivosti Microsoft Entra Agent ID in opis identitetnega ter avtorizacijskega okvira za AI-agente.
2. 02PRIMARY DOCUMENTATIONNational Institute of Standards and Technology (NIST)
   Microsoft Learn, »Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers)«, posodobljeno 21. julija 2026. Opis ločenih vlog lastnika, sponzorja in managerja. Sponzor je povezan predvsem s poslovno odgovornostjo za namen in življenjski cikel agenta.
3. 03PRIMARY DOCUMENTATIONNational Institute of Standards and Technology (NIST)
   NIST NCCoE, »Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization«, 5. februar 2026. Konceptni dokument o uporabi identitetnih standardov pri programskih in AI-agentih. Med odprtimi področji obravnava identifikacijo, avtorizacijo, revizijo in nezatajljivost dejanj agentov.
4. 04PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn, »Best practices for Microsoft Entra Agent ID« in »Least privilege for AI agents with Microsoft Entra Agent ID«. Priporočila za omejevanje dovoljenj, časovno omejen dostop, JIT- pristope, nadzor življenjskega cikla in revizijo dejavnosti agentov.
5. 05STANDARDInternet Engineering Task Force (IETF)
   IETF, RFC 9396, »OAuth 2.0 Rich Authorization Requests«, maj 2023. Standard uvaja authorization_details za podrobnejše izražanje avtorizacijskih zahtev. Primer plačilne transakcije vključuje konkretne podatke o znesku in prejemniku. V članku je uporabljen kot primer podrobnejše avtorizacije, ne kot standard za upravljanje namena AI- agentov.
6. 06STANDARDOWASP
   OWASP GenAI Security Project, »LLM06:2025 Excessive Agency«. Opis tveganja škodljivih dejanj v sistemih, ki modelom omogočajo uporabo zunanjih funkcij. Med možnimi sprožilci navaja tudi dvoumna benigna navodila in napačne modelske sklepe, ne samo zlonamerne napade.