Zabezpieczenia MCP: bezpieczne uprawnienia dla agentów AI

Token MCP to hasło do Twojego konta z doczepionym API. Daj go agentowi, a dostaniesz użytkownika, który nigdy się nie męczy, czyta każdą stronę, na którą go skierujesz, i robi dokładnie to, co powiedziało ostatnie polecenie w jego kontekście. Zwykle właśnie o to chodzi. Ta strona jest o pozostałych przypadkach.

Wszystko poniżej sprawdziliśmy na produkcyjnym serwerze w dniu podanym na górze: lista narzędzi pochodzi z tools/list na https://mcp.eqvps.com/mcp, limity z samego API. Jeśli dopiero zaczynasz, przeczytaj najpierw podłączanie klienta MCP i tokeny API, a potem wróć.

Model zagrożeń: co naprawdę idzie nie tak

Trzy rzeczy, w kolejności, w jakiej je widzimy:

1. Agent źle zrozumiał. „Posprzątaj maszynę testową” zamienia się w reinstalację niewłaściwego serwera. Bez złej woli, po prostu model wypełnił lukę w poleceniu.
2. Prompt injection. Agent czyta tekst, którego nie napisałeś (README, odpowiedź supportu, stronę z sieci), a ten tekst każe mu coś zrobić. Jeśli agent ma token z pełnymi uprawnieniami, wstrzyknięte polecenie też je ma.
3. Token wycieka. Trafia do historii powłoki, publicznego repozytorium, współdzielonej konfiguracji MCP albo linii logu.

Serwer MCP sprawdza, czy token jest ważny i czy serwer należy do tego konta (lub jest mu delegowany). Nie wie, co miałeś na myśli. Każde zabezpieczenie poniżej odpowiada na jedno pytanie: ile szkód da się narobić, gdy polecenie jest błędne?

Wszystkie narzędzia MCP według poziomu ryzyka

Token klienta widzi 45 narzędzi (serwer MCP 1.6.0). Token resellera (rk_…) widzi osobny zestaw 30 narzędzi resellerskich i żadnego z tych, więc endpoint ma ich łącznie 75. Twój klient dostaje z tools/list tylko własny zestaw.

Ta strona porządkuje narzędzia według ryzyka. Parametry i przykłady wywołań każdego z nich są w przewodniku po parametrach; wszystkie narzędzia w jednej linii, w tym 30 dla resellerów, są na pełnej liście.

Nie publikujemy jeszcze adnotacji narzędzi MCP (readOnlyHint, destructiveHint), więc klient nie posortuje ich sam. Ustaw zatwierdzenia ręcznie według poziomów poniżej.

Poziom 0 — publiczne, bez tokenu (5)

Poziom 1 — odczyt konta, bez skutków ubocznych (15)

Poziom 2 — zmieniają stan, niczego nie wydają (17)

Poziom 3 — wydają pieniądze, niszczą dane lub nadają dostęp (8)

Dziennik zmian zestawu narzędzi

Działająca wersja jest publiczna: curl -s https://mcp.eqvps.com/healthz. Gdy się zmieni, zmieni się też ta tabela.

Saldo to limit wydatków

EQVPS działa w modelu prepaid. Nie ma zapisanej karty, linii kredytowej ani debetu: najwięcej, ile agent może kiedykolwiek wydać, to to, co leży na saldzie. Wydają trzy narzędzia: order_vps, change_plan i create_sandbox. Odnowienia Twoich obecnych serwerów schodzą z tego samego salda.

Agent może tworzyć prośby o pieniądze, ale nie może ich opłacić. topup_balance i pay_invoice zwracają link do płatności krypto, a link bez portfela za nim nic nie robi. Nie ma też endpointu do wypłat: pieniądze z salda mogą kupić usługi na Twoim koncie, ale nie da się ich wyprowadzić. Zwroty przy natychmiastowym anulowaniu też wracają na saldo.

Jedno zastrzeżenie, i to poważne. Jeśli trzymasz saldo bardzo nisko, żeby przyhamować agenta, zaczną się sypać odnowienia Twoich własnych serwerów, które wejdą w okres karencji. Nasza zasada: jeden cykl odnowień tego, co już działa, plus budżet bieżącego zadania agenta. Poradnik o budżecie agenta pokazuje, jak to policzyć. A jeśli dasz agentowi własny portfel z pieniędzmi, ten portfel stanie się drugim limitem, którego też trzeba pilnować.

Najmniejsze uprawnienia: tokenu tylko do odczytu (jeszcze) nie ma

Wprost: każdy token klienta ma te same uprawnienia co konto w panelu. Nazwę i czas życia tokenu można ustawić, zakresów (scopes) — nie.

Najwęższe, co jest dziś dostępne, to delegowanie. Zakładasz agentowi własne konto z zerowym saldem i delegujesz mu jeden serwer:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

To samo przez REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

Zaproszenie trzeba przyjąć, będąc zalogowanym na ten e-mail (accept_delegation), a expires_days wynosi od 1 do 365. Krok po kroku ze zrzutami ekranu: delegowanie dostępu i dostęp w dokumentacji.

Zwróć uwagę na dwa ostatnie wiersze po lewej. Delegat nie wyda Twoich pieniędzy, ale może skasować ten serwer. Włącz kopie zapasowe na każdym serwerze, który agent może przeinstalować.

Higiena tokenów

Jeden token na agenta, z nazwą. Utwórz go w Panel → Ustawienia → Tokeny API dla agentów albo tak:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

Token jest pokazywany tylko raz. Czas życia od 1 do 1825 dni, 365, jeśli nic nie podasz. Dla agentów wybralibyśmy 90.

