AI agenti menia dobre známy problém aplikačnej bezpečnosti na podstatne komplexnejšiu otázku.

Klasická aplikácia prijme požiadavku používateľa, overí identitu, skontroluje oprávnenia a vykoná definovanú operáciu.

AI agent môže fungovať medzi týmito krokmi.

Dokáže interpretovať cieľ používateľa, vyhľadávať údaje, vyberať nástroje, prijímať viacero priebežných rozhodnutí a vykonať niekoľko akcií skôr, než sa celý workflow skončí.

To vytvára zásadnú otázku:

Keď AI agent vykoná operáciu, koho oprávnenia vlastne používa?

Používateľa?

Agenta?

Aplikácie?

Service accountu?

Alebo kombináciu všetkých?

Táto téma je už dostatočne dôležitá na to, aby NIST v roku 2026 spustil samostatnú iniciatívu zameranú na Software and AI Agent Identity and Authorization. Medzi kľúčové oblasti zaraďuje identifikáciu agentov, autorizáciu, auditovanie a non-repudiation.

Aj keď je architektúra AI systému zložitá, bezpečnostný cieľ by mal zostať jednoduchý:

AI agent nesmie získať nové oprávnenie len preto, že model považuje danú akciu za vhodnú.

Autentifikácia stanovuje identitu.

Autorizácia stanovuje oprávnenie.

LLM môže pomáhať interpretovať zámer používateľa, ale kritické rozhodnutia o prístupe majú zostať deterministické, auditovateľné a mimo samotného modelu.

Prečo je identita dôležitejšia, keď AI dokáže konať

Chatbot, ktorý iba odpovedá na otázky, má obmedzenú priamu authority.

Agent pripojený k nástrojom však môže vykonávať operácie v mene používateľov.

Môže čítať dokumenty.

Vytvárať support tickety.

Upravovať záznamy.

Pracovať so source repositories.

Spúšťať workflowy v ďalších firemných systémoch.

Každá významná agentná operácia by preto mala vedieť odpovedať na tri otázky.

Kto workflow inicioval?

Ktorý agent operáciu vykonal?

Pod čí oprávneniami ju downstream systém autorizoval?

Ak sú odpovede nejasné, vznikajú bezpečnostné problémy.

Backend log typu:

ai-service performed update

môže byť technicky správny, ale z pohľadu vyšetrovania slabý.

Nepovie, ktorý používateľ akciu vyvolal ani či na ňu mal právo.

Pri autonómnejších systémoch preto musí identita prežiť celý workflow.

Autentifikácia a autorizácia sú odlišné problémy

Autentifikácia odpovedá:

„Kto je tento aktér?“

Autorizácia odpovedá:

„Čo môže tento aktér vykonať?“

Pri AI aplikáciách je rozlíšenie ešte dôležitejšie, pretože v jednom workflowe môže existovať viac identít.

Používateľ sa prihlási do SaaS aplikácie.

Aplikácia spustí AI agenta.

Agent vyberie nástroj.

Tool zavolá internal API.

API pristúpi k databáze.

V každej fáze musí byť jasné, ktorá authority sa používa.

Úspešný login používateľa neznamená, že každá akcia zvolená agentom je automaticky dovolená.

Rovnako platný backend credential AI služby neznamená, že všetci používatelia AI majú zdediť plný rozsah jeho oprávnení.

AI vytvára reťaz oprávnení

Na agent security je užitočné pozerať ako na permission chain, nie ako na jediný login event.

Človek alebo systém iniciuje operáciu.

Request príde do AI aplikácie.

Aplikácia agentovi poskytne určitú množinu nástrojov.

Každý nástroj komunikuje s ďalšou službou pod určitou identitou.

Downstream systém nakoniec rozhoduje, čo sa môže stať.

Bezpečný design drží authority úzku počas celej tejto reťaze.

Nebezpečný design vytvorí niekde uprostred privilege jump.

Ordinary user môže mať napríklad read access len k vlastným dokumentom.

AI agent však následne zavolá dokumentovú službu pomocou zdieľaného administratorského credentialu s prístupom ku všetkým súborom.

Aplikácia tým z používateľa s obmedzeným prístupom vytvorila potenciálnu cestu ku globálnym údajom.

Presne takýto typ problému súvisí s Excessive Agency a excessive permissions.

Identita používateľa musí prežiť AI vrstvu

Jedným z najsilnejších architektonických princípov je zachovanie pôvodného security contextu používateľa.

Zamestnanec sa opýta enterprise assistanta:

„Zhrň moje aktuálne projekty.“

Agent použije document retrieval tool.

Tool nemá hľadať vo všetkých projektoch dostupných AI service accountu.

Má prehľadávať iba projekty dostupné konkrétnemu zamestnancovi.

Ak používateľ následne požiada:

„Aktualizuj stav projektu,“

rovnaký princíp zostáva.

