Управление на MCP конектора чрез AI API Gateway: OAuth токени, обхват на инструмента и приписване на потребител

Когато агент извика Gmail, Drive, Stripe, вътрешна система или отдалечен MCP сървър, заявката за модел е само част от събитието за сигурност. Истинският оперативен въпрос е: кой е упълномощил конектора, кои OAuth обхвати са предоставени, кой инструмент е извикан, какви данни са напуснали границата на доставчика на модела и как може да бъде отменен достъпът по време на инцидент?

ИИ API шлюз, който само прокси моделира повиквания, не може да отговори на тези въпроси. Може да знае наемателя, модела, ключа API, размера на подканата и цената. Може да не знае, че моделът е делегирал работа на конектор, работещ под токена OAuth на човешки потребител. Тази празнина отслабва приписването, политиката за одобрение, отмяната и отговора на одита.

Практическият модел е да се третира MCP упълномощаването на конектора като първокласен обект на контролната равнина на шлюза. Не ограничавайте управлението на конектора до разрешен списък с имена на инструменти. Управлявайте записването на конектора, OAuth произхода на токена, класификацията на обхвата на инструмента, правилата за одобрение, състоянието на отмяната и регистрирането на одита като част от същия слой на управление, който вече обработва API управление на ключове, достъп до модела, политика на клиента и анализ на използването.

Факти, препоръки и прогнози

Факти: OpenAI документира отдалечено MCP като категория инструменти за отговори API и позволява на приложенията да предоставят OAuth токен за достъп за отдалечен MCP сървър. OpenAI също идентифицира конектори за хоствани услуги като Gmail, Google Диск, Google Календар, Dropbox и Microsoft Teams. В документацията за контрол на данните на OpenAI се казва, че MCP сървърите, използвани с отдалечения MCP сървърен инструмент, са услуги на трети страни и данните, изпратени до тях, са предмет на правилата за задържане на тези услуги. Документацията за конектора на Anthropic описва потребителски конектори, използващи отдалечени MCP сървъри и отбелязва, че потребителите обикновено разрешават конектори чрез OAuth, с разрешения, които по-късно могат да бъдат отменени. Спецификацията за оторизация MCP използва оторизация в стил OAuth за базирани на HTTP MCP транспорти. OAuth указанията за сигурност в RFC 9700 са подходящи за обработката на токени, потоците на кода за оторизация и сигурността на клиента.

Препоръки: Шлюзът трябва да регистрира конектори преди производствена употреба, да обвързва всяко извикване на конектор към клиент, ключ, потребител, субект на токен и идентичност на сървъра, да класифицира инструментите според риска при четене/запис, да налага политика за одобрение преди изпращане и да поддържа централно състояние на анулиране.

Прогнози: Отдалеченото MCP приемане ще изтласка AI шлюзовете отвъд маршрутизирането на модела и измерването на токени. Шлюзовете, които не могат да видят идентичността на конектора, OAuth обхвата, решенията за одобрение и границите на задържане надолу по веригата, ще бъдат по-трудни за използване в регулирани, корпоративни и управлявани от партньори среди.

Проблемът с управлението е разделянето на идентичността

Извикванията на конектор включват поне три самоличности и те не трябва да се обединяват в регистрационни файлове или проверки на правила.

• Повикващ шлюз: API ключът, акаунтът за услугата, работното натоварване или партньорското приложение, което е изпратило заявката за модел.
• Делегиран потребител: човек или краен потребител, който е разрешил достъп до Gmail, Диск, CRM, календар, плащания, вътрешни данни или друг защитен ресурс.
• Цел на конектора: отдалеченият MCP сървър или конектор за хоствана услуга, който получава извикването на инструмента и може да го препрати към друга система.

Ако тези самоличности се свият в едно поле, наречено user, одитната пътека става двусмислена. Акаунт за производствена услуга може да подаде заявка от името на 20 000 крайни потребители. Един човек може да упълномощи няколко конектора с различни обхвати. Отдалечен MCP сървър може да разкрие инструменти, поддържани от множество услуги надолу по веригата. Шлюзът се нуждае от отделни полета и за трите.

Полезният модел на събитието започва с полета като:

{
  "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"
}

Тази структура позволява на екипите по сигурността, финансите и платформата да отговарят на различни въпроси от един и същи запис. Кой наемател е извикал инструмента? Кой ключ на приложението го направи? Кой краен потребител делегира достъп? Кой конектор получи данни? Беше ли действието само за четене или разрушително? Изисква ли се одобрение?

Моделни конектори като ресурси за шлюз

Конекторът трябва да бъде регистриран, преди да бъде използван в производството. Не е необходимо записването да е бавно, но трябва да създаде устойчив обект, към който политиката може да се позовава.

Минимален ресурс за конектор може да включва:

• tenant_id: наемателят или организацията, на която е разрешено да използва конектора.
• connector_id: стабилен вътрешен идентификатор, независим от екранните имена на сървъра.
• server_url: URL на отдалечения MCP сървър или идентификатор на хостван конектор.
• owner_user_id: администраторът или потребителят, който го е записал.
• authorization_server: метаданни на издателя или сървъра за оторизация, когато има такива.
• allowed_tools: прегледани имена и версии на инструменти или отпечатъци.
• tool_classes: четене, писане, експортиране, администриране, плащане, съобщения или неизвестно.
• approved_scopes: OAuth одобрени обхвати за конектора.
• retention_class: вътрешен, доставчик на модел, стандарт на трета страна или забранен за чувствителни работни натоварвания.
• revocation_status: активен, user_revoked, tenant_disabled, изтекъл, поставен под карантина или отказан.

Това е подобно по дух на профил на модел или запис на идентификационни данни на доставчик, но упълномощаването на конектора не е същият обект като ключ на модел нагоре по веригата. Идентификационните данни за изпълнение на доставчика позволяват на шлюза да извиква API на модела. Токените на конектора представляват делегирани правомощия в системи на трети страни или вътрешни системи. Те заслужават отделен произход, контрол на съхранението и политика за одит.

Посредничество или валидиране OAuth Токени умишлено

Има два общи модела за внедряване.

Посредничество с шлюз OAuth

В този модел шлюзът инициира или координира OAuth потока, съхранява токени за опресняване или материал за токени за достъп в хранилище, изсича краткотрайни сесии на конектор и прикачва токени за достъп при изпращане на отдалечени MCP повиквания. Това дава на шлюза силен контрол върху съгласието, продължителността на живота на токена, отмяната и присъединяванията за проверка.

Компромисът е сложността. Шлюзът трябва да обработва екрани за съгласие, сигурност на потока на кода за оторизация, опресняване на токена, ротация на токена, криптирано съхранение, управление на пренасочване на URI, валидиране на издателя и специфична за клиент OAuth конфигурация на приложение. RFC 9700 има значение тук, защото този модел поставя шлюза близо до OAuth клиентски отговорности.

Управлявано от приложение OAuth

В този модел приложението получава токена OAuth и го предава през пътя на модела или шлюза, когато извиква отдалечен конектор MCP. Това може да бъде по-бързо за доставка, защото съществуващите продукти може вече да имат потоци за оторизация на конектори.

Компромисът е фрагментирано управление. Ако шлюзът вижда само непрозрачен токен, той може да не знае темата на токена, обхватите, издателя, актуалността, статуса на отмяна или произхода на съгласието. По-безопасна версия на този модел изисква приложението да предоставя подписани метаданни за конектор с всяко повикване, а шлюзът трябва да валидира издателя, аудиторията, изтичането, записването на конектора, обвързването на потребителя и одобрения обхват преди изпращане.

За конектори за потребителски данни, като имейл, календар, хранилище, CRM и плащания, предпочитайте OAuth токени за всеки потребител. Споделените дълготрайни носители трябва да бъдат ограничени до изрични работни потоци на акаунт за услуга, обхванати от наемател и прегледани като ресурси с по-висок риск.

Нормализиране на обхватите на инструмента преди изпращане

