Zkušenosti z praxe

Agenti AI a přihlašovací údaje: projektová oprávnění s MCP

Cílené nástroje místo obecných seznamů tajemství: jak může prostředník MCP kontrolovaně zohlednit identitu, hranice projektů a přístupy backendu.

Bezpečnost
Značka DAXS nad symbolem pravidel a dvěma projektovými složkami, povolenou a odmítnutou

Worker AI má prověřit projektový server nebo spustit schválenou akci. Potřebuje k tomu vhodné nástroje a oprávnění. Soubor se všemi tokeny API a soukromými klíči SSH v projektové složce tento postup usnadňuje, ale zvětšuje možné následky chyby nebo manipulovaného vstupu.

Řízený prostředník MCP může cíleně vyjádřit povolený rozsah jednání. Agent požádá o definovanou akci; server ověří identitu, projekt a oprávnění. Kde to postup umožňuje, použije omezená backendová služba potřebné přihlašovací údaje, aniž je vrátí modelu.

MCP zprostředkuje nástroje, nikoli automaticky bezpečná práva

Model Context Protocol popisuje, jak klienti používají nástroje a další schopnosti serveru. Aplikace musí spolehlivě rozhodnout, zda uživatel smí provést určitou akci na konkrétním objektu. Přihlášený klient není automaticky oprávněn ke každému projektu ani nástroji.

Pro chráněná spojení HTTP popisuje MCP autorizační postup založený na OAuth. Aktuální specifikace jej odlišuje od místních spojení STDIO. Vhodné zabezpečení závisí na skutečném transportu. Libovolný klíč v parametru URL nebo jeden společný trvalý token nejsou rovnocennou náhradou diferencované správy oprávnění.

Konkrétní příklad: projekt A zůstává projektem A

Worker dostane úkol zjistit stav dohodnuté služby v projektu A. K tomu určený nástroj přijímá ověřený identifikátor objektu a vrací jen potřebný výsledek. Nenabízí volně použitelný shell ani obecný export všech tajemství.

Každé volání se na serveru kontroluje podle uživatele, projektu, nástroje a akce. Ani změna identifikátoru projektu na klientovi nesmí umožnit přístup k projektu B. Cíle se určují ze schválených vazeb; libovolná adresa dodaná modelem není dostatečným oprávněním. Do kontroly patří i hranice tenantů.

Povolená cesta MCP k projektu A s kontrolou pravidel a tajemstvími backendu; projekt B a obecné seznamy tajemství jsou odmítnuty.
Zjednodušený princip architektury: plné šipky ukazují povolenou cestu, červená a přerušované čáry označují odmítnutý přístup. Tajemství používá pouze omezený backend. Vlastní zobrazení.

Ověřit token pro správného příjemce

Na chráněném serveru HTTP MCP musí být přístupový token vydán pro zamýšleného příjemce a ověřen právě jím. Audience, povolený rozsah a platnost spolu souvisejí. Krátká životnost omezuje časové okno odcizeného tokenu; nenahrazuje kontrolu objektů na serveru ani proces odvolání.

Bezpečnostní dokumentace MCP zakazuje neověřené předávání tokenů: server nemá přijímat tokeny určené jiným zdrojům jako vlastní důkaz oprávnění a beze změny je předávat navazujícím API. Přihlášení klienta MCP a oprávnění vůči cílovému systému jsou samostatné vztahy důvěry. Nejasný přechod může zneužít privilegovaného prostředníka pro cizí účely; tento problém se nazývá confused deputy.

Používat tajemství v určeném backendu

Spravovaný backend tajemství může poskytovat přihlašovací údaje podle odpovědnosti a účelu. Provádějící služba dostane jen nezbytná oprávnění. Administrátorské rozhraní spravuje schválení, vazby a odebrání; nevytváří všeobecně čitelný katalog hesel pro všechny připojené workery.

Omezený nástroj může například přečíst stav nebo provést výslovně povolenou provozní akci a vrátit očištěný výsledek. Surová data z backendu tajemství nesmějí mimoděk skončit ve výstupech nástrojů, chybách, trasování ani promptech. Musí-li konkrétní klient technicky získat tajemství, toto zpřístupnění se výslovně posoudí a omezí rozsahem, dobou a příjemcem. Plošná záruka nezpřístupnění tajemství by pak byla chybná.