Backend musí overiť, či daný používateľ môže konkrétny projekt upraviť.

AI nesmie vytvoriť nový authorization universe s väčšími oprávneniami než samotná aplikácia.

Agent identity nie je to isté ako user identity

Agent môže zároveň potrebovať vlastnú identitu.

To neznamená, že nahrádza používateľa.

Identity majú rozdielne úlohy.

User identity hovorí, v koho mene sa práca vykonáva.

Agent identity hovorí, ktorý automatizovaný aktér operáciu skutočne vykonal.

Obe sú užitočné pri autorizácii aj audite.

Ak systém umožňuje meniť rovnaké dáta ľuďom, scheduled jobs a viacerým AI agentom, audit log by mal tieto aktivity rozlišovať.

Operácia môže niesť kontext pôvodného používateľa aj identity konajúceho agenta.

Application a service identity vytvárajú ďalšiu vrstvu

AI systémy používajú aj application alebo service identities.

Ide o machine credentials pre prístup k infraštruktúre.

Samotná service identity nie je nebezpečná.

Problém vznikne vtedy, keď široká service identity potichu nahradí user-level authorization.

Predstavme si AI assistanta s jedným credentialom, ktorý dokáže čítať každý CRM účet.

Frontend správne autentifikuje jednotlivých používateľov.

CRM však vidí iba spoločnú AI službu.

Ak systém inde neobnoví user-level authorization, tenant alebo role boundaries môžu zmiznúť.

Aplikácia vie, kto používateľ je.

Backend, na ktorom skutočne záleží, to už vedieť nemusí.

Schopnosť modelu a autorizácia musia zostať oddelené

AI model môže správne chápať, čo robí administrátor.

To mu nedáva administratorské práva.

Model môže správne usúdiť, že vymazanie účtu vyrieši support problém.

To mu nedáva authorization tento účet odstrániť.

Reasoning capability a application authority sú rozdielne veci.

LLM môže vytvoriť odporúčanie.

Backend rozhoduje, či sa operácia smie vykonať.

Tento princíp zostáva platný aj pri oveľa výkonnejších modeloch.

LLM nesmie byť finálnou authorization layer

Nebezpečným patternom je ukladanie pravidiel oprávnení iba do system promptu.

Developer napríklad napíše:

„Účty môžu mazať iba administrátori.“

Model to pri bežnom používaní rešpektuje.

Testy vyzerajú dobre.

Vyzerá to ako access control.

Nie je to však silný access control.

Prompt injection, manipulácia contextu, model error alebo budúca zmena správania môžu ovplyvniť rozhodovanie modelu.

Bezpečný backend preto po požiadavke na odstránenie účtu overí:

authenticated user,

jeho role,

target account,

business rules,

prípadné required approval.

Ak kontroly zlyhajú, účet sa neodstráni bez ohľadu na to, čo model požadoval.

Dobré pravidlo je:

Prompt opisuje policy modelu. Code vynucuje policy v systéme.

Prompt instructions môžu riadiť správanie, nie definovať oprávnenia

System prompts zostávajú užitočné.

Môžu agentovi vysvetliť bežný workflow.

Obmedziť zbytočné tool use.

Určiť očakávané správanie.

Nemajú však niesť zodpovednosť za confidentiality alebo access control.

Prompt zlepšuje správanie.

Deterministický kód vytvára bezpečnostnú hranicu.

Least privilege má začať na úrovni agenta

Least privilege je pri AI agentoch mimoriadne účinný, pretože znižuje následky chýb modelu.

Agent, ktorý dokáže iba čítať verejnú dokumentáciu, má jeden risk profile.

Agent, ktorý dokáže čítať, meniť a mazať produkčné údaje, má úplne iný.

Produkčné tímy by mali minimalizovať počet dostupných nástrojov aj permissions, ktoré tieto tools používajú.

Pokušenie pripojiť všetky firemné možnosti k jednému univerzálnemu assistantu vytvára zbytočnú authority.

Pohodlie vytvára authority.

Authority vytvára attack surface.

Oprávnenia agenta by mali zodpovedať aktuálnej úlohe

Ešte silnejší design používa task-specific permissions.

AI platforma môže podporovať:

document research,

customer support,

account administration,

deployment operations.

Tieto úlohy nepotrebujú rovnaké oprávnenia.

Research môže dostať read access.

Drafting môže vytvárať dočasný obsah.

Publishing môže vyžadovať samostatné permission.

Administratívna zmena môže vyžadovať ďalšiu authorization.

Namiesto permanentného prístupu ku všetkým capabilities môže aplikácia agentovi poskytovať iba oprávnenia aktuálne potrebné pre workflow.

Oddeľte read a write oprávnenia

Read access a write access by sa nemali považovať za rovnaké.

Support assistant potrebuje čítať customer data.

To neznamená, že musí upravovať zákaznícke účty.