MCP сървърите могат да показват имена на инструменти и метаданни, а някои екосистеми предоставят подсказки, като анотации само за четене. Използвайте тези сигнали, но не третирайте предоставените от сървъра метаданни като напълно надеждни. Метаданните на инструмента могат да бъдат грешни, остарели, двусмислени или противоречиви. Ръководството на OWASP MCP подчертава най-малко привилегии, списък с разрешени, удостоверяване, оторизация и наблюдение; MCP Топ 10 произведения също обръщат внимание на рисковете от отравяне с инструменти.

Шлюзът трябва да поддържа свои собствени нормализирани класове на действие:

• Четене: търсене, списък, получаване, извличане, извличане, обобщаване на съществуващо съдържание.
• Писане: създаване, актуализиране, редактиране, етикетиране, преместване, коментар, график.
• Изпращане: имейл, съобщение в чата, уебкука, отговор на заявка, известие.
• Изтриване: премахване, изчистване, архивиране, отмяна.
• Експортиране: групово изтегляне, прехвърляне на файлове, извличане на набор от данни.
• Финансови: такса, възстановяване, фактура, изплащане, промяна на абонамента.
• Администратор: промяна на разрешението, покана за потребител, актуализация на роли, редактиране на правила.
• Неизвестно: всичко, което не е прегледано или не е уверено класифицирано.

След това наложете правила за нормализирани класове вместо необработени имена на инструменти. Например:

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;
}

Това поддържа политиката стабилна, когато конектор преименува gmail.search на mail.messages.query. Необработеният инструмент все още се нуждае от преглед, но системата за одобрение може да разсъждава в оперативни категории.

Изпълнете проверка на конектор преди изпращане

Преди шлюзът да разреши извикване на конектор, инициирано от модела, той трябва да изпълни компактно решение преди изпращане. Това е мястото, където се срещат анализите на използването на AI, политиката за сигурност, работният процес на одобрение и политиката за задържане.

Практическа последователност е:

1. Разрешаване на клиент и ключ: идентифицирайте ключа на шлюза, клиента, работното натоварване, средата и заявката за модел.
2. Разрешаване на краен потребител: изисква стабилен идентификатор на краен потребител за делегирани конектори. Отхвърляне на анонимни делегирани повиквания, освен ако не е изрично разрешено.
3. Разрешаване на конектор: съпоставяне на URL адреса на сървъра или ИД на хостван конектор към записан ресурс на конектор.
4. Потвърдете токена: проверка на издателя, аудитория, където е приложимо, изтичане, предмет, обвързване на клиента, състояние на отмяна и необходими обхвати.
5. Действие за класифициране: име на инструмента за карта и метаданни за четене, писане, изпращане, изтриване, експортиране, финансови, административни или неизвестни.
6. Проверете границата на задържане: определете дали работното натоварване позволява MCP обработка и регистриране на сървър на трета страна.
7. Прилагане на правила за одобрение: автоматично разрешаване, изискване на потребителско одобрение, изискване на администраторско одобрение, блокиране или поставяне под карантина.
8. Резервиране на бюджет, ако може да се таксува: ако изпълнението на конектора има преки или косвени такси, резервиране на бюджет преди изпращане.
9. Напишете решението: запазете решението преди извикване на конектора, а не само след успех.

Първото написване на решението е важно. Ако конекторът изтече, поточно предава частичен изход или задейства грешка надолу по веригата, регистрационният файл за проверка все още трябва да показва, че шлюзът е разрешил или отказал конкретно опитано действие.

Одобрението трябва да е съобразено с работния процес

Одобрението на повикване е лесно за разсъждение и често неизползваемо на практика. Агент за поддръжка на клиенти, който трябва да прочете билет, да търси в Диск, да изготви имейл и да актуализира CRM запис, не трябва да принуждава потребителя да преминава през модал за всяка безвредна операция за четене. В същото време изпращането на имейл, изтриването на файл, възстановяването на плащане или експортирането на папка не трябва да се делегира тихо, защото моделът е избрал инструмент.

Работна политика е наслоена:

• Автоматично разрешаване на прегледани инструменти само за четене за наематели с нисък риск и ново упълномощаване на потребители.
• Изискване на одобрение за изпращане, създаване, актуализиране, изтриване, експортиране, финансови и административни действия.
• Разрешаване на групирани одобрения за наименуван работен поток, обхват и времеви прозорец.
• Изискване на повторно одобрение, когато обхватите се разширят, дефинициите на инструментите се променят съществено или конекторът се премести в клас с по-висок риск.
• Блокиране на неизвестни инструменти, докато не бъдат прегледани.

