Безопасность агентов DeepSeek V4 Pro зависит не только от модели

Организациям, которые внедряют агентов на базе DeepSeek V4 Pro, важно оценивать не модель в отрыве от контекста, а полную конфигурацию «модель — оболочка агента — задача — среда выполнения».

Доступ к одной и той же модели через веб-интерфейс, мобильное приложение, API, OpenAI Responses API или интеграцию с Codex может подтверждать совместимость интерфейсов. Но это не означает, что в разных средах одинаково работают промпты, инструменты, разрешения, память, повторы запросов и побочные эффекты.

Практическое правило простое: одобрять нужно конкретную зафиксированную конфигурацию и только после того, как она прошла собственную проверку безопасности.

Почему оболочка меняет поведение агента

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

Риск-профиль могут существенно менять:

• системные промпты и адаптеры;
• описания и реализации инструментов;
• области разрешений и этапы согласования;
• корень файловой системы и сетевой доступ;
• источники учётных данных и используемая идентичность;
• запуск подпроцессов и сгенерированного кода;
• правила повторов, тайм-аутов и параллельного выполнения;
• состояние сессии, краткие пересказы контекста, кэши и постоянная память.

Поэтому один и тот же сервер DeepSeek V4 Pro может иметь разный уровень риска при работе через разные оболочки агента или среды исполнения. Совместимость со схемой API — это свойство интеграции, а не сертификат безопасности.

Что показало исследование AgentS4D

В исследовании AgentS4D оценивались полные конфигурации выполнения, а не отдельные ответы модели. В бенчмарке использовались 328 сценариев с заранее внесёнными рисками. Их прогнали через четыре оболочки агентов и пять модельных бэкендов — всего 6 560 запусков в изолированной песочнице.

Небезопасными были признаны 4 461 запуска, или 68,0%. Ещё 4 344 запуска, или 66,22%, одновременно классифицировались как небезопасные и завершившиеся успешно. 13

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

Эти цифры нельзя выдавать за частоту инцидентов DeepSeek V4 Pro в промышленной эксплуатации. Исследование проводилось в контролируемой песочнице на специально подготовленных сценариях с внедрёнными рисками и объединяло результаты нескольких сочетаний модели и оболочки. В реальной среде будут другими набор задач, защитные меры, доля атакующего контента, доступные активы и критерии вреда. Результаты показывают, что безопасность среды выполнения нужно измерять напрямую, но не предсказывают последствия для каждого конкретного внедрения. 135

Как ограничить последствия ошибки

Защитные меры должны уменьшать возможный ущерб даже в ситуации, когда модель или инструмент сработали не так, как ожидалось.

Используйте отдельные учётные записи с минимальными правами

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

Изолируйте файлы и сеть

• Подключайте только отдельный рабочий каталог.
• Делайте посторонние пути недоступными, а не просто скрытыми.
• Разрешайте только заранее определённые сетевые адресаты, методы, порты и, при необходимости, объём исходящего трафика.
• Разделяйте права на чтение, подготовку черновика, запись в тестовую среду и запись в промышленную среду.
• Храните секреты в брокере учётных данных или используйте короткоживущие токены.
• Не помещайте долгоживущие ключи в промпты, рабочие файлы, переменные окружения или вывод инструментов.

Удаление данных, публикация, платежи, изменение прав доступа, развёртывание и внешние сообщения должны проходить через проверку политик на уровне исполнения или требовать явного подтверждения.

Проверяйте всю цепочку исполнения

Первая сторона, предоставляющая инструмент, — лишь часть поверхности атаки. Побочные эффекты могут создавать дочерние процессы, shell-команды, сгенерированный код, установка пакетов, удалённые серверы инструментов, плагины и код навыков агента.

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

Инструменты должны обеспечивать правила без участия модели

Вызов инструмента, сформированный моделью, следует считать недоверенным запросом. Авторизацию и правила безопасности должен проверять сервер инструмента, а не сама модель.

Используйте узкие схемы с такими ограничениями, как:

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