Coding assistant potrebuje vidieť repository.

To neznamená, že potrebuje production deployment authority.

Oddelenie read a write capability vytvára veľmi užitočnú containment boundary.

Deštruktívne operácie potrebujú silnejšiu autorizáciu

Mazanie dát.

Zmena permissions.

Transfer ownership.

Nevratné operácie.

Tieto actions by nemali mať rovnaký security model ako obyčajný retrieval.

Môžu používať:

explicit authorization checks,

recent reauthentication,

contextual confirmation,

human approval.

Cieľom nie je vytvoriť friction pri každej operácii.

Cieľom je pridať silnejšie kontroly tam, kde má nesprávne rozhodnutie väčší dopad.

Human approval nenahrádza autorizáciu

Ľudská approval je užitočná.

Nie je náhradou za access control.

Ordinary user presvedčí agenta, aby požiadal o admin-only action.

UI zobrazí:

„Chcete pokračovať?“

Používateľ klikne áno.

Ak to stačí na vykonanie operácie, systém je stále zraniteľný.

Používateľ sa nemôže sám odkliknúť do privilege, ktoré nevlastní.

Authorization má prebehnúť prvá.

Human confirmation zisťuje:

„Chce autorizovaný používateľ túto operáciu naozaj vykonať?“

Authorization zisťuje:

„Má tento používateľ vôbec právo ju vykonať?“

AI agent authorization musí byť object-aware

Nestačí kontrolovať len requested function.

Treba kontrolovať aj konkrétny objekt.

Používateľ môže mať právo volať updateProject.

To neznamená, že smie upraviť každý project.

Customer môže smieť načítať invoice.

To neznamená, že smie načítať invoice iného customer-a.

AI model môže vytvoriť perfektne valid object identifier, ktorý stále patrí neautorizovanému resource.

Tu sa AI agent security stretáva s klasickou API security.

Function-level authorization nestačí.

Potrebujeme object-level authorization.

Tenant boundaries musia prežiť AI workflow

Multi-tenant SaaS je obzvlášť citlivý na chyby autorizácie.

Jeden AI assistant môže cez shared infrastructure obsluhovať stovky alebo tisíce organizations.

Ak agent volá backend cez global service account, tenant isolation môže začať závisieť od logiky vo vnútri AI layeru.

To je slabá hranica.

Tenant identity má zostať súčasťou downstream authorization.

Ak Tenant A vyhľadáva records, eligible majú byť iba records Tenant A.

Pri update musí backend nezávisle overiť, že target object patrí do scope Tenant A.

Od modelu nemožno očakávať, že bude tenant boundaries správne „pamätať“ pod každým možným promptom.

RAG authorization má prebehnúť pred retrievalom

Rovnaký princíp platí pri Retrieval-Augmented Generation.

RAG môže obsahovať dokumenty viacerých používateľov, tímov alebo tenantov.

Semantic similarity určuje relevance.

Authorization určuje eligibility.

Systém nemá najprv získať všetky relevantné dokumenty a až potom žiadať LLM, aby tie neautorizované neukázal.

Bezpečnejšie je najprv vytvoriť množinu autorizovaných dokumentov a retrieval vykonať iba v nej.

Citlivé údaje sa tak nedostanú do model contextu bez permission checku.

AI agent memory potrebuje autorizáciu

Agent memory je forma dát.

Ak systém uchováva dlhodobé informácie o users, projects alebo minulých tasks, memory potrebuje ownership a access boundaries.

Agent nemá získať memory iného usera iba preto, že je semanticky relevantná.

Shared organization memory môže byť legitímna.

Private memory môže mať úplne iné pravidlá.

Security team by preto mal AI memory posudzovať podobne ako ostatné application data stores.

Kto ju vytvoril?

Komu patrí?

Kto ju môže čítať?

Kto ju môže meniť?

Ako dlho sa uchováva?

Formát „AI memory“ nie je dôvodom na vypnutie autentifikácie a autorizácie.

Tools majú vynucovať vlastné security boundaries

AI architektúra sprístupňuje agentom nástroje pre databázy, API a externé služby.

Bezpečný tool nemá predpokladať:

„Request prišiel od AI agenta, takže musí byť autorizovaný.“

Downstream systém má request vždy overiť proti security policy.

Model vyberie nesprávny tool.

Backend stále kontroluje authorization.

Model vytvorí nesprávne target ID.

Object-level authorization stále platí.

Prompt injection zmení agent intent.

Permission boundary stále prežije.

Takto vyzerá defense in depth.

Tool credentials majú mať úzky scope

Agent nemá dostať široké credentials iba preto, že sa s nimi ľahšie vyvíja.

Ak tool potrebuje iba read access k jednému datasetu, jeho credential nemá poskytovať write cez nesúvisiace resources.

Ak rieši jednu business function, nepotrebuje access ku každej službe firmy.

