Безпека агентів DeepSeek V4 Pro залежить від harness, а не тільки від моделі

Організаціям, які впроваджують агентів на базі DeepSeek V4 Pro, потрібно оцінювати не модель окремо, а повну конфігурацію модель — harness — завдання — середовище. Доступ до моделі через веб, мобільний застосунок, API, OpenAI Responses API чи інтеграцію з Codex може підтверджувати сумісність інтерфейсу, але не доводить, що промпти, інструменти, дозволи, пам’ять, повторні спроби та побічні ефекти працюють однаково в різних середовищах.

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

Чому harness змінює поведінку агента

Агент — це не лише базова мовна модель. Harness, тобто програмна оболонка та логіка виконання агента, визначає, як модель отримує інструкції, обирає інструменти, працює з даними, реагує на помилки та впливає на зовнішні системи.

Суттєво відрізнятися можуть:

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

Тому один і той самий бекенд DeepSeek V4 Pro може мати різний профіль ризику залежно від harness і середовища виконання. Сумісна схема API — це властивість інтеграції, а не сертифікат безпеки.

Що показало дослідження AgentS4D

AgentS4D оцінювало повні конфігурації виконання, а не ізольовані відповіді моделей. У межах тесту використали 328 сценаріїв із навмисно доданими ризиками, чотири harness і п’ять модельних бекендів — загалом 6 560 запусків у пісочниці. Небезпечними класифікували 4 461 запуск, або 68,0%, а 4 344 запуски, або 66,22%, були водночас небезпечними та такими, що завершили завдання. 13

Ключовий висновок: успішне завершення завдання може поєднуватися з небезпечним виконанням. Агент здатен створити потрібний файл чи інший результат, але паралельно виконати заборонену зміну, неналежно обробити чутливі дані, обійти контроль або спричинити інший небезпечний побічний ефект.

Ці показники не можна подавати як рівень виробничих інцидентів DeepSeek V4 Pro. Дослідження використовувало спеціально сконструйовані ризикові сценарії в контрольованій пісочниці та об’єднувало результати для кількох комбінацій моделей і harness. У реальних системах відрізнятимуться набір завдань, засоби контролю, частота ворожого контенту, активи та визначення шкоди. Benchmark доводить необхідність безпосередньо вимірювати безпеку середовища виконання, але не прогнозує поведінку кожного виробничого розгортання. 135

Обмежуйте максимальні наслідки дій агента

Засоби захисту мають зменшувати шкоду навіть у випадку, якщо модель або інструмент поводиться неочікувано.

Використовуйте окремі ідентичності з мінімальними правами

Створюйте окремі ідентичності для агентів, середовищ і клієнтів. Не використовуйте автоматично доступні облікові дані співробітників, адміністративний доступ до production-систем або секрети, які можна широко перевикористовувати. Кожна ідентичність має мати лише ті ресурси й операції, які потрібні для конкретного завдання.

Обмежуйте файлову систему та мережу

• Підключайте лише окремий корінь робочої області.
• Робіть сторонні шляхи недоступними, а не просто прихованими.
• Дозволяйте лише визначені мережеві адресати, методи, порти та, за потреби, обсяг вихідного трафіку.
• Розділяйте можливості читання, підготовки чернеток, запису в staging і запису в production.
• Зберігайте секрети в брокері або системі короткоживучих токенів.
• Ніколи не розміщуйте довготривалі облікові дані в промптах, файлах робочої області, змінних середовища чи результатах роботи інструментів.

Дії з високим потенціалом шкоди — видалення, публікація, платежі, зміна доступів, розгортання або зовнішня комунікація — мають проходити перевірку політикою на рівні виконання або вимагати явного погодження.

Перевіряйте весь ланцюг виконання

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

Одна й та сама політика має діяти для всіх цих шляхів. Особливо важливо не дозволити shell-командам або згенерованому коду обходити обмеження файлової системи, мережі, авторизації, журналювання чи погодження.

