В останніх двох частинах цієї серії я розповів про як Протокол Контексту Моделі відображається на API для вантажних перевезень, а потім про знесено вантажні сервери MCP, які постачалися у 2026 році. Обидві закінчилися однаковим відкритим питанням, тому ця частина відповідає на нього безпосередньо: як тільки агент зможе бронювати реальні вантажі, як зупинити його від бронювання не того для не тієї людини? Безпека — це те, де сервер MCP вантажів перестає бути іграшкою для розробника і стає системою, яка переміщує гроші та вантажівки.
Я роблю це з центру ринку, який надає API, тому мої міркування практичні, а не академічні. Загрози, перелічені нижче, — це ті, які ми реально моделюємо, коли вирішуємо, який інструмент агент може викликати без участі людини.
Чому вантажний сервер підвищує ставки
Загальний сервер MCP, який читає ваш календар, витокує інформацію під час збоїв. Вантажний сервер, який бронює вантаж, робить щось дорожче. Помилковий дзвінок може відправити вантажівку на неправильний склад, змінити одержувача активної відправки, скасувати бронювання, на яке розраховує клієнт, або вилучити коносамент, який ніколи не повинен був покинути обліковий запис. Це не помилки викриття даних. Це гроші та фізичні товари, що рухаються за інструкцією, яку ніхто не вводив.
Ця відмінність переглядає всю проблему. Якщо шкідливий чат-асистент видасть незручну відповідь, це може призвести до збентеження. У випадку з вантажами, найгірший сценарій — це отримання рахунку за перевезення та відправлення вантажу не туди, куди слід. Тому питання ніколи не полягає в тому, «чи захищений цей сервер» в абстрактному сенсі. Питання полягає в тому, «які конкретні дії може виконати агент, і скільки коштуватиме кожна з них, якщо щось піде не так».
Два сценарії відмови, через які варто переживати
Більшість ризиків MCP у 2026 році зводяться до двох моделей, і фрахт погіршує обидві.
**Впровадження підказок (prompt injection)** — це стара веб-проблема в новому одязі. Агент читає текст з джерела, яке він не повністю контролює (накладна, PDF, тіло електронного листа), а цей текст містить інструкцію, якій модель підкоряється. У сфері вантажоперевезень "отруєний" текст надходить легітимними каналами цілий день: коментар до бронювання, митний опис, оновлення статусу від перевізника. Якщо ваш інструмент бронювання довіряє всьому, що передає йому модель, речення, приховане в накладній, може призвести до реального скасування.
Отруєння інструментів є тоншим і специфічним для MCP. Протокол дозволяє серверу описувати власні інструменти, а агент читає ці описи, щоб вирішити, що викликати. Зловмисний або скомпрометований сервер може написати опис, який тихо наказує моделі викрасти API-ключ або перенаправити відправлення, і користувач ніколи не бачить цього тексту. Anthropic та незалежні дослідники провели на початку 2026 року документування варіантів цього, і урок для вантажних перевезень є недвозначним: шар опису виконуваний, тому ставтеся до опису інструментів третьої сторони з такою ж підозрою, як ви ставилися б до коду третьої сторони.
Читання проти запису: межа, яка має визначати вашу авторизацію
Найбільш корисним рішенням щодо безпеки, яке я ухвалив, було припинити думати про "сервер MCP" як про один кордон довіри та розділити його відповідно до того, що робить кожен інструмент зі світом.
Що може залишатися відкритим
Ціноутворення тарифа, зазначення місткості, розрахунок оцінки часу транзиту, пошук коду порту. Жодне з них нічого не змінює. Головна мета полягає в тому, щоб дозволити агенту зв'язатися з ними з мінімальними труднощами або взагалі без них, і саме тут полягає щоденна цінність. Читач, який хоче порівняти три маршрути, не повинен для цього створювати токен. Сервери, які розбиралися, тримали інструменти цитування та довідкові інструменти низькофрикційними саме з цієї причини.
Що повинно бути зачинене
Бронювання, скасування, зміна одержувача, редагування адреси, отримання документа, будь-що, що стосується рахунку-фактури. Кожне з цих дій записує інформацію у реальний світ, і кожне вимагає автентифікованого, дозволеного, такого, що можна перевірити, виклику. Правило, якого ми дотримуємося, легко сформулювати і важче забезпечити: інструмент для читання може бути відкритим, інструмент для запису — ніколи.
OAuth 2.1 і PKCE, а не довготривалий ключ у файлі конфігурації
Специфікація авторизації MCP зупинилася на OAuth 2.1 для віддалених серверів, і цей вибір має реальну вагу для вантажоперевезень. Статичний API-ключ, вставлений у конфігураційний файл, підходить для розробника-одинака, який запускає сервер через stdio на власній машині. Це неправильна модель в той момент, коли сервер доступний через HTTP, а агент діє від імені іменованого користувача в межах спільного облікового запису.
Три властивості виконують основну роботу. Обмежені токени означають, що токен, створений для цитування, не може бути використаний для бронювання. Короткоживучі токени означають, що витік облікових даних закінчується сам по собі, а не залишається назавжди в журналі. Відкличні токени означають, що коли щось виглядає неправильно, ви припиняєте доступ за лічені секунди, а не змінюєте спільний ключ, від якого залежать усі. OAuth 2.1 також вимагає PKCE для потоку авторизаційного коду, що усуває розрив перехоплення, який залишали відкритим старі розгортання OAuth. Нічого з цього не є екзотичним. Це те саме зміцнення, яке пройшов будь-який платіжний API, застосоване до моменту, коли агент каже "забронювати".
Ось форма границі, яку ми дотримуємося, записана у вигляді таблиці, яку я хотів би, щоб кожен сервер вантажних перевезень публікував.
| Дія агента | **Читає або пише** | Авторизація, яку ми вимагаємо | Якщо піде не так |
| Отримати пропозицію | Читати | Відкритий або основний ключ | Марний дзвінок, без шкоди |
| Перевірити потужність, транзит, відстеження | Читати | Відкритий або основний ключ | Застаріла відповідь у найгіршому випадку |
| Забронювати відправлення | Напишіть | Scoped OAuth токен, крок підтвердження | Реальна вартість, реальна вантажівка |
| Скасувати або перебронювати | Напишіть | Токен області дії, ключ ідемпотентності | Втрачений слот, штраф |
| Змінити одержувача або адресу | Напишіть | 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.
Чи має сервер автовідповідача вантажних перевезень працювати як stdio чи як розміщений HTTP?
Сервер, призначений лише для читання, підійде в режимах розміщення HTTP. Сервер з інструментами бронювання чи роботи з документами за замовчуванням повинен використовувати локальний stdio і переходити до розміщення HTTP лише після налаштування OAuth, оскільки доступний без автентифікації кінцевий пункт запису доступний будь-кому, хто знайде URL.
Це замикає цикл, який відкрила ця серія. Якщо ви не читали попередні частини, довідник з протоколів пояснює, як API вантажних перевезень стає набором інструментів, а розбірка показує, де впроваджені сервери проводили ці лінії на практиці.