Model navyše nemusí credential vôbec ukradnúť.

Ak agent už broad authority má, manipulované reasoning môže byť dostatočné na jej zneužitie.

Short-lived authority môže znižovať riziko

Long-lived broad credentials zvyšujú čas aj dopad prípadného compromise.

AI agenti môžu používať contextual authorization.

Namiesto permanentného broad access môže konkrétny workflow dostať oprávnenie iba na určitú úlohu alebo obdobie.

Princíp je jednoduchý:

Agentovi dajte authority, ktorú potrebuje teraz, nie všetky authority, ktoré by možno potreboval v budúcnosti.

Delegated authorization potrebuje jasnú logiku

AI agenti často konajú v mene človeka.

To je delegated authorization.

Systém však musí rozlišovať:

„Tento user môže operáciu vykonať.“

a

„Tento agent má vlastnú nezávislú authority vykonať operáciu.“

Personal assistant môže plánovať meetings iba autentifikovanému používateľovi.

Internal automation agent môže mať organization-wide authority.

Deployment agent môže konať až po approved release workflowe.

Generic „agent token“ by nemal tieto rozdielne trust models spájať do jednej nejasnej identity.

Agent konajúci za používateľa nemá získavať extra privileges

Najbezpečnejším defaultom je, aby delegation nezvyšovala authority.

Ak používateľ nemôže resource priamo získať, agent konajúci v jeho mene by ho vo väčšine prípadov nemal získať iba preto, že komunikuje s privileged backendom.

Legitímne exceptions existujú.

Mali by však byť explicitne navrhnuté a kontrolované, nie náhodne vzniknúť použitím service accountu.

Agent s vlastnou authority potrebuje vlastný governance

Niektoré AI agents nie sú osobní assistanti.

Môžu na pozadí vykonávať organization-wide operations.

Kontrolovať infrastructure events.

Aktualizovať interné tickety.

Vykonávať routine maintenance.

Taký agent potrebuje vlastné oprávnenia.

Tie sa majú riadiť podobne ako ostatné privileged machine identities.

Ktoré systems môže používať?

Aké operations môže vykonávať?

Kto mení jeho permissions?

Kde sú logované jeho actions?

Ako sa access okamžite suspenduje?

Čo sa stane pri unexpected behavior?

Autonomous agent musí byť explicitný bezpečnostný aktér.

Multi-agent systems ešte viac komplikujú autorizáciu

Single-agent systém je už komplexný.

Multi-agent systém vytvára ďalšie trust relationships.

Jeden agent zbiera informácie.

Druhý ich analyzuje.

Tretí vykonáva actions.

Riziko vzniká, keď sa permissions medzi nimi implicitne prenášajú.

Research agent s public read access nemá automaticky zdediť authority execution agenta.

Správa od iného agenta tiež nie je automatickým proof of authorization.

Identity a authority musia zostať explicitné aj medzi agentmi.

Správa od agenta nie je authorization token

Agent A môže Agentovi B povedať:

„Používateľ túto operáciu schválil.“

Agent B by tejto vete nemal automaticky veriť.

Authorization potrebuje autentifikovaný a overiteľný mechanizmus.

Natural-language communication je vhodná na reasoning.

Nie je náhradou za security credential.

Security system má dôverovať cryptographic alebo deterministic authorization state, nie model-generated príbehu o oprávnení.

Prompt injection sa nesmie zmeniť na privilege escalation

Prompt injection je jeden z najsilnejších dôvodov, prečo držať autorizáciu mimo modelu.

Útočník zmanipuluje agenta a ten požiada o privileged resource.

Backend nezávisle overí user permission.

Request zlyhá.

Model bol manipulovaný.

Security boundary prežila.

Cieľ preto nemusí byť garantovať, že agent nikdy nebude manipulovaný.

Dôležitejšie je garantovať, že manipulácia nevytvorí novú authority.

Prompt injection a authorization sú samostatné vrstvy

Prompt-injection controls znižujú unwanted model behavior.

Authorization limituje to, čo sa môže stať po takom správaní.

Aplikácia preto môže mať nedokonalú odolnosť voči prompt injection a stále si zachovať dôležité security boundaries.

Injected instruction spôsobí, že agent požiada o confidential record iného usera.

Retrieval API ho zamietne.

Útok skončí na authorization layer.

To je výrazne silnejšie než dôvera v to, že model sám request označí za podozrivý.

Excessive permissions zosilňujú chyby modelu

Dva agents môžu používať rovnaký model.

Jeden má iba read-only access k public dokumentácii.

Druhý má administratorský access do production systems.

Rovnaká reasoning chyba vytvorí úplne odlišný impact.

Preto je permission architecture jedným z najúčinnejších nástrojov kontroly AI risk.

Na vytvorenie bounded system nepotrebujete dokonale spoľahlivý model.