Vlastní akceptační kritéria omezeného pilotu; nikoli automatický příslib funkcí MCP.
Kontrolní bod Požadovaná hranice Konkrétní test
Uživatel a projekt Každá akce zůstává v povoleném rozsahu projektu. Změnit identifikátor projektu: odmítnout neoprávněný přístup.
Nástroj a parametry Dostupné jsou jen zamýšlené akce a cíle. Odmítnout volnou cílovou adresu nebo identifikátor cizího objektu.
Token a backend Příjemce a autorizační cesta jsou jednoznačné. Ověřit chybnou audience, vypršení a odvolání.
Tajemství a výsledky Backend opouštějí jen potřebné výsledky. Prověřit výstupy nástrojů, chyby a logy na surové hodnoty.
Schválení a provoz Změny se závažnými následky jsou cíleně schválené. Otestovat vazbu na cíl, životnost, limity a postup při výpadku.

Cizí obsah nesmí udělit oprávnění

Ticket, web nebo repozitář může obsahovat text, který se snaží přimět agenta k jiným akcím. Manipulované mohou být i popisy a výsledky nástrojů. Takový obsah jsou data, nikoli důkaz oprávnění. Prompt „používej jen projekt A“ pomáhá popsat úkol, nenahrazuje však technicky vynucenou hranici projektu.

Dopad prompt injection omezují úzce vymezené nástroje, ověřené parametry, omezené cílové systémy a nezávislé kontroly oprávnění. Další schválení se řídí akcí: dotaz na stav potřebuje jiný postup než změna se závažnými následky. Schválení se váže na konkrétní cíl a zamýšlenou změnu.

Naplánovat logování a odvolání

Pro dohledatelný provoz se zaznamenávají identita uživatele nebo služby, projekt, nástroj, rozhodnutí, čas a výsledek. Tajné hodnoty se vynechávají. Uchovávání, přístup k logům a potřebná podrobnost se dohodnou podle prostředí. Jediný log úspěchu nenahrazuje ověření toho, co se v cíli skutečně stalo.

Limity četnosti, časové limity a omezený rozsah backendu dále snižují následky neočekávaných volání. Při odvolání se odděleně posuzují nová volání, již vydaná oprávnění a probíhající akce. Výpadek služby MCP nebo tajemství vyžaduje definovaný chybový a obnovovací postup.

Začít malým pilotem

Vhodný pilot začíná jedním projektem a několika nástroji pouze pro čtení. Ověřují se povolené i zakázané identifikátory objektů, chybějící práva, neplatná oprávnění, manipulované výsledky a výpadek backendu. Teprve pak se hodnotí jasně omezené zápisové akce. Rozsah vychází z rizika a existujícího provozu.

DAXS pomáhá s architekturou, integrací a ověřitelným rozsahem nástrojů. Naše tematická stránka MCP a rozhraní, náš článek o spravovaných přístupech SSH a přehled bezpečnosti AI prohlubují souvislosti. Můžete probrat integraci AI pro konkrétní projekt.

Často kladené otázky

Může server MCP skrýt před modelem všechny přihlašovací údaje?

Při vhodně navržených serverových akcích může model dostat pouze očištěný výsledek. Zda je to možné u každé potřebné operace, se musí ověřit. Technické předání tajemství klientovi mění hodnocení rizika.

Stačí jako ochrana dlouhý tajný token?

Ne. Ověřují se také příjemce, rozsah, platnost, přiřazení uživateli a projektu i konkrétní akce. Jeden token s širokými právy toto rozdělení sám neposkytuje.

Jak začít pilot s více projekty?

Nejprve se definují a testují povolené akce pro jeden projekt. Druhý projekt se následně ověří také pomocí výslovně zakázaných vzájemných odkazů. Teprve skutečně vynucené oddělení vytváří základ dalších úkolů.

Zdroje: MCP: autorizace, verze 28.07.2026 (externí odkaz) · MCP: hranice důvěry a předávání tokenů (externí odkaz) · OWASP: autorizace každého volání a objektu (externí odkaz) · OWASP: správa tajemství (externí odkaz) · OWASP: omezení prompt injection (externí odkaz)

Konkrétní funkční a provozní rozsah se dohodne pro dané prostředí.