Zarządzanie łącznikiem MCP za pośrednictwem bramy API AI: tokeny OAuth, zakresy narzędzi i przypisanie poszczególnych użytkowników

Kiedy agent wywołuje Gmaila, Drive, Stripe, system wewnętrzny lub zdalny serwer MCP, żądanie modelu stanowi tylko część zdarzenia bezpieczeństwa. Prawdziwe pytanie operacyjne brzmi: kto autoryzował łącznik, jakie OAuth zakresy zostały przyznane, jakie narzędzie zostało wywołane, jakie dane opuściły granicę dostawcy modelu i w jaki sposób można odwołać dostęp w trakcie incydentu?

Brama AI API, która wywołuje tylko modele proxy, nie może odpowiedzieć na te pytania. Może znać najemcę, model, klucz API, rozmiar podpowiedzi i koszt. Może nie wiedzieć, że model przekazał pracę łącznikowi działającemu pod tokenem OAuth użytkownika. Ta luka osłabia atrybucję, politykę zatwierdzania, unieważnianie i reakcję audytu.

Praktyczny wzorzec polega na traktowaniu autoryzacji złącza MCP jako obiektu płaszczyzny sterującej bramy pierwszej klasy. Nie ograniczaj zarządzania łącznikami do listy dozwolonych nazw narzędzi. Zarządzaj rejestracją oprogramowania sprzęgającego, OAuth pochodzeniem tokena, klasyfikacją zakresu narzędzi, zasadami zatwierdzania, stanem unieważnienia i rejestrowaniem inspekcji w ramach tej samej warstwy zarządzania, która obsługuje już API zarządzanie kluczami, dostęp do modeli, zasady dzierżawy i analizę użycia.

Fakty, zalecenia i prognozy

Fakty: OpenAI dokumentuje zdalne MCP jako kategorię narzędzi Odpowiedzi API i umożliwia aplikacjom dostarczanie OAuth tokenu dostępu dla zdalnego serwera MCP. OpenAI identyfikuje także łączniki usług hostowanych, takie jak Gmail, Google Dysk, Google Kalendarz, Dropbox i Microsoft Teams. Z dokumentacji dotyczącej kontroli danych OpenAI wynika, że ​​serwery MCP używane z narzędziem MCP zdalnego serwera są usługami stron trzecich i przesyłane do nich dane podlegają zasadom przechowywania tych usług. Dokumentacja łącznika Anthropic opisuje niestandardowe łączniki korzystające ze zdalnych serwerów MCP i zauważa, że ​​użytkownicy często autoryzują łączniki za pośrednictwem OAuth, z uprawnieniami, które można później odwołać. Specyfikacja autoryzacji MCP wykorzystuje autoryzację w stylu OAuth dla transportów HTTP opartych na MCP. OAuth wskazówki dotyczące bezpieczeństwa zawarte w dokumencie RFC 9700 dotyczą obsługi tokenów, przepływów kodu autoryzacyjnego i bezpieczeństwa klienta.

Zalecenia: Brama powinna rejestrować łączniki przed użyciem w środowisku produkcyjnym, wiązać każde wywołanie łącznika z dzierżawcą, kluczem, użytkownikiem, podmiotem tokenu i tożsamością serwera, klasyfikować narzędzia według ryzyka odczytu/zapisu, egzekwować zasady zatwierdzania przed wysłaniem i centralnie utrzymywać stan unieważnienia.

Przewidywania: Zdalne MCP przyjęcie spowoduje, że bramy AI wykroczą poza routing modelu i pomiar tokenów. Bramy, które nie widzą tożsamości konektora, OAuth zakresu, decyzji zatwierdzających i granic przechowywania na dalszym etapie, będą trudniejsze w użyciu w środowiskach regulowanych, korporacyjnych i obsługiwanych przez partnerów.

Problemem zarządzania jest podział tożsamości

Wywołania oprogramowania sprzęgającego obejmują co najmniej trzy tożsamości i nie należy ich łączyć w dziennikach ani kontrolach zasad.

• Obiekt wywołujący bramę: klucz API, konto usługi, obciążenie lub aplikacja partnera, która przesłała żądanie modelu.
• Wyznaczony użytkownik: osoba lub użytkownik końcowy, który autoryzował dostęp do Gmaila, Dysku, CRM, kalendarza, płatności, danych wewnętrznych lub innego chronionego zasobu.
• Cel złącza: zdalny MCP serwer lub łącznik usługi hostowanej, który odbiera wywołanie narzędzia i może je przekazać do innego systemu.