Групираните одобрения трябва да са изрични. Потребителят може да одобри: „През следващите 30 минути позволете на този работен поток за поддръжка да търси в Диск и чернови на отговори, но изисква потвърждение преди изпращане.“ Това е по-полезно от превключвател за разрешаване/забрана на бинарен конектор.

Границите на задържане се нуждаят от собствено поле

Отдалечените MCP повиквания могат да преместват данни извън границите на задържане и обработка на доставчика на модела. Това не е автоматично грешно, но трябва да се вижда. Работно натоварване, на което е разрешено да използва моделна крайна точка при една настройка за задържане на данни, все още може да бъде забранено да изпраща същото съдържание до MCP сървър на трета страна с различни условия за задържане.

Добавете класификация за задържане както към работните натоварвания, така и към конекторите. Примерни класове:

• internal_only: не са разрешени извиквания на конектор на трети страни.
• approved_processors_only: конекторът трябва да е в списък с одобрени доставчици.
• third_party_standard_allowed: стандартната обработка на SaaS конектор е разрешена.
• no_argument_logging: разрешени са извиквания на конектори, но аргументите трябва да бъдат редактирани или хеширани.
• export_blocked: разрешено четене/търсене, отказано групово експортиране.

Тук шлюзът предпазва екипите от фина грешка: ако приемем, че контролите на данните на доставчика на модел се прилагат автоматично към всеки инструмент, използван от агента. Те не се прилагат непременно, след като данните бъдат изпратени до отдалечен MCP сървър или конектор за външна услуга.

Създаване на Ledger за одит на конектор

Легерът за одит на конектори трябва да обединява заявки за модел, упълномощаване на шлюз, изпращане на конектори и резултати надолу по веригата. Не разчитайте само на необработените трасировки на доставчика, тъй като всеки доставчик може да изложи събитията на инструмента по различен начин и регистрационните файлове на приложението може да пропуснат токен или контекст на одобрение.

Препоръчителните полета в счетоводната книга включват:

• model_request_id и ID на проследяване.
• tenant_id, gateway_key_id, работно натоварване, среда и ID на краен потребител.
• connector_id, хеш на URL адреса на сървъра, идентификатор на хостван конектор и клас на риск.
• tool_name, версия на инструмента или отпечатък на метаданни и нормализиран клас на действие.
• OAuth издател, обект на токен, хеш на набор от обхват, група за изтичане и произход на токена.
• Хеш на аргументи, редактирани аргументи, клас на чувствителност и клас на запазване.
• Решение за одобрение, одобряващ, обхват на одобрението и изтичане на одобрението.
• Статус на изпращане, статус на отговор, клас на грешка, закъснение и идентификационни номера на заявки надолу по веригата, когато има такива.

Пълното регистриране на аргументи може да помогне за реагиране при инцидент, но също така увеличава поверителността и риска от задържане. Предпочитайте по подразбиране структурирани полета, хеширане, селективна редакция и етикети за чувствителност. Разрешаване на пълно улавяне само при изричен инцидент или политика за отстраняване на грешки с изтичане.

Отмяната и поставянето под карантина са изисквания към продукта

Оттеглянето не може да бъде ръчно редактиране на база данни. Потребителите и администраторите се нуждаят от работни процеси, които незабавно се превръщат в състояние на правила.

Приложете поне тези действия:

• Прекъсване на връзката с потребителя: отмяна или маркиране на неактивни всички токени за оторизация на конектора на един потребител.
• Деактивиране на клиента: блокира един конектор за цял клиент, без да деактивира трафика на несвързан модел.
• Обработка на изтичане на токена: неуспешно затваряне или повторно упълномощаване, когато опресняването е неуспешно или актуалността на оторизацията надвишава правилото.
• Карантина на конектор: блокира конектор, като същевременно запазва конфигурацията и регистрационните файлове за разследване.
• Списък за отказ при спешни случаи: блокиране по URL хеш на сървъра, ID на конектора, издател или отпечатък на инструмент.
• Понижаване на обхват: повторно упълномощаване с по-малко обхвати, когато работният процес вече не се нуждае от широк достъп.