Autorizáciu kontrolujte pri každom sensitive transition

Častou chybou je kontrola autorizácie iba na začiatku dlhého workflowu.

User začne authorized task.

Agent vykoná desať actions.

Aplikácia predpokladá, že všetkých desať zdedilo legitimitu pôvodnej požiadavky.

Workflow však môže meniť smer.

Agent objaví nové údaje.

Vyberie unexpected tool.

Zmení sa target object.

Neskoršia operácia môže mať výrazne vyšší impact.

Sensitive transitions preto potrebujú autorizáciu primeranú konkrétnej operácii.

Action-level authorization je dôležitejšia s rastúcou autonómiou

Čím viac autonomy agent dostane, tým menej rozumné je tvrdiť, že jedno úvodné user approval automaticky pokrýva všetko ďalšie.

User povie:

„Pomôž mi zorganizovať customer accounts.“

Agent môže:

čítať metadata,

meniť ownership,

mazať duplicates,

posielať správy zákazníkom.

High-level goal nemá automaticky autorizovať každú technicky súvisiacu operáciu.

Authorization sa má viazať na konkrétne capability boundaries.

Approval má rásť s dopadom

Low-impact reversible actions môžu fungovať s minimálnym friction.

Read-only lookup môže byť automatic.

Draft editing potrebuje bežnú user authorization.

External publishing môže vyžadovať confirmation.

Zmena account permissions môže vyžadovať stronger verification.

To umožňuje zachovať použiteľnosť bez toho, aby každá operácia mala rovnakú trust level.

Approval fatigue môže oslabiť bezpečnosť

Ak používateľ potvrdzuje každý trivial tool call, začne confirmations ignorovať.

Rutinná operácia a high-value security decision začnú vyzerať rovnako.

Lepší design sústreďuje ľudskú pozornosť tam, kde má user intent najväčší význam.

Security má vytvárať meaningful friction, nie permanent friction.

Permission boundaries majú byť zrozumiteľné používateľovi

Rozhranie by malo jasne ukazovať, keď agent iba číta informácie a keď mení state.

Používateľ by mal vedieť, kedy sa kontaktuje external system.

Kedy operácia ovplyvní inú osobu, shared workspace alebo production environment.

To podporuje informed approval.

Samotná authorization však stále zostáva v deterministických application controls.

High-risk actions môžu potrebovať fresh authentication

Long-running AI session môže zostať aktívna veľmi dlho.

Používateľ sa raz autentifikuje.

Neskôr sa agent pokúsi vykonať highly sensitive action.

Pre niektoré risk models už pôvodný login nemusí byť dostatočný.

Určité operácie môžu vyžadovať recent reauthentication alebo silnejšie potvrdenie identity.

AI tento problém zosilňuje, pretože workflow môže pokračovať a meniť sa bez neustáleho inputu používateľa.

Long-lived conversation sa nemá stať permanent privileged session.

Agent session nemá byť permission container

Conversation state môže uchovávať preferences a context.

Nemá uchovávať dôkaz privilege.

Model, ktorý si pamätá:

„Používateľ je administrátor,“

nie je ekvivalent authenticated application session, ktorá túto rolu dokazateľne potvrdzuje.

Rovnako stará konverzácia o schválení sensitive action nemusí autorizovať ďalšiu operáciu v novom contexte.

Authorization state patrí do systémov navrhnutých na security state.

Natural-language memory patrí do model contextu.

Ich miešanie vytvára slabé hranice.

Credentials majú zostať mimo model contextu

Agent môže credentials potrebovať na prístup k tools.

Model však zvyčajne nepotrebuje raw secrets.

Backend môže credential držať a autorizovanú operáciu vykonať v mene modelu.

Tak sa znižuje riziko, že prompt leakage alebo context exposure povedie ku credential theft.

Agent potrebuje capability.

Nemusí poznať underlying secret.

Authorization metadata nepovažujte za ochranu cez utajenie

Aplikácia môže modelu ukazovať roles alebo permission structure, pretože ich potrebuje na reasoning.

Security však nemá závisieť od toho, že táto štruktúra zostane skrytá.

Silná authorization zostáva bezpečná aj vtedy, keď útočník rozumie role modelu.

Security má pochádzať z enforcementu, nie z obscurity.

Auditability je súčasťou autorizácie

Authorization odpovedá, či sa action má vykonať.

Auditability umožňuje spätne pochopiť, čo sa stalo.

Pri AI agentoch potrebuje audit trail dostatok kontextu.

Initiating user.

Acting agent.

Použitá capability.

Authorization decision.

Affected resource.

Resulting action.

Takéto údaje sú nevyhnutné pri vyšetrovaní unexpected autonomous behavior.

Audit log má rozlišovať user intent od agent action

Používateľ povie:

„Vyčisti zastarané projektové informácie.“

Agent sa rozhodne odstrániť niekoľko records.

