Wiedza

MCP i agenci AI: bezpieczne narzędzie zaczyna się poza modelem

Autor: Piotr AdamskiOpublikowano: 12 września 2026

Model Context Protocol ułatwia podłączenie modelu lub agenta do narzędzi. Sam protokół nie rozstrzyga jednak, czy agent powinien móc wykonać daną operację, na którym zasobie i z jakim skutkiem. To musi egzekwować warstwa aplikacyjna.

Jeżeli agent może przez MCP odczytać raport, zmienić konfigurację, uruchomić wydatek albo usunąć zasób, traktujemy go jak klienta uprzywilejowanego API. Prompt opisuje intencję. Gateway ma egzekwować granice.

W praktyce projektujemy tę granicę według siedmiu zasad.

1. Oddziel tożsamość operatora od credentiali do systemu docelowego

Agent działa w czyimś imieniu. Potrzebujemy więc co najmniej dwóch pytań:

kto zlecił operację i jakie ma uprawnienia w Brillnet?
jak system Brillnet uwierzytelnia się do dostawcy zewnętrznego?

To nie jest to samo.

W naszym wewnętrznym Brillnet Ads MCP operator przechodzi przez kontrolę Brillnet, a wywołanie do Google używa osobnej tożsamości usługi. Token dostawcy jest krótkotrwały i nie wraca do warstwy MCP jako dane dla modelu.

Dzięki temu model nie musi znać credentiali, żeby wykonać dozwolone zadanie. I nie może ich „przypadkiem” wkleić do odpowiedzi, bo ich nie dostał.

Zasada

Sekret ma być dostępny dla komponentu, który musi go użyć, a nie dla całego łańcucha.

2. Uprawnienia opisuj przez operację, nie przez nazwę agenta

Rola typu marketing-agent brzmi czytelnie, ale sama w sobie niewiele mówi o tym, co system faktycznie pozwala zrobić.

Lepiej rozdzielić zakresy według skutku:

read
→ odczyt i raportowanie

write
→ utworzenie albo zmiana zasobu

operate
→ uruchomienie skutku operacyjnego, np. wydatku lub publikacji

destructive
→ usunięcie, odpięcie, unieważnienie albo inna trudna do cofnięcia zmiana

Agent może mieć read bez write. Może mieć write do przygotowania kampanii, ale bez operate, więc nie może jej uruchomić. Operacja usunięcia może wymagać write + destructive.

Taki model nie musi mieć dokładnie tych nazw. Ważne jest rozdzielenie przygotowania zmiany od jej skutku.

Więcej: Najmniejsze uprawnienia dla agentów AI

3. Bezpieczne wartości domyślne muszą działać bez pomocy modelu

Jeżeli brak jednego parametru może uruchomić działanie, mamy złą wartość domyślną.

W wewnętrznym Brillnet Ads MCP nowa kampania pozostaje PAUSED, gdy status nie został jawnie podany. To drobna decyzja architektoniczna, ale jej sens jest istotny: brak informacji nie jest zgodą na uruchomienie wydatku.

Ten sam wzorzec można zastosować szerzej:

dokument bez statusu → draft, nie publikacja;
nowy użytkownik bez roli → brak dostępu, nie rola domyślna;
integracja bez potwierdzonego celu → brak synchronizacji;
niejednoznaczny zasób → błąd, nie „najbardziej prawdopodobny” rekord;
brak zgody na operację wysokiego ryzyka → stop, nie retry.

Bezpieczna wartość domyślna powinna być przewidywalna również wtedy, gdy model halucynuje, pomija pole albo źle rozumie intencję.

4. Operacje o wysokim wpływie mają osobną bramkę

Agent może przygotować poprawną zmianę, ale poprawna technicznie zmiana nie zawsze jest poprawną decyzją biznesową.

Wydanie budżetu, publikacja treści, wysłanie wiadomości do klienta, zmiana uprawnień albo usunięcie danych mają skutki poza samą sesją agenta. Dlatego akceptacja powinna być niezależnym zdarzeniem.

Minimalny komunikat przed zatwierdzeniem powinien pokazać:

system i zasób docelowy;
rodzaj operacji;
najważniejsze parametry zmiany;
przewidywany skutek;
informację, czy operacja jest odwracalna;
kto zatwierdza.

Nie wystarczy pytanie „Czy kontynuować?”. Człowiek musi wiedzieć, co dokładnie zatwierdza.

Więcej: Kiedy agent AI wymaga zatwierdzenia człowieka?

5. Retry nie może po cichu powielać zapisu

Systemy agentowe wykonują wiele wywołań API. Błędy sieci, timeouty i ponowienia są normalne. Problem zaczyna się wtedy, gdy ponowienie tej samej operacji tworzy drugi zasób albo wykonuje drugi przelew, publikację czy wysyłkę.

Dla operacji, które to wspierają, stosujemy idempotency key. Gateway rozpoznaje tę samą próbę i nie wykonuje jej drugi raz bez kontroli.

To trzeba połączyć z read-after-write:

agent zleca zmianę
↓
gateway waliduje i wykonuje zapis
↓
system docelowy odpowiada
↓
gateway odczytuje stan zasobu
↓
operator widzi wynikowy stan

Dzięki temu „narzędzie zwróciło 200” nie jest jedynym dowodem, że system znajduje się w oczekiwanym stanie.

6. „Raw gateway” nie może być tylnymi drzwiami