Jeśli te tożsamości zostaną zgrupowane w jednym polu o nazwie user, ścieżka audytu stanie się niejednoznaczna. Konto usługi produkcyjnej może przesłać żądanie w imieniu 20 000 użytkowników końcowych. Jeden człowiek może autoryzować kilka łączników o różnych zakresach. Zdalny serwer MCP może udostępniać narzędzia obsługiwane przez wiele usług podrzędnych. Brama wymaga oddzielnych pól dla wszystkich trzech.

Przydatny model zdarzenia zaczyna się od pól takich jak:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

Ta struktura pozwala zespołom ds. bezpieczeństwa, finansów i platform odpowiadać na różne pytania na podstawie tego samego rekordu. Który najemca wywołał to narzędzie? Który klucz aplikacji to zrobił? Który użytkownik końcowy przekazał dostęp? Które złącze odebrało dane? Czy działanie było tylko do odczytu, czy miało charakter destrukcyjny? Czy wymagana była zgoda?

Modelowe łączniki jako zasoby bramy

Konektor powinien zostać zarejestrowany przed użyciem go w środowisku produkcyjnym. Rejestracja nie musi być powolna, ale powinna dać trwały obiekt, do którego będą mogły odwoływać się zasady.

Minimalny zasób oprogramowania sprzęgającego może obejmować:

• tenant_id: dzierżawca lub organizacja może korzystać z łącznika.
• connector_id: stabilny identyfikator wewnętrzny, niezależny od wyświetlanych nazw serwerów.
• server_url: adres URL zdalnego MCP serwera lub identyfikator hostowanego oprogramowania sprzęgającego.
• owner_user_id: administrator lub użytkownik, który go zarejestrował.
• authorization_server: metadane wydawcy lub serwera autoryzacji, jeśli są dostępne.
• allowed_tools: sprawdzone nazwy i wersje narzędzi lub odciski palców.
• tool_classes: odczyt, zapis, eksport, administracja, płatność, przesyłanie wiadomości lub nieznane.
• approved_scopes: OAuth zakresów zatwierdzonych dla łącznika.
• retention_class: wewnętrzny, dostawca modeli, standard innej firmy lub zabroniony w przypadku wrażliwych obciążeń.
• revocation_status: aktywny, user_revoked, tenant_disabled, wygasł, poddany kwarantannie lub odrzucony.

Jest to podobne do profilu modelu lub rekordu danych uwierzytelniających dostawcy, ale autoryzacja oprogramowania sprzęgającego to nie ten sam obiekt, co klucz modelu nadrzędnego. Poświadczenia środowiska wykonawczego dostawcy umożliwiają wywoływanie interfejsów API modelu bramy. Tokeny łącznika reprezentują uprawnienia delegowane do systemów zewnętrznych lub wewnętrznych. Zasługują na osobne pochodzenie, kontrolę przechowywania i zasady audytu.

Broker lub zweryfikuj OAuth tokeny celowo

Istnieją dwa typowe wzorce wdrażania.

Broker przez bramę OAuth

W tym modelu brama inicjuje lub koordynuje przepływ OAuth, przechowuje tokeny odświeżania lub materiał tokenów dostępu w skarbcu, zarządza krótkotrwałymi sesjami łącznika i dołącza tokeny dostępu podczas wysyłania zdalnych wywołań MCP. Daje to bramie silną kontrolę nad zgodą, czasem życia tokena, unieważnianiem i przyłączaniem inspekcji.

Kompromisem jest złożoność. Brama musi obsługiwać ekrany zgody, zabezpieczenia przepływu kodu autoryzacyjnego, odświeżanie tokenów, rotację tokenów, szyfrowany magazyn, zarządzanie przekierowaniami URI, weryfikację wystawcy i konfigurację aplikacji OAuth specyficzną dla dzierżawy. RFC 9700 ma tutaj znaczenie, ponieważ ten wzorzec stawia bramę blisko OAuth obowiązków klienta.

Zarządzane przez aplikację OAuth

