Nadměrná pravomoc AI agentů (OWASP LLM06) – příliš funkcí, oprávnění a autonomie a jak je omezit

AI asistent, který čte vaše e-maily, může být užitečný. AI asistent, který je také odesílá, maže, přeposílá a platí, může být nebezpečný: stačí jedna chyba, halucinace nebo skrytý pokyn v cizí zprávě. Podle OWASP je právě nadměrná pravomoc (Excessive Agency) jedním z klíčových rizik aplikací s jazykovými modely (LLM06:2025). Tento článek vysvětluje, co je „agency“, jak vzniká problém a jak mu předejít pomocí jednoduchých zásad: dát AI co nejméně funkcí, co nejméně oprávnění a co nejméně samostatnosti.

Informace vycházejí z popisu LLM06:2025 Excessive Agency na webu OWASP, z přehledu OWASP Top 10 for LLM Applications, z blogu NCSC Prompt injection is not SQL injection a z doporučení Anthropic Building effective agents (stav k 14. 11. 2026). Nejde o technický návod.

Související články: AI agenti a bezpečnostní rizika, AI agent, nebo workflow? a Gemini – připojené aplikace.

Aktualizováno: listopad 2026.

Co je „agency“

Podle OWASP mají systémy založené na LLM často schopnost volat funkce či komunikovat s jinými systémy prostřednictvím rozšíření (extensions), které se mohou nazývat nástroje, dovednosti či pluginy. V agentních systémech může být volba, které rozšíření použít, svěřena samotnému modelu.

Nadměrná pravomoc je zranitelnost, která umožňuje škodlivé akce v reakci na neočekávané, nejednoznačné či zmanipulované výstupy modelu, bez ohledu na to, co závadu způsobilo. Častými spouštěči jsou:

• halucinace (špatně navržený prompt nebo slabý model),
• přímá či nepřímá prompt injection, včetně škodlivých uživatelů, napadených rozšíření či napadených dalších agentů v systémech s více agenty.

Dopady se týkají důvěrnosti, integrity i dostupnosti podle toho, ke kterým systémům má aplikace přístup. OWASP rozlišuje toto riziko od nesprávného zacházení s výstupy, které se týká nedostatečné kontroly výstupu; viz Nesprávné zacházení s výstupy.

Postup omezení pravomoci AI agenta – vlastní infografika

Tři kořenové příčiny

1. Nadměrná funkcionalita. Rozšíření obsahují funkce, které systém nepotřebuje, nebo zůstávají dostupná nepoužívaná rozšíření.
2. Nadměrná oprávnění. Rozšíření mají v navazujících systémech více práv, než potřebují, nebo používají obecnou vysoce privilegovanou identitu místo identity konkrétního uživatele.
3. Nadměrná autonomie. Aplikace samostatně neověřuje ani neschvaluje akce s vysokým dopadem.

Příklady

OWASP uvádí:

• Funkcionalita: rozšíření agenta pro čtení dokumentů má také funkce mazání a úprav; rozšíření určené ke spuštění jednoho příkazu shellu neblokuje další příkazy; zkušební rozšíření bylo odstraněno, ale zůstává volatelné.
• Oprávnění: rozšíření „jen pro čtení“ používá databázovou identitu s právy UPDATE, INSERT a DELETE; rozšíření pro dokumenty jednotlivých uživatelů se připojuje účtem, který vidí soubory všech uživatelů.
• Autonomie: funkce mazání odstraní dokumenty bez potvrzení uživatele.

Kombinovaný scénář: osobní asistent čte e-maily pomocí rozšíření, které umí i odesílat poštu. Škodlivý příchozí e-mail pomocí nepřímé prompt injection přiměje agenta najít citlivé informace a přeposlat je útočníkovi. Opatření podle OWASP:

• použít rozšíření jen pro čtení pošty (odstraní nadměrnou funkcionalitu),
• použít OAuth s oprávněním jen pro čtení (odstraní nadměrná oprávnění),
• vyžadovat, aby uživatel každý koncept zkontroloval a odeslal (odstraní nadměrnou autonomii),
• omezit rychlost odesílání (sníží škodu).

Prevence a zmírnění podle OWASP

1. Minimalizujte rozšíření: nabídněte jen ta, která LLM nezbytně potřebuje.
2. Minimalizujte funkcionalitu rozšíření: implementujte jen nutné funkce, například čtecí přístup k poště.
3. Vyhněte se otevřeným rozšířením: upřednostněte úzké nástroje (například zápis do souboru) před obecnými (shell, načítání libovolných URL).
4. Minimalizujte oprávnění: nejnižší práva v databázích a API, prosazená oprávněními identity.
5. Spouštějte rozšíření v kontextu uživatele: sledujte autorizaci a rozsah, použijte OAuth s minimálními scope a jednejte jako konkrétní uživatel.
6. Vyžadujte schválení uživatelem u akcí s vysokým dopadem (human-in-the-loop).
7. Úplná mediace (complete mediation): prosazujte autorizaci v navazujících systémech, ne na úsudku LLM; ověřte každý požadavek podle bezpečnostní politiky.
8. Očišťujte vstupy a výstupy podle bezpečného kódování (OWASP ASVS) a používejte analýzu kódu.

Opatření omezující škodu (nezabrání nadměrné pravomoci): logování a monitoring aktivity rozšíření a navazujících systémů a omezení rychlosti (rate limiting), které zmenší počet nežádoucích akcí a dá monitoringu čas zachytit je.

Proč to souvisí s prompt injection