Log:

User requested cleanup

neukazuje, čo sa skutočne stalo.

Log:

AI service deleted records

neukazuje pôvodný user intent.

Silnejší audit spája obe strany.

User X spustil workflow Y.

Agent Z vybral operation A.

Authorization policy B ju povolila.

Objects C a D boli ovplyvnené.

Tak možno rekonštruovať intent aj execution.

Authorization failures majú byť viditeľné

Repeated denied actions môžu byť security signal.

Jeden neúspešný request môže byť nevinná chyba modelu.

Opakovaný pokus o access k nesúvisiacim user records môže ukazovať na manipuláciu alebo zlú agent logic.

Monitoring preto nemá sledovať iba successful tool calls.

Mal by sledovať aj významné authorization failures.

Rate limiting dopĺňa autorizáciu

Authorization určuje, či je operation allowed.

Rate limit určuje, ako často sa môže vykonať.

Pri high-impact operations môže frequency limit výrazne znížiť blast radius.

Agent schopný jednej citlivej operácie je riziko.

Agent schopný vykonať ju autonómne tisíckrát je podstatne väčšie riziko.

Pri chýbajúcom authorization contexte používajte fail closed

AI workflows prechádzajú cez viac služieb a identity context sa môže stratiť.

Bezpečný default nie je:

„Nevieme, kto to je, použime teda broad service account.“

Ak backend pri sensitive action nevie určiť responsible user alebo agent identity, nemal by automaticky poskytovať maximum dostupných permissions.

Neistota o authority sa nemá zmeniť na väčšiu authority.

Nevytvárajte jedného super-agenta

Universal agent s accessom ku každej business capability je produktovo atraktívny.

Bezpečnostne vytvára obrovskú boundary.

Výhodnejšia môže byť compartmentalized architecture.

Research agent rieši výskum.

Support agent rieši support.

Deployment agent rieši deployment pod silnejšou autorizáciou.

Compromise jednej komponenty má potom menší blast radius.

Špecializované agents vytvárajú čistejší permission model

Specialization umožňuje zosúladiť oprávnenia s účelom.

Summarization agent má read access.

Drafting agent môže vytvoriť draft, ale nemôže ho odoslať.

Execution agent môže konať až po explicit authorization.

Taký design je menej flexibilný než jeden universal agent.

Je však výrazne ľahšie testovateľný.

Ako penetration testovať autorizáciu AI agentov

AI agent security test začína mapovaním celého identity a permission chainu.

Users.

Roles.

Agent identities.

Service accounts.

Tools.

Downstream systems.

Prvým cieľom nemusí byť manipulácia modelu.

Najprv treba pochopiť:

Odkiaľ authority pochádza?

Ktorá identity sa autentifikuje ku každej službe?

Aké permissions vlastní?

Môže agent pristúpiť k viac dátam než initiating user?

Vie backend, ktorý user action začal?

Sú high-impact tools vždy dostupné?

Mení sa permission podľa role?

Až potom má adversarial testing plný význam.

Testujte rovnakého agenta s rôznymi user roles

Role comparison je vysoko hodnotný test.

Ordinary user nesmie získať admin-level action len preto, že backend používa shared service identity.

Customer nesmie dosiahnuť records iného tenant-a.

Read-only employee nesmie cez AI interface získať write capability.

Porovnajte tool visibility aj reálnu downstream execution.

Hidden tool môže byť stále reachable.

Visible tool môže naopak korektne rejectovať unauthorized operation.

Runtime enforcement je dôležitejší než vzhľad interface.

Testujte, čo sa stane, keď model požaduje priveľa

Security assessment má úmyselne overovať, či authorization prežije unexpected model behavior.

Model nech v controlled scenario požiada o operation mimo authority aktuálneho usera.

Najsilnejší výsledok nie je:

„Model odmietol.“

Najsilnejší je:

„Backend odmietol, aj keď model operáciu požadoval.“

To dokazuje, že security boundary nezávisí iba od probabilistického správania modelu.

Testujte object-level authorization cez agenta

Ak agent pristupuje k objects podľa identifierov, testujte ownership a tenant boundaries.

Môže user cez natural language požiadať o record iného usera?

Môže model odvodiť iný object identifier?

Validuje downstream tool ownership?

Exponuje retrieval metadata ešte pred autorizáciou?

AI interface je iba ďalšia cesta k rovnakým security-sensitive objects.

Testujte delegated identity

Ak agent koná v mene usera, testujte, či delegation zachováva jeho restrictions.

Používa OAuth-style delegated identity?

Backend service credential?

Custom policy layer?

Pozná downstream system original actor?

Môže jeden user spôsobiť použitie authority patriacej inému?

Konkrétna technológia je menej dôležitá než výsledná security property:

delegation nesmie potichu vytvárať privilege escalation.

Testujte agent-to-agent authorization