W tym modelu aplikacja uzyskuje token OAuth i przekazuje go przez model lub ścieżkę bramy podczas wywoływania zdalnego konektora MCP. Wysyłka może być szybsza, ponieważ istniejące produkty mogą już mieć procesy autoryzacji oprogramowania sprzęgającego.

Kompromisem jest fragmentaryczne zarządzanie. Jeśli brama widzi tylko nieprzezroczysty token, może nie znać podmiotu, zakresów, wystawcy, aktualności, statusu unieważnienia ani pochodzenia zgody tokenu. Bezpieczniejsza wersja tego wzorca wymaga, aby aplikacja dostarczała podpisane metadane łącznika przy każdym wywołaniu, a brama powinna przed wysłaniem sprawdzić wystawcę, odbiorców, wygaśnięcie, rejestrację łącznika, powiązanie użytkownika i zatwierdzony zakres.

W przypadku łączników danych użytkownika, takich jak poczta e-mail, kalendarz, pamięć masowa, CRM i płatności, preferuj tokeny OAuth dla poszczególnych użytkowników. Udostępnione, długotrwałe tokeny okaziciela powinny być ograniczone do jawnych przepływów pracy na koncie usługi w zakresie obejmującym dzierżawcę i sprawdzane jako zasoby o wyższym ryzyku.

Normalizuj zakresy narzędzi przed wysyłką

MCP serwery mogą ujawniać nazwy narzędzi i metadane, a niektóre ekosystemy udostępniają wskazówki, takie jak adnotacje tylko do odczytu. Korzystaj z tych sygnałów, ale nie traktuj metadanych dostarczonych przez serwer jako w pełni zaufanych. Metadane narzędzi mogą być błędne, nieaktualne, niejednoznaczne lub kontradyktoryjne. Wytyczne OWASP MCP podkreślają najniższe uprawnienia, umieszczanie na listach dozwolonych, uwierzytelnianie, autoryzację i monitorowanie; MCP 10 najważniejszych prac również zwraca uwagę na ryzyko zatrucia narzędzi.

Brama powinna utrzymywać własne znormalizowane klasy akcji:

• Przeczytaj: szukaj, wyświetlaj listę, pobieraj, pobieraj, pobieraj, podsumowuj istniejącą treść.
• Napisz: twórz, aktualizuj, edytuj, oznaczaj etykietami, przenoś, komentuj, planuj.
• Wyślij: e-mail, wiadomość na czacie, webhook, odpowiedź na zgłoszenie, powiadomienie.
• Usuń: usuń, wyczyść, zarchiwizuj, unieważnij.
• Eksport: pobieranie zbiorcze, przesyłanie plików, wyodrębnianie zbioru danych.
• Finanse: obciążenie, zwrot pieniędzy, faktura, wypłata, zmiana subskrypcji.
• Administrator: zmiana uprawnień, zaproszenie użytkownika, aktualizacja roli, edycja zasad.
• Nieznane: wszystko, co nie zostało sprawdzone lub nie zostało sklasyfikowane w sposób pewny.

Następnie egzekwuj zasady dotyczące znormalizowanych klas zamiast surowych nazw narzędzi. Na przykład:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

Dzięki temu zasady są stabilne, gdy łącznik zmienia nazwę gmail.search na mail.messages.query. Surowe narzędzie nadal wymaga przeglądu, ale system zatwierdzania może uzasadniać w kategoriach operacyjnych.

Przeprowadź kontrolę oprogramowania sprzęgającego przed wysyłką

Zanim brama zezwoli na zainicjowane przez model wywołanie łącznika, powinna podjąć kompaktową decyzję przed wysłaniem. W tym miejscu spotykają się analiza wykorzystania sztucznej inteligencji, zasady bezpieczeństwa, przepływ zatwierdzania i zasady przechowywania.

Praktyczna sekwencja to:

1. Rozwiąż dzierżawę i klucz: zidentyfikuj klucz bramy, dzierżawcę, obciążenie, środowisko i żądanie modelu.
2. Rozwiąż problem z użytkownikiem końcowym: wymagaj stabilnego identyfikatora użytkownika końcowego dla delegowanych łączników. Odrzucaj anonimowe delegowane połączenia, chyba że zostało to wyraźnie dozwolone.
3. Rozwiąż łącznik: dopasuj adres URL serwera lub identyfikator hostowanego łącznika do zarejestrowanego zasobu łącznika.
4. Sprawdź token: sprawdź wystawcę, odbiorców, jeśli ma to zastosowanie, wygaśnięcie, temat, powiązanie dzierżawy, stan unieważnienia i wymagane zakresy.
5. Klasyfikuj działanie: mapuj nazwę narzędzia i metadane do odczytu, zapisu, wysyłania, usuwania, eksportowania, finansów, administratora lub nieznane.
6. Sprawdź granicę przechowywania: określ, czy obciążenie pozwala na przetwarzanie i rejestrowanie MCP serwera innej firmy.
7. Zastosuj zasady zatwierdzania: automatyczne zezwalanie, wymaganie zatwierdzenia przez użytkownika, wymaganie zatwierdzenia przez administratora, blokowanie lub kwarantanna.
8. Zarezerwuj budżet, jeśli podlega rozliczeniu: jeśli wykonanie łącznika wiąże się z opłatami bezpośrednimi lub pośrednimi, zarezerwuj budżet przed wysyłką.
9. Zapisz decyzję: utrwal decyzję przed wywołaniem konektora, a nie tylko po sukcesie.

Najważniejsze jest napisanie decyzji. Jeśli przekroczony zostanie limit czasu łącznika, nastąpi częściowe przesyłanie strumieniowe danych wyjściowych lub wywołany zostanie błąd w dalszej części, dziennik kontrolny powinien nadal wykazywać, że brama zezwoliła na określoną próbę działania lub ją odrzuciła.

Zatwierdzanie powinno uwzględniać przepływ pracy

Zatwierdzanie poszczególnych połączeń jest łatwe do uzasadnienia i często nie nadaje się do zastosowania w praktyce. Pracownik obsługi klienta, który musi przeczytać zgłoszenie, przeszukać Dysk, przygotować e-mail i zaktualizować rekord w CRM, nie powinien zmuszać użytkownika do wykonywania każdej nieszkodliwej operacji odczytu. Jednocześnie wysyłanie wiadomości e-mail, usuwanie pliku, zwrot płatności lub eksportowanie folderu nie powinny być delegowane w trybie cichym, ponieważ modelka wybrała narzędzie.

Praktyczna polityka jest wielowarstwowa:

• Automatycznie zezwalaj na sprawdzone narzędzia tylko do odczytu dla dzierżawców niskiego ryzyka i autoryzację nowych użytkowników.
• Wymagaj zgody na wysyłanie, tworzenie, aktualizowanie, usuwanie, eksportowanie, działania finansowe i administracyjne.
• Zezwól na grupowe zatwierdzanie nazwanego przepływu pracy, zakresu i okna czasowego.
• Wymagaj ponownego zatwierdzenia w przypadku rozszerzenia zakresu, istotnej zmiany definicji narzędzi lub łącznika przeniesionego do wyższej klasy ryzyka.
• Blokuj nieznane narzędzia do czasu ich sprawdzenia.

Zatwierdzenia grupowe powinny być jednoznaczne. Użytkownik może zatwierdzić: „Przez następne 30 minut zezwól temu procesowi pomocy na przeszukiwanie Dysku i wersje robocze odpowiedzi, ale wymagaj potwierdzenia przed wysłaniem”. Jest to bardziej przydatne niż przełącznik zezwalania/odmawiania złącza binarnego.

Granice przechowywania wymagają własnego pola

Zdalne wywołania MCP mogą przenosić dane poza granice przechowywania i przetwarzania dostawcy modelu. Nie jest to automatycznie złe, ale musi być widoczne. Obciążenie, które może korzystać z punktu końcowego modelu w ramach jednego ustawienia przechowywania danych, może nadal mieć zakaz wysyłania tej samej treści na serwer MCP innej firmy z innymi warunkami przechowywania.

Dodaj klasyfikację przechowywania zarówno do obciążeń, jak i do łączników. Przykładowe zajęcia:

• internal_only: niedozwolone są połączenia z oprogramowaniem sprzęgającym innych firm.
• approved_processors_only: oprogramowanie sprzęgające musi znajdować się na liście zatwierdzonych dostawców.
• third_party_standard_allowed: dozwolone jest standardowe przetwarzanie oprogramowania sprzęgającego SaaS.
• no_argument_logging: dozwolone są wywołania oprogramowania sprzęgającego, ale argumenty muszą zostać zredagowane lub zaszyfrowane.
• export_blocked: zezwolenie na odczyt/wyszukiwanie, eksport zbiorczy zabroniony.

