Vyvíjet MCP servery.
Cíleně propojit systémy.
AI nemá jen odpovídat, ale cíleně pracovat se stávajícími systémy. DAXS vyvíjí vhodné MCP servery a adaptéry – s jasnými nástroji, omezenými právy a ověřitelnými výsledky.
MCP server zpřístupňuje definované funkce AI aplikacím.
Asistent má umět načíst stav ticketu, prohledat schválenou dokumentaci nebo vytvořit připravený záznam. K tomu potřebuje jasně popsaný, omezený přístup. DAXS vyvíjí vhodné MCP servery a navazující API propojení pro stávající firemní systémy.
Protokol Model Context Protocol popisuje, jak mohou AI aplikace využívat mimo jiné nástroje, datové zdroje a připravené prompty. MCP server je přitom technický adaptér. Samotný dobrý název nástroje z něj nedělá bezpečné řešení ani samostatně pracujícího agenta.
Klasické API
Aplikace volá stanovenou funkci jiného systému. Pro tento přístup se plánují datový model, oprávnění, validace a zpracování chyb.
Integrace MCP
Kompatibilní AI klient může používat popsané funkce a zdroje prostřednictvím společného protokolu. Konkrétní schválení a provedení v cílovém systému zůstávají samostatnými úkoly.
AI agent
Aplikace kombinuje model, stav a nástroje pro několik kroků. K tomu potřebuje vymezený úkol, podmínky zastavení a dohledatelnou kontrolu svých akcí. Agent může používat MCP nebo jiná API.
Klient, rozhraní a cílový systém kontrolují každý svou oblast.
AI aplikace navrhne volání nástroje. MCP server prověří identitu, povolenou funkci a vstupy. Cílový systém navíc vynucuje svá přístupová pravidla. U kritických akcí se před provedením ověřuje konkrétní schválení.
Schéma ukazuje příklad architektury individuální integrace. Které verze klienta, SDK a protokolu spolupracují, se stanoví a otestuje před realizací.
Úkol určuje data a akce.
Rozhraní k ticketovacímu systému nemusí zpřístupnit celou databázi. Nástroj může například poskytnout přesně ta pole, která jsou potřebná pro povolené zjištění stavu. Jiný vytvoří pouze návrh. Obecné shellové, SQL nebo administrátorské funkce by pro tento účel byly zbytečně širokým rozsahem.
| Typ | Možný nástroj | Důležitá kontrola |
|---|---|---|
| Čtení | Načíst stav ticketu, vyhledat schválenou dokumentaci nebo zjistit technický stav. | Uživatel smí vidět konkrétní objekt; poskytnout pouze potřebná pole, omezený počet výsledků a žádná data jiných tenantů. |
| Omezený zápis | Připravit návrh odpovědi nebo strukturovanou interní poznámku. | Prověřit pole a povolený obsah, jasně označit návrh, řídit opakování a srozumitelně vrátit výsledek. |
| Kritické akce | Spustit dohodnutou změnu v produkčním systému. | Doplňkové schválení vázané na akci a cílový objekt; znovu ověřit oprávnění bezprostředně před provedením, stanovit hranice a cestu zpět. |
Také nástroj pro čtení může odhalit důvěrná data. „Pouze číst“ proto nenahrazuje autorizaci. U zapisujících volání navíc plánujeme idempotenci, chybové stavy a zacházení s nejasnými výsledky: timeout nedokazuje, že se akce neprovedla.
Úspěšné přihlášení ještě není oprávněním ke každému objektu.
Rozlišujeme přihlášení k AI klientovi, autorizaci na MCP serveru a oprávnění v cílové aplikaci. Kontext uživatele, skupiny a tenantu pochází z důvěryhodné identity. Model si nesmí sám určovat roli nebo povolenou oblast dat textovým vstupem.
Ke vzdálené HTTP integraci patří vhodná koncepce autorizace. Tokeny musejí být určené pro zamýšlenou službu a prověřené z hlediska platnosti a rozsahu. Přihlašovací údaje pro navazující systémy se chrání a omezují podle příslušného cíle. Libovolně předávaný klientský token není univerzálním systémovým přístupem.
Místní procesní připojení má jiné hranice než vzdálená firemní služba: například spuštěný program, jeho původ a oprávnění v operačním systému. Jednoduché místní spuštění nenahrazuje prověření programu ani jeho přístupů k datům. Pro obě varianty dohodneme povolená spojení a technické odpovědnosti.
MCP je protokol, nikoli úplná bezpečnostní architektura.
Skutečné omezení vynucují serverová logika, práva cílového systému, chráněné přihlašovací údaje, síťová pravidla a ověřitelná schválení. Vhodné provedení se řídí klientem, daty, akcemi a provozním modelem.
Hranice platí i při nevhodných návrzích modelu.
Dokument, text ticketu nebo výsledek nástroje může obsahovat podvržené instrukce. Takový obsah se zpracovává jako data. Nesmí udělovat nová práva ani odůvodnit provedení jinak zakázané akce. Pokyny v promptu mohou aplikaci podpořit; závazná kontrola je mimo model.
Vstupy a cíle
Na serveru validovat typy, povolené hodnoty, vazbu na objekt, cesty a počty výsledků. Omezit povolená API a síťové cíle; nepoužívat volně sestavované příkazy ani nekontrolované volání adres.
Akce a schvalování
Srozumitelně zobrazit rozsah volání a vedlejší účinky. Kritická schválení vázat na konkrétní operaci, časově omezit a před provedením znovu prověřit. Stanovit pravidla zastavení a opakování.
Provoz a dohledatelnost
Zajistit limity požadavků, časové limity, zpracování chyb a účelově omezené protokoly. Nevkládat přihlašovací údaje do kontextu modelu ani diagnostických výstupů. Umožnit prověření podezřelých přístupů a jejich odebrání.
Prověřujeme běžné postupy i zakázané přístupy k objektům, podvržený obsah, vypršelá oprávnění, duplicitní volání a zamítnuté schválení. Tím se snižují rizika; obecný příslib bezpečně zabránit každému prompt injection by nebyl seriózní.
Začít zvládnutelnou funkcí.
Zmapujeme cílovou aplikaci, stávající API, uživatelské role a potřebná pole. Vznikne omezený katalog nástrojů s jasnými vstupy a výsledky. Pilot pro čtení může ukázat, zda integrace pomáhá v praxi; zapisující kroky se podle potřeby samostatně doplní a prověří.
- Vymezit úkol: jaký problém, které objekty a kteří uživatelé?
- Vyvinout rozhraní: připojit cílové API, popsat nástroj, zavést práva a chybové případy.
- Prakticky převzít: prověřit povolené a zakázané případy, schvalování a opakování.
- Předat do správy: zaznamenat dokumentaci, správu přístupů, verzí a odpovědnosti.
DAXS může tuto práci zajistit jako individuální vývoj a integraci. Samotný datový dotaz lze vhodně řešit také klasickým API nebo skriptem. Odpovídající rozsah probereme podle vašich stávajících systémů.
Konkrétní požadovaná funkce, dotčená aplikace, stávající dokumentace API a anonymizovaný příklad. Přihlašovací údaje ani důvěrná zákaznická data nepatří do veřejné poptávky.
To vyjasníme při rozhovoru.
Jak se liší API od MCP?
API poskytuje funkce systému. MCP popisuje společný způsob nabízení nástrojů a kontextu podporovaným AI aplikacím. MCP server k tomu může používat stávající API; jejich práva a odborná pravidla zůstávají potřebná.
Potřebuje každá automatizace AI agenta?
Ne. Pevně stanovený import nebo jednoznačný výpočet lze často jednodušeji realizovat skriptem nebo přímým API propojením. Agent připadá v úvahu, když proměnlivé úkoly skutečně vyžadují flexibilní výběr kroků.
Smí MCP nástroj sám provádět změny?
Pokud je to odborně požadované a technicky zabezpečené. Funkce pro čtení, omezené změny a kritické akce se řeší odděleně. Schvalování, cílová práva, kontrola vstupů a dohledatelné výsledky patří k příslušné funkci.
Stačí přihlášení k AI službě jako oprávnění?
Ne. Server musí prověřit volajícího a jeho oprávnění; cílový systém musí rovněž povolit přístup ke konkrétní funkci a objektu. Volání nástroje nesmí vytvářet práva, která uživatel jinak nemá.
Jak začíná smysluplný pilot?
Jasným přínosem a několika omezenými nástroji, pokud možno nejprve pro čtení. Stanovíme kritéria úspěchu a před rozšířením zapisujících funkcí testujeme nepovolené přístupy, problematický obsah, překročení časového limitu i opakovaná volání.
Přístup k nástroji ještě není povolením k provozu.
Agent v Linuxu může používat API, místní nástroje nebo externí služby. Vlastní identita služby, omezené přístupy k souborům, izolace procesů, povolené síťové cíle a bezpečně spravované přihlašovací údaje se plánují samostatně. Místní agent tedy není automaticky offline; každé externí volání patří do datového toku. Testují se také změny modelu, chyby nástrojů, limity doby běhu a nákladů i dohledatelný způsob zastavení.
Více o právech a schvalování pro agenty
Skript, workflow, nebo AI agent: konkrétní rozhodovací otázky
Proberme váš případ použití.
Co se má zjednodušit, která data se zapojují a jaké systémy už máte? Z toho vytvoříme smysluplný začátek a zvládnutelný další krok.