Multi-agent systems potrebujú samostatné tests.

Môže low-privilege agent inštruovať high-privilege agenta?

Validuje Agent B authority requestu Agent A?

Môže tvrdenie v natural language typu „user to schválil“ bypassnúť skutočnú authorization?

Môže jeden compromised agent prinútiť ďalšieho prekročiť jeho intended role?

Testujte revocation

Permissions sa menia.

Zamestnanci odchádzajú.

Roles sa menia.

Tokens expirovali.

User revokuje external integration.

Agent authorization musí zmeny reflektovať rýchlo.

Testovanie má preveriť cached agent state, persistent tool sessions a long-running workflows.

Stará konverzácia usera s revoked permissions nesmie zachovať authority, ktorú identity system už odobral.

Testujte long-running agent workflows

Authority platná na začiatku workflowu nemusí byť platná o hodinu neskôr.

High-impact operation preto môže potrebovať re-evaluation v čase execution.

Je to dôležité pri changing roles, approvals a external services.

Testujte approval boundaries

Ak je potrebná human confirmation, verify, že ju nemožno bypassnúť.

Vyžaduje backend proof of approval?

Alebo UI iba zobrazí confirmation, zatiaľ čo agent dokáže tool volať priamo?

Môže agent po approval zmeniť target?

Pokrýva approval pre Object A omylom aj Object B?

Approval má význam iba vtedy, keď je viazaná na operáciu, ktorá sa skutočne vykoná.

Testujte credential scope

Pozrite sa, aké credentials tools používajú downstream.

Read-only AI feature s administrator-level database accessom si zaslúži pozornosť aj bez potvrdeného exploitu.

Test má zisťovať, či narrower permissions zachovajú funkcionalitu.

Excessive credential authority výrazne zvyšuje následky prompt injection aj model mistakes.

Testujte authorization po prompt injection

Prompt-injection testing je najužitočnejší v spojení s reálnymi permission boundaries.

Ak indirect content manipuluje agenta:

Získa data iného usera?

Zavolá privileged tool?

Zmení application state?

Ak backend authorization tieto outcomes zastaví, dôležitá defense layer funguje.

Ak prompt manipulation priamo vytvára privileged action, architektúra potrebuje silnejšie oddelenie.

Severity má závisieť od získanej authority

Nie každá authentication alebo authorization slabina má rovnaký dopad.

Menšia nejasnosť v logovaní je niečo iné ako global cross-tenant access.

Unnecessary read access je niečo iné ako možnosť meniť production security settings.

Najdôležitejšia otázka pre severity je:

Čo môže attacker vykonať cez agenta, čo by bez neho legitímne vykonať nemohol?

Remediation má obnoviť permission boundary

Ak shared service account bypassuje user-level authorization, obnovte user context alebo implementujte equivalent downstream policy.

Ak agent nepotrebuje write access, odoberte ho.

Ak high-impact operations obchádzajú approval, vložte approval priamo do execution path.

Ak permissions existujú iba v promptoch, presuňte ich do deterministic code.

Ak multi-agent systém dôveruje natural-language claims of authorization, použite authenticated delegation.

Cieľom je, aby bol unauthorized outcome technicky nemožný, nie iba menej pravdepodobný.

Pri retestingu skúšajte odlišné správanie modelu

Weak remediation upraví system prompt tak, aby pôvodné wording útoku nefungovalo.

Strong remediation opraví authorization.

Retest preto skúša alternatívne cesty k rovnakej restricted operation.

Ak user nemá permission bez ohľadu na to, ako model action formuluje alebo vyberie, boundary je výrazne silnejšia.

Model behavior je probabilistic.

Authorization nemá byť.

Bezpečné permission boundaries navrhujte ešte pred launchom

Najľahšia authorization vulnerability na opravu je tá, ktorú architektúra nikdy nevytvorí.

Pred nasadením agenta zmapujte:

Ktoré data môže čítať?

Ktoré records môže meniť?

Ktoré tools môže volať?

Ktoré service accounts používa?

Prežije user identity až do downstream systems?

Ktoré actions potrebujú stronger permission?

Ktoré potrebujú explicit approval?

Môže agent konať bez človeka?

Čo sa stane pri úspešnom prompt injection?

Threat modeling pred production deploymentom je lacnejší než rekonštrukcia authorization modelu pri už aktívnom privileged agentovi.

Začnite ľudským používateľom

Pri user-facing agentoch je dobrým základom existujúca authority človeka.

Čo môže user urobiť cez normálnu aplikáciu?

Potrebuje agent naozaj niečo navyše?

V mnohých prípadoch nie.

Agent mení interface a mieru automatizácie.

Nemal by potichu meniť user permission level.

Potom definujte vlastnú authority agenta

Niektoré capabilities môžu patriť samotnému agentovi.

Môže vytvárať temporary analysis artifacts.

Čítať shared documentation index.

