Keď AI začne konať – riadenie identity, oprávnení a prístupov pre agentov

Najväčším rizikom agentickej AI preto nemusí byť chybná odpoveď. Môže ním byť nesprávna akcia vykonaná úplne správne.

Pri chatbotovi sa bezpečnosť točila najmä okolo promptu, odpovede a informácií, ktoré model dokáže zobraziť. Agent však pridáva ďalšie články reťazca: podnikové dáta, identity, konektory, API a konkrétne akcie. Môže aktualizovať záznam, vytvoriť súbor, spustiť proces alebo komunikovať mimo organizácie. Z asistenta sa stáva aktér – a tomu musí zodpovedať aj spôsob, akým ho riadime.

1. Od odpovede k vykonaniu

Podnikové využitie AI si môžeme zjednodušene predstaviť v troch úrovniach. Na prvej AI pracuje s verejnými informáciami. Na druhej dostane kontrolovaný prístup k podnikovým dátam a odpovedá v pracovnom kontexte používateľa. Na tretej už môže nad systémami vykonávať akcie. Práve tu sa mení rizikový profil: chybná alebo zmanipulovaná odpoveď sa môže premeniť na zmenu dát, externú komunikáciu či spustenie procesu.

Klasifikácia údajov, DLP a používateľské oprávnenia zostávajú dôležité, ale už samy nestačia. Organizácia musí vedieť, pod akou identitou agent koná, ku ktorým zdrojom sa pripája, aké nástroje smie použiť, kam môže zapisovať a ktoré kroky vyžadujú súhlas človeka. Potrebuje tiež jasného vlastníka, auditnú stopu, pravidelnú revíziu a spôsob, ako agenta okamžite odstaviť.

Z bezpečnostného pohľadu sa tak agent podobá skôr aplikácii alebo digitálnemu pracovníkovi než chatbotu. Má však jednu zvláštnosť: jeho správanie nie je vždy úplne deterministické. Mení sa podľa kontextu, obsahu zdrojov aj postupu, ktorý si model zvolí. Kontroly, ktoré poznáme z IAM, aplikačnej bezpečnosti a dátovej governance, preto netreba zahodiť. Treba ich dôsledne preniesť aj na agentov.

2. Keď sa legitímne funkcie spoja do rizikového reťazca

Dobrou ilustráciou je nepriama prompt injection. Škodlivý pokyn sa v takom prípade nenachádza priamo v otázke používateľa, ale v obsahu, ktorý AI spracúva – napríklad v e-maile, dokumente, webovej stránke alebo formulári. Ak model nerozlíši obsah od inštrukcie, môže sa pokúsiť tento pokyn vykonať.

Napríklad ShareLeak, evidovaný ako CVE-2026-21520, ukázal tento princíp v prostredí Copilot Studio. Škodlivý obsah bol interpretovaný ako pokyn a v kombinácii s prístupom k internému zdroju a povolenou komunikačnou akciou vznikla cesta na odoslanie dát. Konkrétna zraniteľnosť bola opravená a nešlo o potvrdený incident u zákazníkov. Dôležité je : každý krok mohol byť legitímny, no ich kombinácia viedla k neželanému výsledku.

Podobným precedentom bol EchoLeak, CVE-2025-32711, teda výskumný zero-click scenár v Microsoft 365 Copilot. Aj táto chyba bola opravená a nebola potvrdená jej exploitácia v reálnych útokoch. Oba prípady

ukazujú, že nestačí spoliehať len na filtrovanie promptov. Treba obmedziť dáta, nástroje, akcie aj výstupné kanály tak, aby zlyhanie jednej vrstvy neviedlo rovno k úniku informácií alebo k nevratnej zmene.

3. AI zviditeľní starý dlh v oprávneniach

Pri príprave zákazníckych prostredí na Copilot a agentov sa opakujú podobné nálezy: neriadené oprávnenia v SharePointe a Teams, odkazy typu Anyone alebo prístupy pre veľké skupiny, neaktívne lokality bez vlastníka a citlivé dokumenty bez konzistentnej klasifikácie. Nie je to problém, ktorý vytvorila AI. Je to dlh nahromadený počas migrácií, reorganizácií a rokov bežného zdieľania.

