By Johannes Glück on września 28, 2026
Sztuczna inteligencja przechodzi od generowania odpowiedzi do podejmowania działań w rzeczywistych systemach. Ta zmiana przesuwa centralne pytanie dotyczące bezpieczeństwa. Nie wystarczy już pytać, czy model jest dokładny lub godny zaufania. Trzeba też zapytać, jak zachowuje się otaczający system, gdy model źle zinterpretuje polecenie, napotka złośliwe dane wejściowe lub otrzyma więcej uprawnień, niż wymaga zadanie. Protokoły takie jak MCP ułatwiają budowanie połączeń między agentem a systemem, ale jednocześnie sprawiają, że projektowanie tych połączeń staje się nie do pominięcia.
Połączenie agenta AI z systemem biznesowym może ujawniać różne kategorie danych różnym komponentom, w tym hostowi AI, serwerowi narzędzi, dostawcy tożsamości i aplikacji docelowej. MCP definiuje, jak komunikują się poszczególne części tego połączenia, ale nie określa, jakie dane każda implementacja przechowuje, udostępnia lub zachowuje.
Od odpowiedzi do konsekwencji
Podłączenie agenta nie tworzy jednej granicy zaufania. Tworzy ich łańcuch: host AI interpretuje żądanie, klient protokołu wybiera funkcję, serwer narzędzi waliduje i tłumaczy wywołanie, dostawca tożsamości ustala, kto działa, a system docelowy egzekwuje uprawnienia i rejestruje wynik. MCP standaryzuje część tej komunikacji, ale samo w sobie nie zabezpiecza całego łańcucha. Bezpieczeństwo zależy od decyzji podejmowanych na każdej warstwie.
Pierwsza generacja szeroko stosowanej generatywnej AI głównie tworzyła treści do przeglądu przez ludzi: tekst, obrazy, podsumowania i kod. Agenci coraz częściej obsługują narzędzia. Wysyłają wiadomości, modyfikują rekordy, uruchamiają przepływy pracy, przesyłają pieniądze i kontrolują procesy fizyczne. Prawdopodobna, lecz błędna odpowiedź bywa uciążliwa; prawdopodobne, lecz błędne działanie może mieć natychmiastowe konsekwencje.
Standardy takie jak MCP sprawiają, że narzędzia są wykrywalne i możliwe do wywołania przez ustrukturyzowane interfejsy. To znaczący postęp wobec screen scrapingu czy improwizowanych integracji, ale sama struktura nie jest polityką bezpieczeństwa. Projektant narzędzia wciąż decyduje, jakie działania są dostępne, jakie wejścia akceptują, czyjej tożsamości używają i jakie dowody zwracają.
Napotkaliśmy to rozróżnienie podczas tworzenia serwera MCP dla ezeep. Drukowanie uwidacznia ten problem — decyzja agenta może w ciągu kilku sekund stać się fizycznym wydrukiem. Ta lekcja jednak odnosi się do każdego systemu produkcyjnego.
Dokąd faktycznie trafiają dane
Stwierdzenie „model nigdy nie widzi twojego hasła” jest użyteczne, ale nie wyczerpuje opisu przepływu danych. Typowe połączenie agenta obejmuje kilka kategorii informacji: poświadczenia obsługiwane przez warstwę uwierzytelniania, argumenty narzędzia konstruowane na podstawie żądania użytkownika, wyniki operacyjne zwracane do modelu, ładunki biznesowe przekazywane do usługi docelowej oraz logi przechowywane przez jeden lub więcej komponentów. Model zwykle otrzymuje treść konwersacji, opisy dostępnych narzędzi, argumenty potrzebne do wywołania wybranego narzędzia oraz wynik zwrócony przez to narzędzie.
Te kategorie danych niekoniecznie podążają tą samą ścieżką. OAuth może trzymać hasło i token typu bearer poza kontekstem modelu, podczas gdy wynik działania narzędzia wciąż ujawnia nazwy klientów, lokalizacje urządzeń, wartości finansowe czy wewnętrzne metadane systemowe. Dokument może przepływać bezpośrednio między usługami, podczas gdy jego nazwa pliku, miejsce docelowe i status pojawiają się w konwersacji. Host AI, serwer narzędzi, dostawca tożsamości i system docelowy mogą też mieć różne zasady logowania i retencji danych.
Dlatego nie istnieje odpowiedzialne, uniwersalne stwierdzenie, że „AI nie widzi danych”. Właściwe pytania to: jakie dane otrzymuje każda warstwa, dlaczego ich potrzebuje, jak długo je przechowuje i czy użytkownik rozumie tę granicę. Nasza implementacja MCP daje konkretne przykłady tych rozróżnień, ale problem projektowy dotyczy każdego systemu połączonego z agentem.
Tożsamość określa promień rażenia
Agent nie powinien mieć niezależnej władzy. Agent może działać przez współdzieloną tożsamość usługi lub w imieniu indywidualnego użytkownika. Żaden z tych modeli nie jest uniwersalnie właściwy. Tożsamość współdzielona pasuje do bezobsługowych przepływów pracy, ale każde działanie dziedziczy uprawnienia tego konta. Autoryzacja przypisana do poszczególnych użytkowników daje węższy dostęp i wyraźniejsze przypisanie działań, lecz wymaga, by każdy użytkownik się uwierzytelniał, a aplikacja poprawnie zarządzała indywidualnymi sesjami. Interpretacja żądania przez agenta nigdy nie powinna zastępować autoryzacji egzekwowanej przez system docelowy.
Ważna decyzja inżynierska nie polega na tym, który model brzmi bezpieczniej w oderwaniu od kontekstu. Chodzi o to, czy tożsamość pasuje do przepływu pracy i czy przypisane jej uprawnienia są węższe niż konsekwencje ewentualnego błędu. W pracy nad ezeep MCP wspieramy oba modele, ponieważ zautomatyzowana usługa magazynowa i pracownik drukujący w trybie interaktywnym mają faktycznie różne wymagania dotyczące tożsamości.
Kto jest odpowiedzialny, gdy agent AI podejmuje działanie?
Jest to problem projektowania systemu, a nie tylko zaufania do modelu. Bezpieczniejsza architektura łączy kilka mechanizmów kontroli: tożsamości z zasadą najmniejszych uprawnień, wąsko zdefiniowane i typowane możliwości, walidację w systemie docelowym, potwierdzanie działań o istotnych konsekwencjach, oddzielenie zaufanych instrukcji od niezaufanych treści oraz ścieżkę audytową pokazującą, co faktycznie się wydarzyło. Ograniczanie zasięgu minimalizuje potencjalne szkody, a obserwowalność i atrybucja pozwalają ustalić odpowiedzialność po wykonaniu działania.
Projektowanie z myślą o odwracalności
Użytecznym testem dla każdej możliwości agenta jest nie tylko sprawdzenie, czy dane działanie jest dozwolone, lecz także co się stanie, gdy okaże się błędne. Operacje odczytu, zmiany możliwe do odzyskania, zobowiązania finansowe, komunikacja zewnętrzna oraz destrukcyjne działania administracyjne wymagają różnych mechanizmów kontroli. Niektóre działania powinny wymagać potwierdzenia. Niektóre powinny umożliwiać wycofanie zmian. Innych nie powinno się w ogóle udostępniać agentowi.
Podczas budowy serwera MCP ezeep zdecydowaliśmy się nie udostępniać możliwości usuwania użytkowników, grup ani drukarek, mimo że istnieją powiązane REST API. To nie czyni pozostałych narzędzi nieszkodliwymi — drukowanie generuje fizyczny wydruk, a narzędzia administracyjne mogą zmieniać dostęp — ale usuwa klasę nieodwracalnych błędów. Zasada jest szersza niż samo drukowanie: projektowanie możliwości powinno odzwierciedlać konsekwencje, nie tylko techniczną dostępność.
Czy Prompt Injection może skłonić agenta AI do podjęcia niewłaściwego działania?
Tak. Agent może natknąć się na instrukcje ukryte w dokumentach, na stronach internetowych, w e‑mailach, w zgłoszeniach serwisowych czy w wynikach narzędzi. Jest to powszechnie nazywane tzw. indirect prompt injection: treść, która powinna być traktowana jako dane, próbuje zamiast tego wpłynąć na kolejne działania agenta.
Tego ryzyka nie da się rozwiązać, prosząc model, aby „był ostrożny”. Niezaufana treść nie powinna mieć możliwości nadawania uprawnień, zmiany celu użytkownika, wyboru tożsamości o wyższych uprawnieniach ani omijania potwierdzeń. Dane wejściowe narzędzi wymagają deterministycznej walidacji, działania o istotnych konsekwencjach muszą być sprawdzane według zasad poza modelem, a wrażliwe przepływy pracy powinny wyraźnie oddzielać zaufane instrukcje od niezaufanych materiałów.
Znaczenie ma też łańcuch dostaw narzędzi. Opisy narzędzi wpływają na zachowanie modelu, więc podłączenie nowego serwera jest samo w sobie decyzją bezpieczeństwa — nie tylko ustawieniem dla wygody.
O bezpieczeństwie decyduje każda warstwa
Podłączenie agenta do rzeczywistego systemu to decyzja projektowa podejmowana na każdej warstwie: jakie działania istnieją, z czyjej tożsamości korzystają, jakie dane widzi każdy komponent, co można cofnąć i co jest rejestrowane. MCP standaryzuje część tej dyskusji. Reszta zależy od osób tworzących połączenie. Dla serwera MCP ezeep oznaczało to obsługę zarówno tożsamości usługowych, jak i per‑użytkownika oraz nieudostępnianie możliwości usuwania użytkowników, grup czy drukarek. Każdy agent w końcu się pomyli, więc połączenie musi być zaprojektowane z myślą o tym momencie — i tak właśnie zbudowaliśmy serwer MCP ezeep.
ezeep MCP jest już dostępny: Umożliwcie swojej AI drukowanie
Czy drukarki etykiet przestaną działać po włączeniu Windows Protected Print Mode?