W tym miejscu brama chroni zespoły przed subtelnym błędem: założeniem, że kontrola danych dostawcy modeli automatycznie stosuje się do każdego narzędzia używanego przez agenta. Niekoniecznie mają one zastosowanie po wysłaniu danych do MCP zdalnego serwera lub zewnętrznego łącznika usług.

Utwórz księgę audytu oprogramowania sprzęgającego

Księga audytu oprogramowania sprzęgającego powinna łączyć żądania modelu, autoryzację bramy, wysyłkę łącznika i dalsze wyniki. Nie polegaj wyłącznie na nieprzetworzonych śladach dostawcy, ponieważ każdy dostawca może inaczej ujawniać zdarzenia narzędzia, a dzienniki aplikacji mogą pomijać token lub kontekst zatwierdzania.

Zalecane pola księgi obejmują:

• model_request_id i identyfikator śledzenia.
• tenant_id, gateway_key_id, obciążenie, środowisko i identyfikator użytkownika końcowego.
• connector_id, skrót adresu URL serwera, identyfikator hostowanego oprogramowania sprzęgającego i klasa ryzyka.
• tool_name, wersja narzędzia lub odcisk metadanych i znormalizowana klasa działania.
• OAuth wydawca, temat tokena, skrót zestawu zakresu, przedział wygaśnięcia i pochodzenie tokena.
• Skrót argumentów, zredagowane argumenty, klasa wrażliwości i klasa przechowywania.
• Decyzja o zatwierdzeniu, osoba zatwierdzająca, zakres zatwierdzenia i wygaśnięcie zatwierdzenia.
• Stan wysyłki, status odpowiedzi, klasa błędu, opóźnienie i identyfikatory żądań dalszych, jeśli są dostępne.

Pełne rejestrowanie argumentów może pomóc w reagowaniu na incydenty, ale zwiększa również ryzyko prywatności i przechowywania. Domyślnie preferuj pola strukturalne, hashowanie, redakcję selektywną i tagi czułości. Zezwalaj na pełne przechwytywanie tylko w ramach wyraźnych zasad dotyczących incydentów lub debugowania z datą wygaśnięcia.

Odwołanie i kwarantanna to wymagania dotyczące produktu

Odwołanie nie może być ręczną edycją bazy danych. Użytkownicy i administratorzy potrzebują przepływów pracy, które przekształcają się w natychmiastowy stan zasad.

Wdrożyj przynajmniej te działania:

• Odłączenie użytkownika: unieważnij lub oznacz jako nieaktywne wszystkie tokeny dla autoryzacji oprogramowania sprzęgającego jednego użytkownika.
• Wyłączenie dzierżawy: zablokuj jedno złącze dla całego dzierżawcy bez wyłączania niepowiązanego ruchu modelu.
• Obsługa wygaśnięcia tokena: zamknięcie zakończone niepowodzeniem lub ponowna autoryzacja w przypadku niepowodzenia odświeżenia lub świeżości autoryzacji przekraczającej zasady.
• Kwarantanna łącznika: blokuje łącznik, zachowując jego konfigurację i dzienniki na potrzeby sprawdzenia.
• Awaryjna lista odrzuconych: blokowanie na podstawie skrótu adresu URL serwera, identyfikatora złącza, wydawcy lub odcisku palca narzędzia.
• Obniżenie zakresu: ponowna autoryzacja z mniejszą liczbą zakresów, gdy przepływ pracy nie wymaga już szerokiego dostępu.

Ważny szczegół implementacji polega na tym, że status unieważnienia należy sprawdzić w momencie wysyłki. Conocna synchronizacja jest przydatna do uzgadniania, ale nie jest wystarczająca do reagowania na incydenty.

Sondy zgodności dla zdalnych MCP złączy

Zanim łącznik będzie dostępny dla dzierżawców produkcyjnych, przetestuj go jako zależność regulowaną. Krótki zestaw sond pozwala wykryć wiele błędów integracji i zasad.