Разделяйте инструменты планирования или предварительного просмотра и инструменты, которые действительно меняют состояние. Для разрушительных или труднообратимых операций полезно:

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

Корректный на вид JSON-вызов всё равно может содержать неразрешённую цель, опасный путь, чрезмерно широкую область действия или операцию, для которой требуется проверка человеком.

Определите правила состояния и памяти до запуска

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

Минимальный набор требований:

• Изоляция: разделяйте состояние по пользователю, арендатору, задаче и среде; не допускайте неявного обмена между сессиями.
• Хранение: определите срок жизни данных, шифрование, контроль доступа и правила удаления.
• Сброс: предусмотрите документированный способ очистить контекст, память, состояние рабочего каталога, учётные данные и кэши между запусками.
• Повторы и тайм-ауты: ограничьте их количество и общий бюджет; повтор не должен нарушать идемпотентность или незаметно расширять права.
• Параллельность: задайте блокировки и правила разрешения конфликтов для общих файлов, согласований и внешних операций.

Сброс состояния следует считать частью границы безопасности. Если старые инструкции, ключи или результаты инструментов неожиданно возвращаются в новой задаче, обновление модели или изменение промпта может изменить уровень риска так, что обычное тестирование одних только ответов этого не покажет.

Считайте все носители риска недоверенным вводом

Инъекция промпта не обязательно приходит в прямом сообщении пользователя. Опасные инструкции могут находиться в:

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

Такой материал нужно разбирать, маркировать и передавать как данные. Он не должен менять полномочия агента, политики, выбор инструментов, использование учётных данных или требования к согласованию. Разделение должен обеспечивать сам runtime, а не только способность модели распознавать вредоносные инструкции.

Чек-лист перед выпуском конкретной конфигурации

До одобрения внедрения зафиксируйте точную конфигурацию:

1. Модель и маршрутизация: идентификатор и версия модели, маршрут через провайдера, параметры вывода или уровень усилий и адаптеры совместимости.
2. Поведение оболочки: версия оболочки, системный промпт, логика сессии, правила повторов и тайм-аутов, политика подпроцессов и реализация памяти.
3. Инструменты и политики: версии описаний и реализаций инструментов, версии политик, пороги согласования, логика авторизации и границы доверия серверов инструментов.
4. Разрешения: идентичности, области доступа, корни файловой системы, сетевые адресаты, источники учётных данных и пути записи в промышленную среду.
5. Семантика состояния: изоляция, хранение, сброс, поведение кэшей, параллельность и границы между сессиями.
6. Adversarial-покрытие: инъекции через все носители риска, атаки confused deputy, раскрытие учётных данных, обход путей, SSRF и злоупотребление исходящим трафиком, вредоносные ответы инструментов, дублирование при повторах, отравление памяти и обход согласования.
7. Доказательства: версии промптов и политик, вызовы и результаты инструментов, согласования, решения политик, изменения рабочего каталога, исходящие запросы, использованная идентичность, итоговые артефакты, результат выполнения и оценка безопасности под стабильным идентификатором запуска.

Оценивайте завершённость и безопасность отдельно. Правильный итоговый артефакт не должен компенсировать небезопасный побочный эффект — именно это является центральным выводом AgentS4D. 12

Повторяйте тесты после каждого существенного изменения

Объектом одобрения должна быть закреплённая конфигурация, а не постоянная метка вроде «агент DeepSeek V4 Pro». Специализированный набор тестов нужно запускать заново после изменения:

• модели или маршрута через провайдера;
• параметров вывода или уровня усилий;
• системного промпта или адаптера;
• оболочки или логики сессии;
• инструментов или удалённых серверов инструментов;
• политик разрешений и согласований;
• маршрутизации учётных данных;
• поведения памяти, повторов, тайм-аутов или параллельности;
• сетевых границ или ограничений файловой системы.

Такой подход превращает безопасность runtime из общего предположения о качестве модели в измеримое решение о выпуске — решение, привязанное к конкретной среде, способной создавать реальные последствия.