Trzymaj go w pliku, który możesz czytać tylko Ty, nie w repozytorium, nie w prompcie i nie w zmiennej powłoki, którą kopiujesz tu i tam:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # oczekiwane: -rw-------

Potem wczytaj go w usłudze agenta przez EnvironmentFile= (systemd) albo set -a; . ~/.config/eqvps/agent.env; set +a.

Rotuj przed wygaśnięciem. Narzędzie refresh_token albo POST /auth/tokens/{id}/refresh wydaje nowy token o tej samej nazwie i od razu unieważnia stary. Jeśli token jest wpisany na sztywno w konfiguracji klienta MCP, zaktualizuj ją zaraz potem, inaczej następna sesja dostanie 401.

Sprawdzaj, kto czego używa: GET /auth/tokens pokazuje każdy token z nazwą, datą wygaśnięcia i last_used_at. Nieznany token albo taki, którego użyto po wyłączeniu agenta, to Twój sygnał.

Gdy token wycieknie

W tej kolejności:

1. Unieważnij go. Panel → Ustawienia → Tokeny API dla agentów → Unieważnij, albo curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Przestaje działać od następnego żądania.
2. Poszukaj nowych tokenów, których nie tworzyłeś, i też je unieważnij.
3. Sprawdź, co mogło zostać naruszone: historię usługi każdego serwera, faktury i saldo oraz list_delegations pod kątem dostępu, którego nie nadawałeś.
4. Zmień hasła root na każdym serwerze, który ten token widział. get_vps_status z reveal: true oddaje hasło root, więc wyciekły token to wyciekłe hasło root. Przy okazji sprawdź ~/.ssh/authorized_keys.
5. Zamknij drzwi z hasłem. Jeśli Twoje konto nigdy nie miało hasła, posiadacz tokenu mógł je ustawić przez set_password. Zaloguj się kodem z e-maila i zmień je.

Zapobieganie punktowi 5 nic nie kosztuje: ustaw hasło konta sam już teraz, a set_password będzie zwracać 409 każdemu po Tobie.

Zatwierdzanie przez człowieka

Co egzekwuje serwer:

• reinstall_vps, reset_password i cancel_service z type: immediate wymagają confirm równego dokładnej nazwie hosta (DELETE działa też przy reinstalacji i resecie).
• change_plan wymaga confirm: true.
• Domyślne anulowanie to end_of_period: serwer działa do końca opłaconego okresu, a undo_cancel to cofa.
• Limity na konto: reinstalacja 4/min, reset hasła 6/min, zasilanie 20/min, zamówienia 20/min. Wystarczy, by pętla nie zrobiła tego pięćdziesiąt razy, ale nie zatrzyma jednego błędnego wywołania.

Miej jasność, czym jest confirm. Powstrzymuje agenta przed działaniem na podstawie „posprzątaj tam”. Nie zatrzyma atakującego, bo nazwa hosta jest o jedno wywołanie get_vps_status dalej. Prawdziwe zatwierdzanie żyje w Twoim kliencie MCP. Większość klientów potrafi pytać przed każdym wywołaniem: poziomy 0 i 1 puszczaj swobodnie, poziom 3 zawsze z pytaniem. W klientach z uprawnieniami per narzędzie, np. w settings.json Claude Code (serwer zarejestrowany jako eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Dodaj też linijkę do instrukcji agenta. Sama w sobie nie jest zabezpieczeniem, ale ogranicza nieporozumienia (zostaw ją po angielsku, modele rozumieją ją tak samo):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Jeśli agent loguje się kodem z e-maila zamiast trzymać długożyjący token, zobacz logowanie agenta przez MCP.

Audyt: co widać potem

• Lista tokenów (GET /auth/tokens albo Ustawienia → Tokeny API dla agentów): nazwa, data utworzenia, wygaśnięcie, last_used_at. Dlatego warto nazywać tokeny według agentów.
• Historia usługi (panel, strona serwera): włączenia i wyłączenia, reinstalacje, resety hasła, zmiany planu, płatności, każde z czasem i źródłem: Ty, support albo automatycznie. Nie pokaże, który token czy delegat to zrobił, tylko że akcja przyszła z Twojej strony.
• Faktury i saldo: każde obciążenie i zwrot.
• list_delegations: kto ma dostęp, do czego i do kiedy.

Ta luka w historii usługi to dziś uczciwa granica audytu po stronie serwera. Jeśli musisz wiedzieć, który agent co zrobił, loguj każde wywołanie narzędzia z argumentami (bez sekretów) po stronie agenta.

Konfiguracja, którą wybralibyśmy

Dla agenta, który obsługuje jeden serwer produkcyjny:

1. Osobne konto dla agenta, zerowe saldo, serwer delegowany z expires_days: 90.
2. Twój token właściciela zostaje u Ciebie i nie leży w żadnej konfiguracji agenta.
3. Kopie zapasowe na tym serwerze, bo delegat może go przeinstalować.
4. Narzędzia poziomu 3 w kliencie na „ask” albo „deny”.
5. Token agenta w pliku z prawami 600, odnawiany przed wygaśnięciem.

Agentowi, który musi zamawiać serwery albo uruchamiać sandboxy, delegowanie nie wystarczy, bo potrzebuje salda. Wtedy limitem jest saldo: doładowuj je pod konkretne zadanie, nazwij token i raz w tygodniu zajrzyj do last_used_at. Jeśli token tylko do odczytu zmieniłby to, jak uruchamiasz agentów, napisz do nas przez support: właśnie takie opinie decydują o tym, co budujemy dalej.