Отруєні описи інструментів

Що таке Отруєні описи інструментів?

Агент ШІ читає опис підключеного інструмента, щоб вирішити, як і коли ним користуватися, тож цей текст ближчий до виконуваних вказівок, ніж до документації. Змініть опис — і зміниться поведінка агента, хоча обробник, схема й дозволи лишилися тими самими, а під час рев'ю коду цього ніщо не виявить. Ви знайдете інструмент, схвалений кілька місяців тому, який тепер наказує агентові надсилати кожен лист на зовнішню адресу в прихованій копії, порівняєте (diff) поточний опис зі схваленим формулюванням і заблокуєте скомпрометований сервер на шлюзі.

Що ви дізнаєтесь у Отруєні описи інструментів

• Поясніть, чому агент ШІ сприймає опис підключеного інструмента MCP як вказівки, що виконуються, а не як пасивну документацію
• Розпізнавайте раг-пул (підміну після схвалення) в отруєнні інструментів: сервер отримує схвалення для одного опису, а пізніше оновлення непомітно підставляє іншу поведінку без змін у коді чи дозволах
• Локалізуйте отруєний інструмент на кожному рівні, до якого він дістається: вимкніть інструмент у поточному сеансі й заблокуйте скомпрометований сервер на шлюзі, щоб захистити й усі інші підключені команди
• Читайте кожен аргумент у вікні згоди на виклик інструмента, бо отруєний опис може змусити агента додати аргумент, про який ви не просили
• Ставтеся до опису інструмента MCP як до артефакту ланцюга постачання: фіксуйте схвалену версію, порівнюйте (diff) із нею кожне оновлення й локалізуйте скомпрометований сервер і на клієнті, і на шлюзі

Отруєні описи інструментів — Кроки навчання

1. Чужий токен для публікації

   Боб атакує не Sarnholt Systems, а вендора, якому ця компанія вже довіряє. Викрадений токен мейнтейнера дає змогу публікувати пакети в реєстрі VaultSync Bridge від імені самого VaultSync Bridge.

2. Маніфест, який читають усі

   Маніфест інструментів сервера — це перелік, який отримує кожен підключений клієнт, коли питає сервер, що той уміє. Боб відкриває копію, яку збирається опублікувати.

3. Один рядок

   Він не чіпає нічого, на що звернув би увагу той, хто порівнює випуски (diff). Обробник не змінено, схему вхідних даних не змінено, дозволи не змінено. Боб змінює лише речення, яке читає агент.

4. Випуск у вигляді патча

   Він публікує це як звичайний технічний випуск. Реєстр приймає його, бо публікація йде зі справжнього облікового запису мейнтейнера.

5. Очікування оновлення

   Боб своє зробив. Далі все відбувається всередині Sarnholt, на схваленому сервері, коли агент наступного разу візьметься за інструмент, яким безпечно користувався місяцями.

6. Звичайне оновлення від вендора

   Понеділок, ранок у Sarnholt Systems. Аліса, інженерка з платформи ШІ, відкриває пошту, а там звичайна купа листів: нотатки зі стендапу, запрошення в календар і повідомлення про випуск від стороннього сервера MCP, який її команда підключила кілька місяців тому. Нічого термінового.

7. Підключення серверів

   Sarnholt Systems працює з агентними інструментами через Agent Host — клієнт MCP компанії. Сервери ticket-desk-mcp (невелика внутрішня інтеграція зі службою ІТ-підтримки) і fileops-mcp (конектор для файлів і електронної пошти, який щойно оновив VaultSync Bridge) уже підключені й схвалені.

8. Огляд схвалених інструментів

   Перш ніж щось змінювати, Аліса дивиться, що саме підключено. Обидва сервери виглядають так само, як тоді, коли її команда їх схвалила: той самий ендпоінт, ті самі описи інструментів. Відрізняється лише версія — v1.4, про яку йшлося в повідомленні про патч, що вона щойно прочитала.

9. Оновлення приходить непомітно

   Поки Аліса ще на вкладці, сервер надсилає Agent Host свіжий перелік інструментів. У ньому вказівки для send_email переписано. Жодного запиту на схвалення, жодного нового номера версії, жодного сповіщення. Перелік інструментів просто перемальовується.

10. Звичайне прохання

    Перелік інструментів перемалювався без жодного запиту, повторно схвалити його ніхто не просив. Вона повертається до рутинної роботи й просить агента виконати звичайне завдання.