يمكن لـ Anthropic والنماذج اللغوية الأخرى استدعاء أدوات مخفية بدون إذن

Главный риск агентных LLM сегодня не в том, что они иногда ошибаются с параметрами функции, а в том, что при неудачной архитектуре они могут вызвать инструмент, которого им формально никто не выдавал. Если такая функция существует в окружении, модель способна догадаться о её имени, придумать аргументы и получить реальный побочный эффект: прочитать секрет, записать сообщение, обратиться к чужому API. На бумаге права доступа выглядят ограниченными, но на практике граница между разрешённым и запрещённым оказывается вероятностной.

Для систем, где модель работает с данными, почтой, документами или корпоративными интеграциями, это уже не курьёз, а риск безопасности. Проблема проявляется в связке агентной модели и клиентского окружения, где список разрешённых инструментов и фактическое пространство имён расходятся. В демонстрации модели дали только read_url, но в среде существовала функция read_secret.

После подсказки вида from dialoghelper import * модель решила, что доступ к read_secret у неё есть, и попыталась вызвать этот инструмент. Если библиотека или API проверяют только формат вызова, а не жёстко сверяют имя функции с выданной схемой, запрос проходит дальше. Автор показал похожее поведение не только у Anthropic, но и в отдельных сценариях у Gemini, Grok и через мультипровайдерные обёртки.

Иными словами, уязвимость рождается не в одном бренде, а на стыке модели, SDK и агентной обвязки. Опасность резко возрастает, когда такая система попадает в так называемую смертельную триаду: у модели есть доступ к внешним инструментам, к недоверенному контенту и к приватным данным. Тогда prompt injection перестаёт быть просто досадной особенностью и превращается в канал утечки.

Достаточно, чтобы злоумышленник встроил инструкцию в письмо, веб-страницу или документ, а модель, уверенная в наличии скрытого инструмента, сама дотянулась до секрета и отправила его наружу. Особенно неприятно то, что архитектурное разделение, на которое надеются разработчики, может дать ложное чувство безопасности: чувствительный инструмент вроде бы не включён в набор, но физически лежит рядом в окружении и становится достижимым через несанкционированный вызов. Выявить такой сбой сложно.

Во многих случаях модель ведёт себя правильно и отказывается от запретного вызова, а затем внезапно ломается из-за мелочи в контексте: формулировки подсказки, истории сообщений или даже названия модуля. В статье приводится показательный пример, где одно и то же действие то блокируется, то проходит после безобидного упоминания dialoghelper. Структурированное декодирование частично снижает риск, потому что заставляет модель укладываться в схему, однако и тут есть компромиссы: рост задержек, жёсткие лимиты на число strict-инструментов и падение производительности на больших наборах функций.

Поэтому полагаться только на умное поведение модели нельзя. Проверка имени инструмента должна происходить на стороне провайдера и в клиентском коде до фактического выполнения. Практический вывод простой: если ты строишь агента поверх MCP, Jupyter, внутренних SDK или любой другой динамической среды, недостаточно скрыть лишние функции из описания и надеяться на дисциплину модели.

Нужно жёстко валидировать каждый tool call, отделять чувствительные операции от недоверенного контента и держать пространство исполнения уже, чем видимость для LLM. Иначе один угаданный read_secret или add_msg превращает аккуратную агентную архитектуру в систему, где права доступа существуют только до первой удачной галлюцинации. Хорошая новость в том, что исправление не выглядит сложным: достаточно отбрасывать любой вызов, чьё имя отсутствует в разрешённой схеме, ещё до передачи в рантайм.

Несколько строк защитного кода в библиотеке или шлюзе способны закрыть класс проблем, который иначе маскируется под редкую галлюцинацию, а по факту ломает модель доверия всей системы.