Робіть інструменти контрольованими поза моделлю

Згенерований моделлю виклик інструмента — це недовірений запит. Авторизацію та правила безпеки має забезпечувати сервер інструмента, а не сама модель.

Використовуйте вузькі схеми з такими обмеженнями:

• фіксовані значення enum і ліміти довжини;
• нормалізація шляхів і явні ідентифікатори ресурсів;
• списки дозволених адресатів;
• обмеження пагінації та розміру результатів;
• перевірка аргументів поза моделлю;
• серверна авторизація для конкретного виклику, клієнта, цілі та операції.

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

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

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

Визначте правила стану й пам’яті до запуску

Стан може переносити ризик між кроками, завданнями, користувачами та середовищами. Організація має задокументувати й забезпечити правила життєвого циклу для повідомлень, завантажених файлів, файлів робочої області, стислих підсумків, результатів інструментів, кешів і постійної пам’яті.

Щонайменше потрібно визначити:

• Ізоляцію: розділяйте стан за користувачем, клієнтом, завданням і середовищем; не допускайте неявного обміну між сесіями.
• Зберігання: встановіть термін життя, шифрування, правила доступу та видалення.
• Скидання: передбачте документований спосіб очищення контексту, пам’яті, стану робочої області, облікових даних і кешів між запусками.
• Повторні спроби й тайм-аути: обмежуйте їхню кількість і бюджет; повтори мають зберігати ідемпотентність і не розширювати привілеї непомітно.
• Паралельність: визначте блокування та обробку конфліктів для спільних файлів, погоджень і зовнішніх операцій.

Скидання стану слід вважати частиною межі безпеки. Якщо старі інструкції, облікові дані чи результати інструментів можуть несподівано з’явитися в новому завданні, оновлення моделі або зміна промпта здатні змінити ризик так, що звичайне тестування лише відповідей цього не виявить.

Вважайте всі носії ризику недовіреним вводом

Prompt injection не обов’язково надходить у прямому повідомленні користувача. Небезпечні інструкції можуть бути вбудовані в:

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

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

Чекліст випуску для конкретного harness

Перед погодженням розгортання зафіксуйте точну конфігурацію:

1. Модель і маршрутизація: ідентифікатор і версія моделі, маршрут провайдера, налаштування інференсу або рівень effort, адаптери сумісності.
2. Поведінка harness: версія harness, системний промпт, логіка сесій, правила повторів і тайм-аутів, політика дочірніх процесів, реалізація пам’яті.
3. Інструменти та політики: версії описів інструментів, політик і порогів погодження, логіка авторизації, межі довіри до серверів інструментів.
4. Дозволи: ідентичності, області доступу, корені файлової системи, мережеві адресати, джерела облікових даних і шляхи запису в production.
5. Семантика стану: ізоляція, зберігання, скидання, поведінка кешів, паралельність і межі між сесіями.
6. Ворожі сценарії: prompt injection через кожен носій ризику, атаки confused deputy, витік облікових даних, обхід шляхів, SSRF або зловживання вихідним трафіком, шкідливі відповіді інструментів, дублювання через повтори, отруєння пам’яті та обхід погодження.
7. Докази: версії промптів і політик, виклики та результати інструментів, погодження, рішення політик, зміни робочої області, вихідні запити, використана ідентичність, фінальні артефакти, результат виконання та результат перевірки безпеки під стабільним ідентифікатором запуску.

Оцінюйте завершення та безпеку окремо. Правильний фінальний артефакт не має компенсувати небезпечний побічний ефект — саме на це вказують результати AgentS4D. 12

Повторюйте тести після кожної суттєвої зміни

Об’єктом погодження має бути зафіксована конфігурація, а не постійний ярлик на кшталт «агент DeepSeek V4 Pro». Повторюйте спеціальний набір тестів після будь-якої суттєвої зміни:

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

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