• Wykrywanie metadanych zwraca stabilną tożsamość serwera i oczekiwane definicje narzędzi.
• Metadane zasobów chronionych i zachowanie autoryzacji są zgodne z udokumentowanymi założeniami, tam gdzie ma to zastosowanie.
• Wymagania dotyczące rejestracji klienta dynamicznego są zrozumiałe, obsługiwane lub wyraźnie wyłączone.
• Żądania bez tokenów bezpiecznie kończą się niepowodzeniem.
• Wygasłe tokeny kończą się niepowodzeniem w przewidywalny sposób i nie powodują niekontrolowanych ponownych prób.
• Klasyfikacja odczytu/zapisu odpowiada zaobserwowanemu zachowaniu, a nie tylko opisom.
• Zniekształcone metadane narzędzia zostały odrzucone lub oznaczone jako nieznane.
• Zmiany listy narzędzi powodują przegląd w przypadku zmiany nazw, zakresów, opisów lub klas ryzyka.
• Błędy łącznika są rejestrowane bez wyciekania poufnych argumentów do ogólnych pól błędów.

Te sondy nie zastępują kontroli bezpieczeństwa, ale zapewniają bramie powtarzalny sposób wykrywania dryfowania. Zdalne MCP serwery mogą zmieniać się niezależnie od dostawcy modelu i niezależnie od cyklu wydawania aplikacji.

Lista kontrolna wdrożenia

• Utwórz rejestr oprogramowania sprzęgającego z polami dzierżawcy, serwera, autoryzacji, zakresu, narzędzia, ryzyka, przechowywania i odwołania.
• Oddzielna tożsamość klucza bramy, delegowana tożsamość użytkownika końcowego i tożsamość łącznika przy każdej decyzji dotyczącej zasad.
• Przechowuj tokeny łącznika w skarbcu referencji, ale trzymaj je oddzielnie od danych uwierzytelniających środowiska wykonawczego dostawcy modelu.
• Preferuj na użytkownika OAuth w przypadku łączników danych użytkownika; ogranicz tokeny usług wspólnych do jawnych przepływów pracy na koncie usługi.
• Normalizacja działań narzędzi na odczyt, zapis, wysyłanie, usuwanie, eksport, finanse, administratora i nieznane.
• Przeprowadź kontrole przed wysyłką pod kątem rejestracji oprogramowania sprzęgającego, ważności tokenu, dopasowania zakresu, zgodności przechowywania, stanu zatwierdzenia i rezerwacji budżetu.
• Dziennikuj decyzje dotyczące oprogramowania sprzęgającego przed wysyłką i ustalaj ostateczny stan po odpowiedzi lub błędzie.
• Utwórz procedury odłączania użytkowników, wyłączania dzierżawców, kwarantanny oprogramowania sprzęgającego i awaryjnej listy odrzuconych.
• Przed użyciem w środowisku produkcyjnym sprawdź metadane złącza, zachowanie tokena, dryf narzędzia i zniekształcone metadane.

Wnioski, które można zastosować

MCP i łączniki usług czynią agentów użytecznymi, ponieważ pozwalają modelom działać na rzeczywistych systemach. Ta sama użyteczność sprawia, że ​​autoryzacja łącznika staje się problemem płaszczyzny kontrolnej, a nie szczegółem inżynieryjnym.

Brama powinna znać więcej niż tylko model, liczbę tokenów i klucz API. Powinien wiedzieć, który konektor został wywołany, który użytkownik go autoryzował, jakie zakresy zostały przyznane, o jaką klasę akcji narzędzia zażądano, czy wymagane było zatwierdzenie, czy granica przechowywania była zgodna i w jaki sposób można odwołać dostęp. Zacznij od rejestru łączników, sprawdzenia zasad przed wysyłką i połączonej księgi audytu. Następnie dodaj OAuth pośrednictwo, zatwierdzenia grupowe, sondy zgodności i kwarantannę awaryjną w miarę wzrostu wykorzystania oprogramowania sprzęgającego.

Celem nie jest blokowanie MCP zdalnej adopcji. Celem jest zapewnienie, aby dostęp do konektora był możliwy do przypisania, odwołania, przeglądu i zgodności z tymi samymi oczekiwaniami dotyczącymi zarządzania, które zespoły już stosują w odniesieniu do dostępu do modelu i OpenAIkompatybilnej bramy API.

Powiązana lektura

• szersze wzorce zarządzania narzędziem agenta