Do czego ma dostęp
Uczciwa granica.
To Twoja rola decyduje, które narzędzia istnieją
Serwer działa jako Ty, na połączeniu, które uczyniłeś aktywnym. Nie ma osobnego konta serwisowego ani szerszego dostępu niż Twój własny. Odkąd pojawiły się role, nie ma też szerszego dostępu niż Twoja ROLA. Lista narzędzi, którą dostaje klient, budowana jest z uprawnień, jakie masz w aktywnej przestrzeni roboczej, więc klient osoby z rolą Viewer w ogóle nie wymienia sendEmail, createRule ani sendWithTemplate.
To mocniejsze niż odmowa wywołania. Narzędzie, którego nie ma na liście, nie jest narzędziem, o którym model rozmyśla, nie zjada kontekstu i nie da się go spróbować w czyimś imieniu, a potem za to przepraszać. Oznacza to też, że pusto wyglądający klient to zwykle uprawnienie, którego nie masz, a nie funkcja, której temu serwerowi brakuje — i dokładnie po to istnieje whoAmI.
Rejestracja i wywołanie to dwie bramki, a trzyma tylko ta druga. Lista budowana jest raz, przy otwarciu sesji, a setActiveConnection może przenieść tę sesję do skrzynki, w której wolno Ci mniej, więc lista jest z założenia nieaktualna, a protokół nie ma sposobu, żeby wycofać narzędzie w trakcie sesji. Dlatego każde bramkowane narzędzie przed uruchomieniem ponownie ustala Twoją rolę względem BIEŻĄCEGO połączenia. Rejestracja to uprzejmość; wywołanie to granica.
Odmowa nazywa obie połowy, jak w Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, więc agent może to wyjaśnić osobie, dla której pracuje, i przestać próbować, zamiast ponawiać nieprzejrzysty błąd, aż ktoś się podda. Rola zmieniona przez administratora przy otwartej sesji działa tak samo — już przy następnym wywołaniu.
Adresy to druga oś i nic z tego ich nie dotyczy. Rola mówi, co wolno Ci robić; przyznane Ci adresy mówią, na których skrzynkach wolno Ci to robić, a zanim wiadomość wyjdzie, obie rzeczy muszą się zgadzać.
Sam token nadal jest bez zakresu
Tym, co się NIE zmieniło, jest sama zgoda. Token, który dostaje aplikacja, sięga wszystkiego, na co pozwala Twoja rola, a nie podzbioru wybranego przy zatwierdzaniu, więc zatwierdzenie klienta jest zatwierdzeniem go do wszystkiego, co możesz zrobić w tej przestrzeni roboczej. Przed udzieleniem czegokolwiek widzisz, co prosi o dostęp, a Account → Connected apps usuwa aplikację później, kasując każdy trzymany przez nią token i stojącą za nim zgodę, ale wybór „tylko do odczytu, dla tej aplikacji” nie jest zbudowany.
Sufit klienta MCP jest więc Twoim sufitem. Zawężenie tego, co może aplikacja, oznacza zawężenie roli osoby, która ją podłączyła, a to zawęża również to, co ta osoba może w samej aplikacji. Taki jest dziś uczciwy kształt tego mechanizmu i dlatego zakres nadawany osobno przy każdej zgodzie wciąż wart jest zbudowania.
Słownictwo jest już wspólne: uprawnienia roli i zakresy klucza API czerpią z jednego alfabetu, dzięki czemu uprawnienia klucza da się policzyć jako część wspólną obu. Zakres MCP nadawany przy pojedynczej zgodzie, gdy powstanie, zostanie wyrażony tymi samymi słowami.