В последних двух частях этой серии я рассмотрел как Протокол Контекста Модели соотносится с API для грузоперевозок, а затем снесли грузовые серверы MCP, поставленные в 2026 году. Оба закончились одним и тем же открытым вопросом, поэтому эта часть отвечает на него напрямую: как только агент сможет бронировать реальный груз, как вы остановите его от бронирования неправильного груза для неправильного человека? Безопасность — это то, где сервер MCP для грузоперевозок перестает выглядеть как игрушка разработчика и начинает выглядеть как система, перемещающая деньги и грузовики.
Я запускаю это с позиции маркетплейса, который предоставляет API, поэтому мои соображения практические, а не академические. Описанные ниже угрозы — это те, которые мы фактически моделируем, когда решаем, какой инструмент может вызывать агент без участия человека.
Почему грузовой сервер повышает ставки
Общий сервер MCP, который считывает ваш календарь, раскрывает информацию при сбоях. Фрахтовый сервер, который бронирует груз, делает что-то более дорогостоящее. Неправильный вызов может отправить грузовик на неправильный двор, изменить получателя живой отправки, отменить бронирование, на которое рассчитывает клиент, или извлечь коносамент, который никогда не должен был покинуть учетную запись. Это не ошибки, связанные с раскрытием данных. Это деньги и физические товары, перемещаемые по инструкции, которую никто не вводил.
Эта разница меняет всю проблему. В случае с чат-ботом худший сценарий — это неловкий ответ. В случае с грузоперевозками худшим сценарием будет счет за фрахт и груз, который окажется не там, где нужно. Поэтому вопрос никогда не стоит «безопасен ли этот сервер» в абстракции. Он ставится так: «Какие конкретные действия может предпринять агент, и какова стоимость каждой из них в случае неудачи».
Два типа отказов, из-за которых стоит беспокоиться
Большинство рисков MCP к 2026 году сводится к двум моделям, и грузоперевозки усугубляют обе.
Внедрение команд — это старая веб-проблема в новом обличье. Агент читает текст из источника, который он не полностью контролирует, — накладной, PDF-файла, тела электронного письма — и этот текст содержит инструкцию, которой модель следует. В сфере грузоперевозок "отравленный" текст поступает через легитимные каналы весь день: комментарий к бронированию, описание для таможни, обновление статуса от перевозчика. Если ваш инструмент бронирования доверяет всему, что ему передает модель, предложение, скрытое в накладной на доставку, может привести к реальной отмене.
Отравление инструментов — это более тонкая атака, специфичная для MCP. Протокол позволяет серверу описывать свои собственные инструменты, а агент считывает эти описания, чтобы решить, что вызывать. Вредоносный или скомпрометированный сервер может написать описание, которое незаметно предписывает модели кражу API-ключа или перенаправление груза, при этом пользователь никогда не увидит этот текст. Anthropic и независимые исследователи потратили начало 2026 года на документирование вариантов этой атаки, и урок для грузоперевозок очевиден: слой описания является исполняемым, поэтому относитесь к описанию стороннего инструмента с тем же подозрением, с котором вы бы относились к стороннему коду.
Чтение или запись: грань, определяющая ваши права доступа
Самым полезным решением в области безопасности, которое я принял, было перестать думать о «сервере MCP» как об одном доверенном периметре и разделить его в зависимости от того, что каждый инструмент делает с миром.
Что может остаться открытым
Запрос ставки по линии, перечисление мощностей, расчет ориентировочного времени транзита, поиск портового кода — ничто из этого ничего не меняет. Главное, чтобы агент мог связаться с ними с минимальным количеством препятствий, и именно в этом заключается ежедневная ценность. Читатель, который хочет сравнить три маршрута, не должен для этого выпускать токен. На серверах, которые оказались в результате разборки, серьезные из них как раз по этой причине сохраняли инструменты для получения котировок и справок с низким уровнем трения.
Что должно быть закрыто
Бронирование, отмена, изменение грузополучателя, редактирование адреса, получение документа — все, что связано с накладной. Каждое такое действие приводит к изменению реального мира, и за каждым из них должен стоять аутентифицированный, авторизованный, проверяемый вызов. Правило, которому мы следуем, легко сформулировать и труднее соблюсти: инструмент для чтения может быть открытым, а инструмент для записи — никогда.
OAuth 2.1 и PKCE, а не долгоживущий ключ в конфигурационном файле
Спецификация авторизации MCP остановилась на OAuth 2.1 для удаленных серверов, и этот выбор имеет реальный вес для грузоперевозок. Статический API-ключ, вставленный в конфигурационный файл, подходит для одиночного разработчика, запускающего сервер через stdio на своей собственной машине. Эта модель становится неправильной в тот момент, когда сервер доступен через HTTP, а агент действует от имени именованного пользователя в рамках общего аккаунта.
Три свойства выполняют основную работу. Ограниченные токены означают, что токен, выданный для цитирования, не может быть использован для бронирования. Краткоживущие токены означают, что скомпрометированный учетный данные истекают сами по себе, а не живут вечно в журнале. Отзываемые токены означают, что когда что-то выглядит неправильно, вы отключаете доступ за секунды, а не меняете общий ключ, от которого зависят все. OAuth 2.1 также требует PKCE в потоке кода авторизации, что закрывает уязвимость перехвата, которую оставили открытой старые развертывания OAuth. Ничего из этого не является экзотикой. Это то же самое усиление безопасности, которое прошли все платежные API, примененное к моменту, когда агент говорит «забронируй».
Вот форма границы, которую мы применяем, представленная в виде таблицы, которую я хотел бы видеть у каждого сервера грузоперевозок.
| Действие агента | **Читает или пишет** | Мы требуем аутентификации | Если что-то пойдет не так |
| Получить расценку | Читать | Открытый или простой ключ | Пустая трата времени, вреда нет |
| Проверить мощность, транзит, отслеживание | Читать | Открытый или простой ключ | В худшем случае — несвежий ответ |
| Забронировать отправку | Напиши | Токен OAuth с ограниченным доступом, шаг подтверждения | Реальная стоимость, настоящий грузовик |
| Отменить или перебронировать | Напиши | Scoped token, idempotency key | Утерянный слот, штраф |
| Изменить получателя или адрес | Напиши | Scoped token, human confirm | Неправильная доставка, мошенничество |
| Выписать коносамент или счет-фактуру | Чувствительный | Облачный токен, проверка для каждого документа | Утечка данных и документов |
Шаблон в той таблице — это само решение о продукте. Операции чтения находятся слева и остаются дешевыми. Операции записи находятся справа и отрабатывают свое "трение".
Проблема раскрытой инстанции
Поразительно, но большая часть рисков, связанных с MCP, не является ничем особенным. Это сервер, который должен был работать локально, но был выставлен в открытый интернет без аутентификации, потому что так его было проще поставлять. Протокол поддерживает два транспорта. Сервер stdio запускается как локальный процесс, который запускает клиент, что удерживает его на вашей машине и вне сети. Хостинговый HTTP-сервер доступен любому, кто сможет найти его URL.
Для сервера, предназначенного только для чтения, HTTP-доступ в основном безвреден. Для сервера с инструментами бронирования — это главное. Если ваши инструменты записи доступны через публичный HTTP, аутентификация — это не функция, которую вы добавляете позже, это то, что стоит между посторонним и вашей очередью диспетчеризации. Наше правило: инструменты бронирования и документы никогда не обслуживаются через неаутентифицированный HTTP-эндпоинт, точка. Если есть сомнения, сервер с возможностью записи должен по умолчанию использовать stdio и локальный запуск, и только переходить к размещенному HTTP-серверу, когда поток OAuth, описанный выше, настроен.
Защита слоя описаний от отравления инструментами
Поскольку описания инструментов влияют на модель, они заслуживают такого же контроля, как и развертываемый вами код. Три привычки охватывают большую часть рисков.
- Закрепите и проверьте серверы, к которым вы подключаетесь. Агент, подключенный к определенному набору известных серверов, представляет собой меньшую цель, чем тот, который устанавливает все, что предлагает реестр. Относитесь к новому серверу как к новой зависимости, потому что это именно то, чем он является.
- Привлекайте человека к каждому написанию. Шаг подтверждения перед бронированием, отменой или изменением грузополучателя превращает тихо отправленную инструкцию в явный запрос, от которого пользователь может отказаться. Это самый дешевый способ контроля с самой высокой отдачей.
- Проверяйте на уровне API, а не в запросе. Сервер должен повторно проверять каждый полученный параметр на соответствие реальным разрешениям учетной записи и текущему состоянию бронирования, вместо того чтобы полагаться на то, что модель составила разумный вызов. Модель предлагает, API решает.
Что должен обеспечивать сервер маркетплейса, чтобы один перевозчик мог пропустить
Однопользовательский сервер работает только в своей собственной сети, поэтому его радиус поражения составляет один оператор. Сервер маркетплейса котирует и бронирует услуги различных перевозчиков от имени многих пользователей, что меняет задачу безопасности двумя способами.
Во-первых, область действия должна быть индивидуальной для пользователя и перевозчика, а не для сервера. Токен, позволяющий агенту бронировать услугу у одного перевозчика, не должен незаметно передаваться другому, а агент одного клиента никогда не должен видеть документы другого клиента. Во-вторых, аудиторский след имеет большее значение, поскольку, когда агент осуществляет бронирование на торговой площадке, необходимо ответить на вопросы "какой пользователь, какой токен, какой перевозчик, в какое время" для каждой записи. Мы относимся к этому журналу как к части продукта, а не как к запоздалой мысли, поскольку именно он позволяет нам отзывать разрешения точечно, а не отключать всех.
Практический чек-лист перед публикацией бронирования
- Разделите инструменты по чтению и записи и запишите это разделение там, где его смогут увидеть как агент, так и ваша команда.
- Удерживайте инструменты для цитирования и ссылок простыми, чтобы ежедневная ценность сохранялась.
- Обеспечьте каждую запись кратковременным, отзываемым токеном OAuth 2.1 с PKCE.
- Требуется шаг подтверждения при бронировании, отмене, а также при изменении грузополучателя и адреса.
- Повторно проверьте все параметры API на соответствие реальным разрешениям и реальному состоянию отгрузки.
- Никогда не используйте инструменты записи через неаутентифицированный HTTP, а серверы с возможностью записи по умолчанию используйте локальный stdio.
- Закрепите серверы, к которым подключается ваш агент, и просматривайте новые, как новый код.
- Регистрируйте каждое действие записи с указанием пользователя, токена, носителя и времени, а также репетируйте отзыв до того, как он понадобится.
Ничто из этого не является уникальным для искусственного интеллекта. Это те же механизмы управления, которые уже используются в грузоперевозках и платежах, направленные на новое место, откуда может исходить инструкция. Агент — это новый вызывающий абонент, а не новый набор правил.
Часто задаваемые вопросы
Безопасно ли вообще позволять агенту ИИ бронировать грузы?
Да, когда бронирование происходит после аутентифицированного и авторизованного вызова с шагом подтверждения, и когда сервер повторно проверяет каждый параметр, а не полагается на модель. Небезопасная версия — это открытый инструмент записи без участия человека. Относитесь к бронированию как к любому другому действию, связанному с перемещением денег, и агент станет еще одним аутентифицированным вызывающим абонентом.
Зачем использовать OAuth 2.1 вместо простого API-ключа?
Статический ключ обычно долговечен, широко применим и его трудно отозвать, не нарушив работу всех, кто им пользуется. OAuth 2.1 предоставляет вам токены с ограниченной областью действия, кратковременные и отменяемые, а также требует PKCE для потока авторизации. Для локального сервера stdio ключ приемлем, но всё, что доступно через HTTP и может записывать данные, должно использовать модель OAuth.
Что такое отравление инструмента в MCP?
Отравление инструмента — это когда описание инструмента сервера, которое агент читает, чтобы решить, что вызвать, содержит скрытые инструкции, направляющие модель к вредоносным действиям, таким как утечка ключа или перенаправление поставки. Поскольку описание влияет на поведение, вы защищаете его так же, как код: фиксируйте надежные серверы, осуществляйте проверку человеком при внесении изменений и валидируйте на уровне API.
Должен ли сервер MCP для грузовых перевозок работать как stdio или как размещенный HTTP?
Сервер с правами только на чтение подходит для размещенного HTTP. Сервер с функциями бронирования или работы с документами должен по умолчанию использовать локальный ввод/вывод (stdio) и переходить на размещенный HTTP только после настройки OAuth с ограниченной областью действия, поскольку доступная конечная точка записи без аутентификации может быть найдена кем угодно, кто ее обнаружит.
Это замыкает круг, открытый этой серией. Если вы не читали предыдущие части, основы протокола объясняет, как API для грузоперевозок становится набором инструментов, а демонтаж показывает, где отправленные серверы провели эти линии на практике.