Tool Hijacking

Суть

Корневая причина — агенту дали слишком много прав и не ограничили последствия. Сам по себе вызов инструмента легитимен (read_file, http_request), но управляемый инъекцией он становится каналом атаки. Для внешнего мира это выглядит как «обычный HTTP-запрос от агента» — без алертов.

Зачем это нужно

Это самая «дорогая» категория: в отличие от jailbreak (вытащить текст), здесь происходит действие с необратимыми последствиями (деньги, письма, БД). Защита — не только фильтры на вход, но и ограничение самих прав (Agent Governance) и изоляция исполнения (Agent Sandboxing).

Как работает (подтипы)

Token / data exfiltration — агент получает команду прочитать .env и отправить содержимое на внешний URL. Инструменты read_file + http_request выполняют её без вопросов → утекают ключи от всей инфраструктуры. Никаких алертов — обычный HTTP-запрос.
Malicious skills / plugins — атакующий публикует инструмент с легитимным названием (pdf-reader, web-search-pro). Варианты:
- rug pull — вредонос добавляют после обновления плагина;
- typosquatting — openai-mcp-tools vs openai_mcp_tools;
- скомпрометированная зависимость внутри легитимного плагина. Итог — выполнение произвольного кода внутри агента, backdoor; агент вызывает плагин автоматически.
Runaway API-billing — агент застрял в цикле (не может выполнить задачу → повторяет), либо команда «повтори запрос 1000 раз» → счёт за API (см. также Agent CostControl).

Защита

Allowlist инструментов и доменов — детерминированная проверка ДО вызова: что агент может запускать, на какие хосты ходить (проверять именно хост, а не подстроку: ловушка wildberries.ru.attacker.net):

from urllib.parse import urlparse
ALLOWED_DOMAINS = {"wildberries.ru"}                 # домен + поддомены (www., m. …)

def is_allowed_url(url) -> tuple[bool, str]:
    try:
        parsed = urlparse(str(url))
    except Exception:
        return False, "<unparsable>"
    if parsed.scheme not in ("http", "https"):       # режем не-http (ftp://…)
        return False, f"scheme:{parsed.scheme}"
    host = (parsed.hostname or "").lower().rstrip(".")
    for dom in ALLOWED_DOMAINS:                       # сравниваем ХОСТ, не подстроку
        if host == dom or host.endswith("." + dom):   # ловушка wildberries.ru.attacker.net -> block
            return True, host
    return False, host or "<empty-host>"

Узел-привратник scrape_one_safe() / n_domain_guard() вызывает is_allowed_url() ДО Firecrawl — экономит биллинг и режет чужие домены.

HITL на опасных действиях (Human in the Loop) — деньги/auth/bash требуют апрува.
Ограничение последствий — Agent Sandboxing: даже захваченный агент не вырывается за microVM.
Принцип наименьших прав — каждому агенту/инструменту только необходимый минимум доступа (Agent Governance, ролевая модель из ФСТЭК №21).
Для MCP-инструментов — проверять источник/издателя, фиксировать версии зависимостей.

Внешнее подтверждение: OWASP поднял Excessive Agency на третье место

Исходный материал описывает перехват инструментов как один из рисков в ряду прочих. Независимая оценка ставит его выше: в OWASP Top 10 for LLM Applications 2026 избыточные полномочия (Excessive Agency) поднялись с шестого места в редакции 2025 года на третье, и подъём поддержан обеими половинами методики — и голосованием экспертов, и статистикой инцидентов.

Важно, откуда взялась статистика: редакция 2026 года впервые учитывает данные 6 639 реальных инцидентов (25% веса против 75% у экспертного голосования). То есть перехват инструментов поднялся не потому, что о нём стали больше говорить, а потому, что он стал чаще случаться в проде — по мере того как агенты перешли от генерации текста к выполнению многошаговых действий.

Практическое следствие для приоритизации: если защитный бюджет ограничен, минимизация полномочий агента даёт больше, чем усиление фильтрации на входе — притом что инъекции (Prompt Injection) остаются на первом месте рейтинга. Эти две меры не конкурируют: инъекция — вход атаки, избыточные права — то, что превращает её в ущерб (см. Attack Kill Chain).

Верификация издателя MCP-инструмента

Сверка 2026-08, и начать надо с неприятного: в экосистеме MCP нет стандарта безопасности пакетов — ни обязательной подписи, ни базовой проверки при публикации. Официальный реестр решает задачу обнаружения, а не сертификации: он не утверждает, что код безопасен, описания инструментов честны, запрошенные права соразмерны и поведение не изменится после подключения. Поэтому «проверить издателя» сводится не к одному действию, а к процедуре на своей стороне.

Что делать практически, по убыванию отдачи:

Пинить конкретный артефакт, а не имя. Подключение по имени или тегу означает, что содержимое может поменяться после вашей проверки — классический rug-pull. Фиксируется версия и хеш.
Читать описания инструментов как недоверенный вход. Поле описания контролируется автором сервера и попадает прямо в контекст модели — это и есть tool poisoning, известный класс с 2025 года. Описание проверяется тем же сканом, что и любой внешний контент (Injection Detection).
Проверять происхождение: личность издателя, репозиторий, метаданные подписи, если они вообще есть. Отсутствие подписи — не блокер сам по себе (её почти ни у кого нет), но повод отнести сервер к недоверенным.
Перечислять инструменты в рантайме и требовать повторного одобрения при изменении состава, описаний или зависимостей. Именно это ловит подмену после подключения.
Считать, что проверка не удалась. Раз гарантий нет, единственный надёжный слой — ограничение прав и детерминированная проверка аргументов перед действием (Guardrails, Deterministic Veto): чужой инструмент не должен получать доступ шире, чем нужно одной задаче.

Масштаб проблемы измерен: в аудите 3 984 опубликованных навыков доля дефектов составила 36%, у 76 нашлась активная вредоносная нагрузка (Attack Kill Chain).

Связано с

Supply Chain AI — инструменты и MCP-серверы как звено цепочки поставки
Prompt Injection — механизм, через который запускается hijacking
Agent Sandboxing — изоляция, ограничивающая ущерб
Agent Governance — уровни автономии и пропорциональные права
Agent CostControl — runaway-billing как форма Token DoS
MCP — инструментальный слой, чьи плагины могут быть скомпрометированы
Deterministic Veto — проверка связки «кто-что-над чем» по графу инфраструктуры