Przy dużym API powstaje pokusa: zamiast budować osobne narzędzie dla każdego endpointu, udostępniamy agentowi ogólne wywołanie REST.

To może być uzasadnione, ale tylko jeśli ogólna ścieżka dziedziczy te same kontrole.

W Brillnet klasyfikujemy metodę, endpoint i charakter żądania przed wykonaniem. Niskopoziomowe wywołanie nie omija wymaganych zakresów i dodatkowej kontroli dla operacji destrukcyjnych.

Antywzorzec wygląda tak:

bezpieczne narzędzia MCP
→ mają scope i walidację

raw_http_request
→ może wywołać dowolny endpoint z pełnym tokenem

W takim układzie cała wcześniejsza kontrola jest kosmetyczna. Najszersza ścieżka definiuje faktyczną granicę bezpieczeństwa.

7. Audyt rejestruje decyzję i rezultat, ale nie sekrety

Wewnętrzne narzędzie Brillnet zapisuje metadane żądania oraz wynik operacji w łańcuchu append-only z kontrolą integralności. Jednocześnie z logów wykluczamy credentiale, nagłówki autoryzacyjne i surowe identyfikatory osobowe.

To rozdzielenie jest ważne. Audyt ma pomóc odtworzyć działanie, a nie skopiować do logu pełny kontekst bezpieczeństwa.

Dla operacji agentowej chcemy zwykle znać:

request/task ID;
operatora i tożsamość agenta;
narzędzie i klasę operacji;
zasób docelowy;
decyzję autoryzacyjną;
identyfikator zatwierdzenia, jeśli był wymagany;
wynik wywołania;
stan po zapisie;
wersję polityki lub konfiguracji, która miała zastosowanie.

Więcej: Ślad audytowy agentów AI

Przykład architektury: agent do Google Ads

Nasz wewnętrzny przypadek jest celowo wąski. Narzędzie służy wyłącznie do kont Google Ads należących do Brillnet. Nie jest usługą agencyjną i nie dostaje dostępu do kont klientów.

Przepływ można uprościć do:

operator Brillnet
↓
tożsamość + profil + scope
↓
agent / model
↓
wywołanie narzędzia MCP
↓
gateway: walidacja + klasyfikacja + approval policy
↓
krótkotrwały token dostawcy
↓
Google Ads API
↓
normalizacja + redakcja
↓
read-after-write / wynik
↓
audit trail

Najważniejszy element nie znajduje się w środku modelu. Jest nim warstwa między intencją a wykonaniem.

Antywzorce, które wyglądają wygodnie

Jeden token administratora dla wszystkich agentów

Ułatwia start. Później nie da się sensownie ograniczyć skutku błędu ani ustalić, czy agent w ogóle powinien mieć dostęp do danego zasobu.

„Model zapyta użytkownika, jeśli operacja będzie ryzykowna”

To decyzja bezpieczeństwa delegowana temu samemu komponentowi, którego błąd próbujemy kontrolować.

Logowanie pełnego promptu i odpowiedzi jako audytu

Rozmowa nie zastępuje śladu operacji. Może też zawierać dane, których nie powinniśmy kopiować do systemu logów.

Automatyczne retry każdego błędu

Nie każdy błąd jest przejściowy. Nie każdy zapis jest idempotentny. Retry bez klasyfikacji może zwiększyć szkodę.

Uniwersalny endpoint z pełnym dostępem „na wypadek nowych funkcji”

Jeżeli agent może ominąć restrykcyjne narzędzia jedną szeroką funkcją, to szeroka funkcja jest realnym modelem uprawnień.

Checklista przeglądu serwera MCP

Przed produkcyjnym użyciem sprawdziłbym minimum:

Czy tożsamość operatora jest znana przy każdym wywołaniu?
Czy credential systemu docelowego jest ukryty przed modelem?
Czy read, write, operate i destructive można rozdzielić?
Czy scope ogranicza również zasób/tenant/konto, nie tylko nazwę funkcji?
Czy brak parametru prowadzi do bezpiecznego stanu?
Czy operacje finansowe, zewnętrzne i destrukcyjne mają niezależne zatwierdzenie?
Czy retry zapisu jest kontrolowany?
Czy po zapisie odczytujemy faktyczny stan zasobu?
Czy niskopoziomowy gateway podlega tej samej autoryzacji?
Czy audit nie zawiera tokenów, sekretów i surowych danych osobowych?
Czy arbitralne ścieżki plików i nieograniczone payloady są odrzucone?
Czy można centralnie odwołać dostęp agenta lub operatora?

MCP 2026-07-28 zmienia protokół, ale nie usuwa obowiązku projektowania kontroli

Wersja MCP 2026-07-28 wprowadziła m.in. stateless core i dalsze utwardzenie autoryzacji. To pomaga budować skalowalną i czytelną warstwę komunikacji. Nie odpowiada jednak za politykę biznesową konkretnego wdrożenia: czy agent może wydać 5000 zł, usunąć konto albo wysłać wiadomość do 10 tysięcy osób.

Tę decyzję nadal musi egzekwować aplikacja.

Źródła

Granica

Opisujemy wzorce używane w naszej pracy. Nie deklarujemy w ten sposób zgodności całego narzędzia z OWASP, NIST ani pełną specyfikacją MCP. Każda integracja wymaga własnego threat modelu i testów.

Jeżeli oceniasz sposób, w jaki Brillnet podchodzi do dostępu, danych i AI, zobacz także Bezpieczeństwo oraz Zgodność i nadzór nad AI.