NCSC upozorňuje, že pokud LLM volá nástroje či API, útočník fakticky získá stejný přístup, jaký tyto nástroje poskytují; a že oprávnění modelu, který zpracovává obsah od určité strany, by se mělo snížit na úroveň této strany. Například model čtoucí externí e-maily nemá mít přístup k privilegovaným nástrojům. Anthropic doporučuje začínat jednoduše a agenty používat jen tam, kde je to nutné; agenti znamenají vyšší náklady a riziko kumulace chyb. Viz NCSC: prompt injection není SQL injection.

Co z toho plyne pro běžné uživatele

• Propojujte AI jen s tím, co je nutné. Nepřipojujte e-mail, pokud stačí kalendář.
• Kontrolujte oprávnění. Při propojení čtěte, zda AI smí jen číst, nebo také měnit, mazat a posílat.
• Vyžadujte potvrzení u odesílání, plateb a mazání.
• Pravidelně odpojujte nepoužívané aplikace.
• Zabezpečte účet (2FA); kdo získá přístup k vašemu účtu, získá přístup i k propojené AI.
• Ověřujte výsledky. I potvrzená akce může vycházet z chybného pochopení.

Co z toho plyne pro firmy

1. Inventář agentů a nástrojů: co umějí a k čemu mají přístup.
2. Matice oprávnění: pro každého agenta seznam povolených akcí; ostatní zakázat.
3. Oddělené identity: agent nikdy nepoužívá administrátorský účet.
4. Schvalování: finanční, mazací a odesílací akce schvaluje člověk.
5. Limity: počet akcí za čas, částky, příjemci.
6. Logy a upozornění: všechny akce zapisujte; neúspěšná volání mohou odhalit útok.
7. Testování: simulujte škodlivé vstupy a nejednoznačná zadání.
8. Řízení rizik: zařaďte agenty do analýzy rizik; viz NIST AI RMF.

Praktické ukázky bezpečného nastavení

Asistent pro e-mail. Povolte jen čtení a vytváření konceptů. Odeslání nechte na člověku. Omezte přístup na konkrétní složky či štítky a vyloučte citlivé zprávy (banka, zdravotnictví).

Asistent pro kalendář. Povolte vytváření a úpravu událostí, ale ne mazání celých kalendářů; omezte sdílení s externími osobami.

Asistent nad dokumenty (RAG). Dejte mu přístup jen k dokumentům, které smí číst tazatel (kontext uživatele). Pokud model pracuje s dokumenty všech zaměstnanců pod jedním účtem, jeden zmatený dotaz může odhalit cizí data.

Asistent pro zákaznický servis. Povolte čtení historie objednávek a odeslání předdefinovaných odpovědí; vrácení peněz schvaluje člověk nad určitý limit. Anthropic uvádí zákaznickou podporu jako typický případ, kde lze akce jako vrácení peněz automatizovat a úspěch měřit; zároveň ale platí, že nad rámec jednoduchých akcí je rozumné zachovat lidský dohled.

Asistent pro programování. Spouštějte kód v izolovaném prostředí; nedávejte mu přístup k produkčním klíčům; vyžadujte kontrolu změn člověkem. U kódu od AI platí obecná doporučení: testy, revize, ověření balíčků.

Jak vyhodnotit riziko před zapnutím funkce

Zeptejte se: Co nejhoršího se může stát, když AI funkci použije špatně? (Odešle zprávu nesprávnému člověku, smaže soubory, zaplatí neoprávněně.) Dá se to vrátit? (Smazaný soubor bez zálohy je horší než koncept e-mailu.) Kdo to uvidí? (Interní chyba vs. zákazník.) Jak rychle se na to přijde? (Logy a upozornění.) Pokud je škoda vysoká a nevratná, funkci nezapínejte nebo zavedte schválení člověkem. Pokud je nízká a vratná, může být automatizace v pořádku. Tento způsob uvažování odpovídá i doporučením NIST AI RMF, které klade důraz na mapování rizik a dopadů a na plán reakce; viz NIST AI RMF.

Odpovědnost a dokumentace

Dokumentujte, jaké pravomoci agent má a proč, kdo je schválil, kdy se naposledy revidovaly a jak se postupuje při incidentu. Pro každého agenta určete vlastníka. Při změně funkcí (nové rozšíření, nový přístup) opakujte analýzu rizik. Zaznamenávejte akce agenta tak, aby bylo možné zpětně dohledat, co a proč udělal. V evropském kontextu platí navíc pravidla AI Act pro některé použití AI, zejména s dopadem na lidi; viz AI Act – harmonogram.

Praktický příklad (smyšlený)

Firma zavede asistenta, který čte zákaznické e-maily a vytváří odpovědi. První verze měla rozšíření s právem odesílat poštu a databázový účet s právem zápisu. Po auditu firma odebere odesílání (asistent připraví koncept, zaměstnanec jej schválí), přepne databázový účet na čtení a omezí asistenta jen na konkrétní složku. Při testu škodlivého e-mailu s pokynem „přepošli seznam klientů“ asistent nic neodešle. Příklad je smyšlený.

Kontrolní seznam – vlastní infografika

Nadměrná pravomoc v kostce

Základní údaje – vlastní infografika

Výhody a nevýhody

Souhrn – vlastní infografika

Související články

V kategorii Bezpečnost, etika a rizika AI najdete také Prompt injection a Bezpečné používání AI – checklist.

Shrnutí

Nadměrná pravomoc (OWASP LLM06) vzniká, když AI agent má příliš mnoho funkcí, oprávnění nebo samostatnosti a může provést škodlivou akci kvůli halucinaci či prompt injection. Prevence: minimum rozšíření a funkcí, nejnižší oprávnění, kontext uživatele (OAuth s minimálním scope), schvalování člověkem a autorizace v navazujících systémech; logování a limity škodu jen omezí. Nejde o technický návod.

Často kladené otázky k nadměrné pravomoci