Tworzyć serwery MCP.
Celowo łączyć systemy.
AI ma odpowiadać i celowo pracować z istniejącymi systemami. DAXS tworzy odpowiednie serwery MCP i adaptery z jasno określonymi narzędziami, ograniczonymi prawami i sprawdzalnymi wynikami.
Serwer MCP udostępnia określone funkcje aplikacjom AI.
Asystent ma odczytać status zgłoszenia, przeszukać zatwierdzoną dokumentację lub utworzyć przygotowany wpis. Potrzebuje do tego jasno opisanego, ograniczonego dostępu. DAXS tworzy odpowiednie serwery MCP i stojące za nimi połączenia API do istniejących systemów firmowych.
Protokół Model Context Protocol opisuje, jak aplikacje AI mogą korzystać m.in. z narzędzi, zasobów danych i przygotowanych promptów. Serwer MCP jest technicznym adapterem. Sama dobra nazwa narzędzia nie czyni go bezpiecznym ani samodzielnie działającym agentem.
Klasyczne API
Aplikacja wywołuje określoną funkcję innego systemu. Model danych, uprawnienia, walidację i obsługę błędów planuje się dla tego dostępu.
Integracja MCP
Zgodny klient AI może korzystać z opisanych funkcji i zasobów poprzez wspólny protokół. Konkretne zatwierdzenie i wykonanie w systemie docelowym pozostają odrębnymi zadaniami.
Agent AI
Aplikacja łączy model, stan i narzędzia w wieloetapowym działaniu. Potrzebuje ograniczonego zlecenia, warunków przerwania i przejrzystej kontroli działań. Agent może korzystać z MCP lub innych API.
Klient, interfejs i system docelowy kontrolują własne obszary.
Aplikacja AI proponuje wywołanie narzędzia. Serwer MCP sprawdza tożsamość, dozwoloną funkcję i dane wejściowe. System docelowy dodatkowo egzekwuje własne reguły dostępu. Przy działaniach krytycznych konkretne zatwierdzenie jest sprawdzane przed wykonaniem.
Rysunek przedstawia przykładową architekturę indywidualnej integracji. Współdziałające wersje klienta, SDK i protokołu są ustalane i testowane przed realizacją.
Zlecenie określa dane i działania.
Interfejs do systemu zgłoszeń nie musi udostępniać całej bazy danych. Narzędzie może np. zwracać dokładnie pola potrzebne do dozwolonej informacji o statusie. Inne tworzy wyłącznie szkic. Ogólne funkcje powłoki, SQL lub administracji byłyby do tego niepotrzebnie szerokim zakresem.
| Rodzaj | Możliwe narzędzie | Ważna kontrola |
|---|---|---|
| Odczyt | Pobranie statusu zgłoszenia, wyszukanie zatwierdzonej dokumentacji lub sprawdzenie stanu technicznego. | Użytkownik może zobaczyć konkretny obiekt; zwracane są tylko potrzebne pola, ograniczona liczba wyników i żadne dane innych tenantów. |
| Ograniczony zapis | Przygotowanie szkicu odpowiedzi lub uporządkowanej notatki wewnętrznej. | Sprawdzić pola i dozwolone treści, jasno oznaczyć szkic, kontrolować powtórzenia i zwrócić przejrzysty wynik. |
| Krytyczne | Uruchomienie uzgodnionej zmiany w systemie produkcyjnym. | Dodatkowe zatwierdzenie powiązane z działaniem i obiektem docelowym; ponowne sprawdzenie uprawnień bezpośrednio przed wykonaniem, określenie granic i drogi wycofania. |
Także narzędzie odczytujące może ujawnić poufne dane. „Tylko odczyt” nie zastępuje więc autoryzacji. Przy zapisach planujemy ponadto idempotencję, stany błędów i obsługę niejasnych wyników: timeout nie dowodzi, że działanie nie zostało wykonane.
Udane logowanie nie oznacza dostępu do każdego obiektu.
Odróżniamy logowanie w kliencie AI, autoryzację na serwerze MCP i uprawnienia w aplikacji docelowej. Kontekst użytkownika, grupy i tenanta pochodzi z zaufanej tożsamości. Model nie może sam określać tekstowo swojej roli ani dozwolonego zakresu danych.
Przy zdalnej integracji HTTP potrzebna jest odpowiednia koncepcja autoryzacji. Tokeny muszą być przeznaczone dla właściwej usługi i sprawdzane pod względem ważności i zakresu. Dane dostępowe kolejnych systemów są chronione i ograniczane odpowiednio do celu. Dowolnie przekazany token klienta nie jest uniwersalnym dostępem systemowym.
Połączenie z procesem lokalnym ma inne granice niż zdalna usługa firmowa: np. uruchamiany program, jego pochodzenie i uprawnienia systemowe. Proste uruchomienie lokalne nie zastępuje kontroli programu ani jego dostępu do danych. Dla obu wariantów uzgadniamy dozwolone połączenia i odpowiedzialność techniczną.
MCP jest protokołem, a nie kompletną architekturą bezpieczeństwa.
Rzeczywiste ograniczenia egzekwują logika serwera, prawa systemu docelowego, chronione dane dostępowe, reguły sieci i sprawdzalne zatwierdzenia. Odpowiednia realizacja wynika z klienta, danych, działań i modelu utrzymania.
Granice obowiązują także przy niewłaściwych propozycjach modelu.
Dokument, treść zgłoszenia lub wynik narzędzia mogą zawierać zmanipulowane instrukcje. Takie treści traktuje się jako dane. Nie mogą nadawać nowych uprawnień ani uzasadniać wykonania zablokowanego działania. Wskazówki w prompcie mogą wspierać aplikację; wiążąca kontrola znajduje się poza modelem.
Dane wejściowe i cele
Walidować po stronie serwera typy, dozwolone wartości, obiekty, ścieżki i liczbę wyników. Ograniczyć API i cele sieciowe; bez dowolnie składanych poleceń i niekontrolowanych wywołań adresów.
Działania i zatwierdzenia
Zrozumiale pokazywać zakres wywołania i skutki uboczne. Krytyczne zatwierdzenia wiązać z konkretną operacją, ograniczać czasowo i sprawdzać przed wykonaniem. Ustalić reguły przerywania i powtarzania.
Utrzymanie i identyfikowalność
Zaplanować limity wywołań i czasu, obsługę błędów i logi ograniczone do celu. Nie włączać danych dostępowych do kontekstu modelu ani diagnostyki. Umożliwić badanie podejrzanych dostępów i cofnięcie dostępu.
Sprawdzamy zwykłe przebiegi, ale również niedozwolony dostęp do obiektów, zmanipulowane treści, wygasłe uprawnienia, podwójne wywołania i odmowę zatwierdzenia. Ogranicza to ryzyko; ogólna obietnica skutecznego zapobieżenia każdej prompt injection byłaby nierzetelna.
Zacząć od niewielkiej funkcji.
Zbieramy informacje o aplikacji docelowej, istniejących API, rolach użytkowników i potrzebnych polach. Powstaje ograniczony katalog narzędzi z jasnymi wejściami i wynikami. Pilotaż odczytu może wykazać codzienną użyteczność integracji; zapis dodaje się i sprawdza osobno w razie potrzeby.
- Wyznaczyć zakres: jaki problem, jakie obiekty i jacy użytkownicy?
- Opracować interfejs: podłączyć API docelowe, opisać narzędzie, sprawdzić uprawnienia i błędy.
- Przeprowadzić praktyczny odbiór: sprawdzić przypadki dozwolone i zabronione, zatwierdzenia i powtórzenia.
- Przekazać z obsługą: zapisać dokumentację, zarządzanie dostępami, aktualizację wersji i odpowiedzialność.
DAXS może wykonać tę pracę jako indywidualny projekt programistyczny i integracyjny. Proste pobranie danych może być również sensownie zrealizowane klasycznym API lub skryptem. Odpowiedni zakres omawiamy na podstawie istniejących systemów.
Konkretna pożądana funkcja, aplikacja, istniejąca dokumentacja API i zanonimizowany przykład. Dane dostępowe i poufne dane klientów nie należą do publicznego zapytania.
Wyjaśnimy to podczas rozmowy.
Czym różni się API od MCP?
API udostępnia funkcje systemu. MCP opisuje wspólny sposób udostępniania narzędzi i kontekstu wspierającym aplikacjom AI. Serwer MCP może korzystać z istniejących API; ich uprawnienia i reguły merytoryczne nadal są wymagane.
Czy każda automatyzacja potrzebuje agenta AI?
Nie. Ściśle określony import lub jednoznaczne obliczenie często prościej wykonać skryptem lub bezpośrednim połączeniem API. Agenta rozważa się, gdy zmienne zadania rzeczywiście wymagają elastycznego doboru kroków.
Czy narzędzie MCP może samodzielnie wprowadzać zmiany?
Jeśli jest to merytorycznie potrzebne i technicznie zabezpieczone. Odczyt, ograniczone zmiany i działania krytyczne traktujemy osobno. Zatwierdzenia, prawa docelowe, walidacja wejścia i przejrzyste wyniki należą do danej funkcji.
Czy logowanie do usługi AI wystarcza jako uprawnienie?
Nie. Serwer musi sprawdzić wywołującego i jego uprawnienia; system docelowy również musi zezwalać na dostęp do konkretnej funkcji i obiektu. Wywołanie narzędzia nie może tworzyć praw, których użytkownik normalnie nie ma.
Jak rozpoczyna się rozsądny pilotaż?
Od jasnej korzyści i kilku ograniczonych narzędzi, możliwie początkowo odczytujących. Ustalamy kryteria sukcesu i testujemy niedozwolony dostęp, problematyczne treści, przekroczenia czasu i powtarzane wywołania przed rozbudową zapisu.
Dostęp do narzędzia nie oznacza zgody na dowolne działanie.
Agent w systemie Linux może używać API, narzędzi lokalnych lub usług zewnętrznych. Własną tożsamość usługi, ograniczony dostęp do plików, izolację procesów, dozwolone cele sieciowe i bezpiecznie zarządzane dane dostępowe planuje się osobno. Lokalny agent nie jest automatycznie offline; każde zewnętrzne wywołanie należy do przepływu danych. Testy obejmują zmiany modeli, błędy narzędzi, limity czasu i kosztów oraz przejrzystą ścieżkę przerwania.
Omówmy Państwa przypadek użycia.
Co powinno stać się prostsze, jakie dane uczestniczą w procesie i jakie systemy już istnieją? Na tej podstawie opracujemy rozsądny początek i niewielki kolejny krok.