AI systémy a vývoj Agenti a workflowy18. októbra 2026·2 minOdborný rozbor

Pri firemnom MCP nestačí preniesť token ďalej. Server musí overiť, komu bol vydaný

Autorizačná špecifikácia MCP a bezpečnostné odporúčania vysvetľujú oddelenie klienta, MCP servera a nadväzujúcich služieb. Pre integrácie firmy je podstatný účel tokenu a hranica delegovaného prístupu.

Pôvodná schéma porovnania spravovanej autentifikácie MCP. Model Context Protocol contributors — CC-BY-4.0 (documentation). Zdroj: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/1155ca460e5097019f32769b38dcba194432e2fb/blog/content/posts/enterprise-managed-auth/ema-comparison.png. Licencia: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/1155ca460e5097019f32769b38dcba194432e2fb/LICENSE

Jedna konverzácia, viac bezpečnostných hraníc

Keď firemný agent používa vzdialený MCP server, do procesu vstupuje klient, server nástrojov a často aj ďalšie API. Každá z týchto služieb má vlastnú hranicu prístupu. Autorizačná špecifikácia MCP vo verzii z 28. júla 2026 opisuje mechanizmus pre HTTP transport; nemožno ju automaticky stotožniť s prihlásením každého lokálneho procesu používajúceho štandardný vstup a výstup.

Článok rozoberá verziu 2026-07-28 a jej bezpečnostné odporúčania, na ktoré dokumentácia presmerovala pri načítaní 18. októbra 2026. Ide o výklad integračného mechanizmu, nie tvrdenie o novej dnešnej zmene protokolu. Pre malú firmu je užitočný pri pripájaní CRM, dokumentového úložiska alebo interného katalógu nástrojov.

Token má určeného príjemcu

Špecifikácia pracuje s OAuth a metadátami chráneného zdroja. Klient má zistiť, kde sa má autorizovať, a žiadať token pre konkrétny zdroj. Server musí overiť, že token bol vydaný na použitie pri jeho službe. To je konkrétny rozdiel oproti všeobecnému tajnému reťazcu, ktorý sa posiela cez každú integračnú vrstvu bez kontroly určenia.

Samostatné bezpečnostné odporúčania rozoberajú token passthrough: prijatý token sa bez primeraného overenia odovzdá nadväzujúcemu API. Dokumentácia tento postup zakazuje, pretože môže obísť kontrolu publika tokenu a pomiešať zodpovednosť služieb. Prístup klienta k MCP serveru a oprávnenie servera pracovať s ďalšou službou preto treba navrhnúť ako dve rozlíšiteľné časti.

Ako to ovplyvní firemnú integráciu

Redakčný príklad je asistent, ktorý číta dokumenty a pripravuje zmenu zákazky v CRM. Autentifikácia potvrdzuje identitu alebo klienta, ale sama ešte neznamená súhlas vykonať každú obchodnú akciu. Aplikácia má popri autorizačnom toku určiť aj rozsah nástrojov a rozhodovanie o citlivých zmenách. Schválenie jednej operácie nesmie byť len voľným textom, ktorý si model vyloží podľa seba.

Pre zavedenie odporúčame najprv zdokumentovať, kto vydáva jednotlivé tokeny, komu sú určené a kde sa overujú. Potom možno testovať odmietnutie nesprávneho príjemcu a zrušeného prístupu. Toto je návrh kontroly odvodený zo špecifikácie, nie výsledok vykonaného penetračného testu. MCP vytvára spoločný spôsob komunikácie; kvalitu konkrétnej autorizácie musí preukázať implementácia.

Repozitár https://github.com/modelcontextprotocol/modelcontextprotocol bol overený 18. októbra 2026 na commite 1155ca460e50. GitHub uvádzal vydanie 2026-07-28 z 2026-07-28. Opisovaný mechanizmus nie je tvrdením, že vznikol až v tomto vydaní.

Technický kontext

Stav overenia: Spracované podľa zdroja; redakcia postup nereprodukovala.

Verzie: 2026-07-28

Podmienky použitia: Vlastná aplikácia a konfigurácia komponentov podľa odkazovanej dokumentácie; konkrétny integračný bod vysvetľujú sekcie článku.

Obmedzenia: Rozbor zachytených technických podkladov. Bez vlastného nasadenia, benchmarku alebo merania úspory.