Bezpieczeństwo i codzienna praca - MCP
Na tej stronie Uprawnienia klucza
Uprawnienia klucza
Każdy klucz MCP dostaje własny zestaw uprawnień, niezależny od innych kluczy tego samego konta:
| Uprawnienie | Co odblokowuje |
|---|---|
monitoring.read | alerty i dzienne statystyki monitoringu |
projects.read | listę projektów i ich bieżący stan |
projects.write | zakładanie i edycję projektów |
projects.delete | usuwanie projektów |
issues.read | listę błędów - wyłącznie metadane grupy |
issues.details | pełną treść błędu: komunikat, miejsce awarii, stos |
issues.write | zmianę statusu błędu |
issues.delete | usuwanie błędów |
Narzędzie, na które klucz nie ma odpowiedniego uprawnienia, nie pojawia się w odpowiedzi tools/list - to nie jest ukryta opcja, tylko brak narzędzia z perspektywy tego klucza.
issues.details jest wyjątkiem
To jedyne uprawnienie domyślnie niezaznaczone, bo odsłania dane wrażliwsze niż reszta: bez niego issues.list zwraca tylko metadane grupy błędu (token projektu, typ, status, liczbę zdarzeń, daty), a narzędzie issues.get w ogóle nie istnieje dla tego klucza. Z tym uprawnieniem lista dokłada komunikat błędu i miejsce awarii, a issues.get zwraca pełny obraz jednej grupy - łącznie ze stosem wywołań, ramkami z fragmentem kodu, danymi żądania i historią dzienną. Zaznacz je świadomie, dopiero gdy narzędzie rzeczywiście ma diagnozować błędy, a nie tylko liczyć je.
Zakres klucza to przecięcie z uprawnieniami wydawcy
Klucz nie żyje własnym życiem - przy każdym żądaniu jego zapisane uprawnienia są przecinane z aktualnymi uprawnieniami osoby, która go wystawiła. Zdegradowanie tej osoby albo dezaktywowanie jej konta zawęża albo unieważnia klucz od najbliższego żądania, bez żadnej dodatkowej akcji. Zawężenie dotyczy tylko odczytu w pamięci - wiersz klucza w bazie zostaje nietknięty, więc przywrócenie dawnych uprawnień wydawcy od razu przywraca pełny zakres klucza.
Czego serwer MCP nigdy nie wypuszcza
Dane projektu nie zawierają kluczy prywatnych, a szczegóły błędu nigdy nie zawierają adresu e-mail, nazwy użytkownika, identyfikatora użytkownika ani adresu IP z ładunku klienta. Nagłówki żądania idą przez listę dozwolonych, nie zakazanych - nowy nagłówek uwierzytelniający u klienta nie wycieka tylko dlatego, że nikt jeszcze go tu nie dopisał; liczba pominiętych nagłówków jedzie w odpowiedzi jako headers_omitted. Wartości zmiennych lokalnych ramek stosu nie wychodzą wcale, a kod źródłowy jest dołączany tylko do ramek aplikacji klienta.
Audyt i limity żądań
Każde wywołanie narzędzia trafia do dziennika audytowego razem z adresem IP zapisanym jako skrót. Żądanie z nagłówkiem Origin wskazującym obcą domenę kończy się 403 - przeglądarka nie ma tu czego szukać, ten endpoint jest dla klientów serwerowych. Limit liczby żądań jest kluczowany skrótem tokenu, więc jeden przeciążony klient nie zjada limitu pozostałym kluczom konta.