Firemná AI pracuje v rámci oprávnení používateľa; nový prístup mu sám nevytvára. Znižuje však bariéru medzi človekom a informáciou, ktorú technicky smie otvoriť. Kedysi musel používateľ vedieť, že dokument existuje, poznať jeho názov alebo aspoň miesto uloženia. AI ho môže nájsť, spojiť s ďalšími podkladmi a zhrnúť v jedinej interakcii.

Riziko teda nie je v tom, že AI obišlo oprávnenia. Riziko je v tom, že “len” využilo oprávnenia, ktoré už dávno nemali existovať. Pred nasadením AI preto nestačí položiť otázku: „Má používateľ prístup?“ Oveľa dôležitejšie je pýtať sa: „Mal by ho ešte stále mať?“

Praktická príprava zahŕňa inventarizáciu zdieľaných a citlivých lokalít, identifikáciu lokalít bez aktívneho vlastníka, revíziu verejných a celofiremných odkazov, odstránenie nepotrebného obsahu a zavedenie zrozumiteľnej klasifikácie. Technológia môže pomôcť s viditeľnosťou a vynútením pravidiel, ale rozhodnutie, kto má mať legitímny prístup, zostáva na vlastníkovi dát.

4. Agent ako nová digitálna identita

Pri používateľovi považujeme za samozrejmosť účet, rolu, pravidlá prístupu, audit a ukončenie účtu pri odchode. Pri produkčnom agentovi potrebujeme podobnú disciplínu. Nestačí vedieť, kto ho vytvoril. Musíme poznať jeho účel, zodpovedného vlastníka a sponzora, rozsah dát, povolené konektory a akcie, komunikačné kanály, rizikovú úroveň aj plán vyradenia.

Microsoft Entra Agent ID je jedným z príkladov, v ktorom sa agenti spravujú ako non-human identity s vlastnými oprávneniami a životným cyklom. Dôležitejší než názov konkrétnej technológie je však výsledok: organizácia musí vedieť priradiť akciu ku konkrétnemu agentovi a ku kontextu, v ktorom konal. Jeho oprávnenia nemajú zostať ukryté v osobnom pripojení tvorcu alebo v nezdokumentovanom workflowe.

Zodpovednosť sa navyše nedá odložiť na neurčitý „AI tím“. Vlastník biznisu potvrdzuje účel a prínos, vlastník dát schvaľuje zdroje, IT alebo platformový tím riadi prostredia a konektory a bezpečnostný či compliance tím nastavuje hranice, monitoring a výnimky. Ak nikto nevie, kto má agenta pravidelne kontrolovať a kto ho môže vypnúť, agent ešte nie je pripravený na produkciu.

5. Praktický rámec: Data – Tools – Actions

Princíp minimálnych oprávnení treba pri agentoch uplatniť v troch samostatných vrstvách. Jedna kontrola nemôže nahradiť ostatné.

Vrstva Kontrolná otázka Príklady

DATA Čo môže agent vidieť? SharePoint, OneDrive, Dataverse, CRM, databázy, e-mail alebo externé znalostné zdroje.

TOOLS Aké nástroje môže použiť? Konektory, API, pluginy, workflowy a služby, cez ktoré získava ďalšie schopnosti.

ACTIONS Čo môže reálne vykonať? Čítať, vytvárať, meniť, mazať, komunikovať externe alebo spustiť transakciu.

Agent, ktorý iba číta vybranú znalostnú bázu, má iný profil než agent s prístupom k e-mailu a CRM. A agent, ktorý môže sám odoslať správu alebo upraviť záznam, má iný profil než agent pripravujúci návrh na schválenie. Hodnotenie rizika preto nesmie skončiť zoznamom dátových zdrojov. Musí zachytiť aj kombinácie nástrojov a možný dosah akcií.

6. Nie každá akcia má byť autonómna

Human-in-the-loop neznamená, že človek mechanicky potvrdí každý krok. Ak mu systém predloží priveľa schválení, kontrola sa rýchlo zmení na formalitu. Rozumnejšie je rozdeliť akcie podľa rizika a podľa toho nastaviť mieru autonómie.