Важният детайл при внедряването е, че статусът на анулиране трябва да се проверява по време на изпращане. Нощното синхронизиране е полезно за съгласуване, но не е достатъчно за реакция при инцидент.

Проби за съответствие за отдалечени MCP конектори

Преди даден конектор да бъде достъпен за наематели в производствената среда, тествайте го като управлявана зависимост. Един кратък набор от сондажи улавя много грешки в интеграцията и правилата.

• Откриването на метаданни връща стабилна идентичност на сървъра и очаквани дефиниции на инструменти.
• Метаданните на защитения ресурс и поведението на оторизация съответстват на документираните предположения, където е приложимо.
• Изискванията за динамична регистрация на клиент са разбрани, поддържани или изрично деактивирани.
• Заявките без токени се провалят безопасно.
• Изтеклите токени се провалят предвидимо и не предизвикват неконтролирани повторни опити.
• Класификацията за четене/запис отговаря на наблюдаваното поведение, не само на описанията.
• Неправилно формираните метаданни на инструмента се отхвърлят или се маркират като неизвестни.
• Промените в списъка с инструменти задействат преглед, когато се променят имена, обхвати, описания или рискови класове.
• Грешките на конектора се регистрират без изтичане на чувствителни аргументи в общи полета за грешка.

Тези сонди не са заместител на прегледа на сигурността, но дават на шлюза повторяем начин за откриване на отклонение. Отдалечените MCP сървъри могат да се променят независимо от доставчика на модела и независимо от цикъла на пускане на вашето приложение.

Контролен списък за внедряване

• Създайте регистър на конектора с полета за клиент, сървър, оторизация, обхват, инструмент, риск, задържане и отмяна.
• Отделна идентичност на ключа на шлюза, делегирана самоличност на краен потребител и идентичност на конектора във всяко решение за политика.
• Съхранявайте токените на конектора в хранилище за идентификационни данни, но ги дръжте различни от идентификационните данни за изпълнение на доставчик на модел.
• Предпочитане за всеки потребител OAuth за конектори за потребителски данни; ограничете токените за споделени услуги до изрични работни потоци на акаунти за услуги.
• Нормализиране на действията на инструмента в четене, писане, изпращане, изтриване, експортиране, финансови, административни и неизвестни.
• Изпълнете проверки преди изпращане за записване на конектора, валидност на токена, съвпадение на обхвата, съвместимост при задържане, състояние на одобрение и резервиране на бюджет.
• Регистриране на решенията за конектори преди изпращане и определяне на крайния статус след отговор или грешка.
• Изграждане на работни потоци за прекъсване на връзката на потребителя, деактивиране на клиент, карантина на конектора и списък за отказ при спешни случаи.
• Проверка на метаданни на конектора, поведение на токена, дрейф на инструмента и неправилно формирани метаданни преди производствена употреба.

Приложимо заключение

MCP и сервизните конектори правят агентите полезни, защото позволяват на моделите да действат върху реални системи. Същата полезност превръща упълномощаването на конектора в проблем на контролната равнина, а не в подробност за бързо проектиране.

Шлюзът трябва да знае повече от модела, броя на токените и API ключа. Трябва да знае кой конектор е бил извикан, кой потребител го е упълномощил, кои обхвати са предоставени, кой клас на действие на инструмента е поискан, дали е необходимо одобрение, дали границата на задържане е съвместима и как достъпът може да бъде отменен. Започнете с регистър на конектори, проверка на правилата преди изпращане и обединена книга за одит. След това добавете OAuth посредничество, групирани одобрения, сонди за съответствие и спешна карантина с нарастването на използването на конектора.

Целта не е да се блокира отдалеченото MCP приемане. Целта е достъпът на конектора да бъде приписван, отменим, прегледан и съвместим със същите очаквания за управление, които екипите вече прилагат за достъп до модела и OpenAI-съвместим API шлюз.

Свързано четене

• по-широко управление на агентски инструмент модели