Oprávnění nástrojů AI agenta: jak řídit, které nástroje smí volat

Připojte AI agenta k MCP serveru a ve výchozím stavu může volat každý nástroj, který ten server nabízí. Přečíst soubor, smazat repozitář, zrušit tabulku v databázi, napsat do zákaznického kanálu. Z pohledu protokolu jsou to všechno jen položky v jednom seznamu a agent smí zavolat kteroukoli z nich. U hobby projektu to nevadí. U regulované firmy je to první věc, na kterou bezpečnostní review upozorní, protože „agent smí zavolat cokoli, co jsme připojili“ není model oprávnění. Znamená to, že žádný nemáte.

Narazili jsme na to v praxi. Regulovaná firma, se kterou děláme POC MCP Gateway, se zeptala přesně na to: může agent většinu nástrojů používat volně, pár jich mít úplně zakázaných a u zbytku počkat, až mu volání schválí člověk? Může, ale ne na straně klienta. Odpověď vede přes mechanismus MCP elicitation a končí na gateway. A to, co na tom zatím drhne, nemá se specifikací nic společného.

Jeden MCP server může nabízet dvacet i víc nástrojů. Napojte na agenta dva nebo tři servery a najednou má po ruce padesát schopností. Většinu z nich k zadanému úkolu nikdy nepotřebuje. Některé nástroje jenom čtou a nic nezkazí. Jiné mažou, mění nebo zakládají věci, u kterých je chyba drahá.

Výchozí chování MCP zachází se všemi stejně. Co je zaregistrované, to se dá zavolat. Tím se dvě úplně jiné otázky slijí do jedné. Dosáhne agent na ten nástroj? A smí ho spustit bez člověka ve smyčce? Firmy potřebují obě otázky oddělit. Skoro vždycky si proto říkají o tři stavy u každého nástroje:

Zajímavý je ten třetí stav. Právě u něj přichází ke slovu mechanismus přímo v protokolu.

Specifikace MCP má mechanismus jménem elicitation: strukturovaný způsob, jak se server uprostřed operace zastaví a zeptá se člověka, než bude pokračovat. Volání nástroje normálně proběhne na jeden zátah, agent zavolá a server vrátí výsledek. S elicitation může server uprostřed říct „než tohle spustím, potřebuji potvrzení od člověka“ a poslat ten dotaz přes klienta zpátky uživateli.

Přesně to potřebuje stav „vyžaduje schválení“. Zakázáno a povoleno jsou statická pravidla, rozhodne se o nich dopředu. „Vyžaduje schválení“ je dynamické: musí přerušit běžícího agenta, dostat se k člověku, počkat na ano, nebo ne, a teprve pak volání pustit dál. Elicitation je odpověď protokolu právě na vzorec „zastav se a zeptej“.

Prokop Simek, který u nás vede produktové a UX uvažování, pojmenoval princip, podle kterého to stavíme. Nástroje, které jenom čtou, se mají schvalovat automaticky. Nic nezkazí, takže nutit u nich někoho do potvrzování je zbytečné otravování. Nástroje, které mažou, mění nebo zakládají, jsou druhý případ. Tam má uživatel dostat možnost akci nejdřív potvrdit. Platí to hlavně o tom, kdo se s AI teprve učí pracovat.

Claude Desktop už jednu variantu tohoto přístupu umí nativně, po jednotlivých konektorech. Problém je, že „per konektor, v jednom konkrétním klientovi“ firmě nestačí.

Požadavek od zákazníka byl přímočarý. Miloš Halda, který ho implementoval, ho popsal takto:

Poslední věta shrnuje celý inženýrský problém. Čistá cesta je flag v metadatech nástroje, který klientovi řekne, ať volání nechá potvrdit uživatelem. V Claudovi funguje. Všude jinde ho klient bez varování ignoruje. Zákazníkovi, který se nesjednotil na jediném AI harnessu, je model oprávnění platný v jednom klientovi k ničemu. Schvalování se proto muselo přesunout na gateway, tedy tam, kudy prochází každý klient.

Miloš sáhl po elicitation, aby řešení bylo client-agnostic:

Politiku tak vynucuje gateway. Nástroj označený jako „vyžaduje schválení“ se nespustí jenom proto, že si to agent přeje. Gateway volání podrží, vytvoří schvalovací stránku a pustí ho dál až ve chvíli, kdy tam řekne ano člověk, který má právo schvalovat. Kontrola sedí na gateway, ne v klientovi, takže platí bez ohledu na to, jaký harness vývojář zrovna používá.

Implementace naráží na nepříjemný fakt. Elicitation ve specifikaci je, ale skutečné klienty za ní zaostávají. Znovu Miloš:

Elegantní UX to není. Vykopírovat URL z chybové hlášky, schválit v prohlížeči, zavolat znovu. Nebudeme předstírat, že je to elegantní. Funguje to ale dneska i v klientech, kteří specifikaci elicitation ještě nedohnali. Druhá možnost byla čekat, až každý harness doimplementuje funkci, kterou jeho dokumentace už slibuje. Mezeru mezi tím, co dokumentace tvrdí, a tím, co reálně běží, odhalíte jenom tak, že na tom něco postavíte.