Nízke riziko: Vyhľadanie informácie, sumarizácia alebo príprava návrhu bez zmeny zdrojových dát. Takéto úlohy môžu byť spravidla autonómne.

Stredné riziko: Vytvorenie dokumentu, aktualizácia interného záznamu alebo spustenie vratného procesu. Rozhoduje citlivosť dát, rozsah zmeny a možnosť návratu.

Vysoké riziko: Externá komunikácia, zmena oprávnení, mazanie dát, finančná operácia alebo zásah do kritického systému. Tu má nasledovať explicitné schválenie alebo iná deterministická kontrola.

O tom, či vysoko riziková akcia potrebuje schválenie, by nemal rozhodovať samotný jazykový model. Pravidlo musí byť vynútiteľné mimo jeho uvažovania – v oprávneniach, politike konektorov, pracovnom postupe, transakčnom limite alebo schvaľovacom kroku. Model môže akciu navrhnúť; kontrolná vrstva rozhodne, či ju smie vykonať.

7. Životný cyklus namiesto jednorazového schválenia

Agent nie je hotový v deň publikovania. Menia sa zdroje, konektory, používatelia, inštrukcie aj obchodný účel. Preto potrebuje riadený životný cyklus podobný aplikácii: Design → Test → Approve → Publish → Monitor → Review → Retire.

Design – Je účel jasný? Aké dáta a akcie sú naozaj potrebné? Kto je vlastník a sponzor?

Test – Ako sa agent správa pri neúplnom, neočakávanom alebo škodlivom vstupe? Dá sa jeho zásah vrátiť?

Approve – Schválili vlastníci dát použité zdroje? Zodpovedajú konektory, kanály a autonómne akcie úrovni rizika?

Publish – Kto môže agenta používať a v akom prostredí? Je produkčná verzia oddelená od vývoja?

Monitor – Vieme sledovať používanie, zmeny oprávnení, neobvyklé akcie a prácu s citlivými údajmi?

Review – Je účel stále platný? Sú oprávnenia primerané? Má agent aktívneho vlastníka?

Retire – Ako zrušíme identitu, pripojenia, oprávnenia a publikovanie bez otvoreného prístupu?

Takýto proces nemusí byť byrokratický. Jednoduchý vstupný formulár, riziková úroveň, evidovaný vlastník, zoznam dát a konektorov a krátke rozhodnutie Go/No-Go sú užitočnejšie než zložitá politika, ktorú nikto nepoužíva. Cieľom governance nie je zastaviť tvorbu agentov. Má zabezpečiť, aby sa rýchlosť experimentovania nepremenila na nekontrolovaný produkčný prístup.

8. Päť otázok pre CISO

Pred rozšírením agentov do celej organizácie by mal bezpečnostný tím vedieť jednoznačne odpovedať na päť otázok:

1. Vieme, koľko agentov máme a kto každého z nich vlastní?

2. Vieme, ku ktorým podnikovým dátam každý agent pristupuje a kto tento prístup schválil?

3. Vieme, aké konektory, API a akcie môže používať?

4. Máme určené operácie, ktoré agent nikdy nesmie vykonať bez schválenia?

5. Dokážeme spätne zistiť, čo agent urobil, a v prípade incidentu ho okamžite zastaviť?

Ak organizácia na tieto otázky nevie odpovedať, problémom nie je samotná AI. Problémom je, že chýba riadenie identity, oprávnení a zodpovednosti.

9. Riadenie agentov nie je úplne nová disciplína

Bezpečnostná diskusia o AI sa dlho sústreďovala na to, čo model vie a aké informácie dokáže nájsť. Pri agentoch sa otázka posúva: nejde už iba o to, čo AI vie, ale najmä o to, čo jej dovolíme urobiť.

Dobrou správou je, že organizácie nezačínajú od nuly. Väčšina princípov je prebratá z IAM, Zero Trust, dátovej governance, DLP a aplikačnej bezpečnosti. Nové je najmä to, že ich musia spojiť do jedného funkčného celku a uplatniť na ďalšiu triedu digitálnych identít. Agent môže byť veľmi užitočný virtuálny kolega. Najprv však musí dostať jasnú pracovnú náplň, primerané oprávnenia, dohľad a niekoho, kto zaň nesie zodpovednosť.