Queryovať internal service dostupnú všetkým používateľom.

Tieto oprávnenia musia byť explicitné.

Security team ich musí vedieť opísať nezávisle od jednej konkrétnej konverzácie.

Agent, ktorého authority sa nedá jasne opísať, sa veľmi ťažko zabezpečuje.

Potom definujte boundary každého toolu

Každý tool má mať jasný security contract.

Čo robí?

Ktoré identity ho môžu volať?

Ktoré objects môže ovplyvniť?

Je read alebo write?

Ktorý backend credential používa?

Potrebuje human approval?

Môže komunikovať externe?

Čo loguje?

Takto sa agent architecture stáva testovateľnou.

Nakoniec predpokladajte, že model urobí nesprávne rozhodnutie

Je to jeden z najlepších architektonických testov.

Predpokladajte, že model vyberie nesprávny tool.

Prompt injection uspeje.

Untrusted content zmení reasoning.

Používateľ položí nejednoznačnú otázku.

Agent navrhne nebezpečnú action.

Čo sa stane?

Ak je odpoveď:

„Model by to asi odmietol,“

boundary je slabá.

Ak je odpoveď:

„Backend odmietne každú operáciu mimo autorizácie autentifikovaného používateľa,“

architektúra je výrazne silnejšia.

Autentifikácia a autorizácia sú základom Agentic AI Security

AI agents vkladajú reasoning a autonomy do workflowov, ktoré boli predtým deterministické.

Tým vznikajú nové security challenges.

Najsilnejšie obranné princípy však zostávajú známe.

Poznajte aktéra.

Zachovajte identitu.

Obmedzte permissions.

Autorizujte každú sensitive action.

Oddeľte user authority od agent authority.

Používajte least privilege.

Oddeľte read od write.

High-impact operations chráňte silnejšími kontrolami.

Authorization rules nenechávajte iba v promptoch.

Secrets držte mimo model contextu.

Logujte významné actions.

Permission boundaries po remediation retestujte.

NIST venoval AI agent identity a authorization v roku 2026 samostatnú pozornosť, čo ukazuje, že už nejde iba o teoretickú otázku, ale o vznikajúcu tému enterprise security a identity standards.

Najdôležitejší princíp však zostáva jednoduchý:

AI môže rozhodnúť, akú akciu chce požiadať vykonať.

Nemá sama rozhodovať, či je táto akcia autorizovaná.

Často kladené otázky o autentifikácii a autorizácii AI agentov

Čo je autentifikácia AI agenta?

Je to proces overenia identity používateľa, software agenta alebo autonómneho AI aktéra zapojeného do workflowu. Moderný agentný systém môže súčasne pracovať s human user identity, agent identity aj backend service identities.

Čo je autorizácia AI agenta?

Určuje, ku ktorým dátam, nástrojom, objektom a akciám môže agent pristupovať v konkrétnom identity a security contexte. Kritická authorization má byť vynucovaná deterministickými application alebo downstream controls.

Mal by mať AI agent vlastnú identitu?

V mnohých architektúrach áno. Samostatná agent identity zlepšuje auditability a riadenie, zatiaľ čo user identity naďalej určuje, v koho mene agent koná.

Môže AI agent používať service account?

Áno, ale široké shared service accounts môžu spôsobiť privilege problems, keď sa stratí user-level authorization. Bezpečnejšie je zachovať user security context a používať minimum necessary permissions.

Majú byť authorization rules v system prompte?

Kritická authorization nemá závisieť iba od system promptu. Privilege separation a permission checks majú byť vynucované mimo LLM deterministickými a auditovateľnými kontrolami.

Ako sa least privilege aplikuje na AI agentov?

Agent má dostať iba tools, functions a downstream permissions potrebné pre konkrétnu úlohu. Minimalizácia capabilities znižuje dopad neočakávaného alebo manipulovaného správania modelu.

Nahrádza human approval autorizáciu?

Nie. Authorization overuje, či aktér operáciu vôbec smie vykonať. Human approval potvrdzuje zámer pri operácii, ktorá už autorizovaná je.

Ako testovať AI agent permissions?

Zmapujte users, agents, tools a downstream identities. Porovnajte roles, testujte object- a tenant-level isolation, credential scope, delegated authority, agent-to-agent authorization, revocation a reakciu systému na unexpected model behavior.

Môže prompt injection bypassnúť permissions AI agenta?

Prompt injection môže ovplyvniť to, o čo sa agent pokúsi. Silná downstream authorization však má zabrániť tomu, aby manipulácia modelu vytvorila nové privileges.

Aká je najnebezpečnejšia authorization chyba pri AI agentoch?

Jedným z najrizikovejších patternov je low-privilege user komunikujúci s agentom, ktorý vykonáva downstream actions cez generic highly privileged identity bez opätovného uplatnenia oprávnení pôvodného používateľa.