Schvalování po jednotlivých nástrojích, tedy per-tool gating, není jedna funkce. Jsou to dva provozní modely a liší se tím, kdo politiku určuje. Matyáš Křeček, který má na starosti, jak Gateway pozicujeme, tu hranici vytyčil:

Pro bezpečnostní tým jsou to dva různé světy. Gating v rukou vývojářů je pohodlný a úplně neauditovatelný. Stojí na tom, že si každý inženýr správně nastaví vlastní harness a nikdy to nezmění. Review projde jedině centrálně řízený gating. Politiku nastaví někdo, kdo za ni odpovídá, a platí pro všechny. Z věty „tento nástroj vždycky vyžaduje schválení“ se stane organizační pravidlo místo osobní preference.

Díky vrstvě Profiles se dá centrálně řízený gating provozovat ve velkém. Stejnou sadu MCP serverů zpřístupníte dvěma týmům s úplně jinou politikou u jednotlivých nástrojů. Platformní tým dostane zápis do infrastrukturních nástrojů, analytický tým tytéž servery jen pro čtení. Bez toho se per-tool gating zvrhne buď v jednu tupou politiku pro všechny, nebo v neřiditelnou hromadu výjimek pro jednotlivce. Je to stejné uvažování o řídicí vrstvě, jaké popisujeme v článku Stavíme MCP gateway pro enterprise, a stejný bezpečnostní základ jako v textu Bezpečnost MCP gateway pro enterprise. Oprávnění u jednotlivých nástrojů jsou jeden dílek té větší governance vrstvy.

Pokud per-tool gating stavíte nebo posuzujete, tady jsou ostré hrany, na které jsme narazili nebo které očekáváme.

Zbytečné odklikávání model oprávnění zabije. Nejrychleji ho položíte tak, že budete lidi nutit schvalovat věci, které schválení nikdy nepotřebovaly. Prokopovo pravidlo „co jenom čte, se schvaluje automaticky“ není příjemný bonus. Právě díky němu dává výzva „vyžaduje schválení“ pořád smysl. Když schvalování vyskočí u každého třetího volání, lidé ho přestanou číst a odklikávají ho z reflexu. To je horší než žádná brána. Máte iluzi kontroly a k tomu doložené lidské „schválení“ u každého destruktivního volání.

Identita agenta versus identita uživatele. Když se gateway ptá, kdo to smí schválit, odpovědí je člověk, ne agent. Přesně proto je naše schvalovací stránka vázaná na majitele MCP serveru. Ve chvíli, kdy volání schvaluje další automatizovaný krok, jste neohlídali nic.

Audit trail je pointa, ne vedlejší produkt. Stav „vyžaduje schválení“ za to zdržování stojí jenom tehdy, když se každé schválení zaznamená: který nástroj, s jakými argumenty, kdo schválil a kdy. Právě takový záznam chce regulovaný zákazník vidět. Gating bez audit logu vás zdrží a žádný důkaz vám nedá.

Výchozí nastavení rozhoduje o všem. Spadne nenakonfigurovaný nástroj mezi povolené, nebo mezi zakázané? U regulovaného zákazníka je jediná obhajitelná odpověď „co neznám, zakážu“, i když první den otravuje víc. Model oprávnění, který při selhání pustí všechno, existuje jenom na papíře.

Pokud napojujete AI agenty na reálné systémy, z pozice „agent smí volat každý nástroj, který jsme zaregistrovali“ se musíte pohnout dřív, než vám bezpečnostní tým dá razítko. Minimum je gating po jednotlivých nástrojích se třemi stavy: povoleno, zakázáno a vyžaduje schválení. Elicitation je protokolový mechanismus, díky kterému stav „zeptej se člověka“ opravdu funguje. A pak je tu otázka, kde ho vynutíte: v klientovi, nebo na gateway. Na tom závisí, jestli politika drží ve všech harnessech, které vaši vývojáři používají, nebo jen v tom jednom, který specifikaci zrovna implementuje.

Profily, audit a bezpečnostní základ rozebíráme v článcích Stavíme MCP gateway pro enterprise a Bezpečnost MCP gateway pro enterprise. Jak na tom stojí trh, shrnuje přehled řízení MCP ve firmách na začátku roku 2026. Pokud se v tom vaše týmy potřebují zorientovat, naše školení AI Security & Governance projde bezpečný vývoj MCP, vzorce human-in-the-loop a OWASP pro LLM. A jestli chcete vidět gating po jednotlivých nástrojích běžet nad reálným workflow, podporovanou vrstvou je MCP Gateway Enterprise. Ozvěte se a probereme gateway, otázky kolem oprávnění, které nám firmy reálně pokládaly, i upřímné zhodnocení toho, které části jsou elegantní a které specifikaci teprve dohánějí.