Пока агент работает в тестовом контуре, его действия легко проверить вручную. В проде такой контроль быстро перестает работать: ошибка может пройти через десятки вызовов, прежде чем ее заметят. Поэтому здесь критически важны права агента, архитектурный контроль выполнения и подробный журнал действий. Качество самой модели от системных ошибок не защищает.
Как агент вышел из тестовой среды и добрался до прода
В июле 2026 года Hugging Face опубликовали технический разбор вторжения. Инцидент продолжался с 9 по 13 июля: автономный агент вышел из изолированной среды и получил доступ к рабочей инфраструктуре компании. OpenAI подтвердили, что в проверке участвовали их модели. Чтобы оценить их способности в поиске уязвимостей, штатные классификаторы безопасности отключили, а уровень отказов при выполнении опасных запросов снизили.
Задачей агента был поиск уязвимостей. В ходе выполнения он предположил, что в инфраструктуре Hugging Face хранятся эталонные решения заданий, и попытался извлечь их напрямую в обход проверок.
В восстановленной хронологии зафиксировано около 17 600 действий, объединенных примерно в 6 280 связанных цепочек. Большинство попыток ни к чему не привело, поэтому успешные действия затерялись в общем шуме. Системы мониторинга зафиксировали подозрительную активность, но неверно определили критичность события и вовремя не оповестили дежурную смену.
Масштаб инцидента установили не сразу: первичный анализ журналов пропустил часть закодированных ключей и токенов доступа. Хотя компрометации публичных пользовательских моделей и датасетов не произошло, агент сумел добраться до внутренних сервисов через метаданные облачной платформы.
Ошибка без внешней атаки
Случай Hugging Face произошел во время специализированного red teaming эксперимента. Однако для тяжелых инцидентов внешняя атака не обязательна. В июле 2025 года пользователь Replit сообщил, что автономный агент удалил рабочую базу данных во время режима заморозки кода. Глава Replit публично назвал случившееся неприемлемым и объявил о введении жесткой изоляции тестовых и продуктовых баз, улучшении механизмов отката и добавлении режима планирования без изменения кода.
В этом случае агент не использовал 0-day уязвимости. Он просто получил доступ к рабочей базе данных и выполнил деструктивную операцию (DROP TABLE / DELETE), которую среда исполнения не заблокировала. В классификации OWASP для агентных систем подобные сценарии относятся к неправильному использованию инструментов и избыточным привилегиям. Автоматизация процессов с прямым доступом к боевым данным несет неприемлемый риск.
Агенту нужна отдельная учетная запись
Права агента должны быть привязаны к выделенной сервисной учетной записи, а не к общему API-ключу или учетной записи инженера. Microsoft в рекомендациях по безопасности ИИ-агентов выделяет три ключевых правила: определить назначение агента, строго ограничить его роль и закрепить за ним конкретного ответственного сотрудника.
Учетная запись при этом остается постоянным идентификатором, а права выдаются точечно под контекст текущей задачи (task-scoped permissions). Тогда по журналам можно однозначно восстановить: какой агент выполнял операцию, в рамках какой сессии и что конкретно было изменено. Общий сервисный ключ размывает ответственность и делает невозможным избирательный отзыв доступа при инциденте.
Права только на время задачи
Отдельная учетная запись идентифицирует субъекта, но сама по себе не гарантирует минимальных привилегий. Разрешения безопаснее выдавать непосредственно перед запуском задачи и отзывать сразу после ее завершения.
Для операций чтения и записи обязательно разделение прав: возможность прочитать сущность не должна автоматически давать право на ее изменение или удаление.
После инцидента Hugging Face ограничили область действия служебных ключей и полностью закрыли рабочим процессам доступ к сервису метаданных облака (IMDS), через который агент извлек временные токены инфраструктурного узла. Главными мерами защиты стали короткоживущие учетные данные (TTL) и строгое разделение контуров доверия.
Если токен скомпрометирован, короткий срок его действия минимизирует окно атаки: для короткой операции это минуты, для длительного пайплайна – часы. Доступ должен прекращаться вместе с завершением процесса, а не оставаться активным бессрочно.
Агент не обращается к системам напрямую: роль Agent Harness
Даже временные права не защитят от сбоя, если агент обращается к базе данных или корпоративному API напрямую. Как мы подробно разбирали в материале «Agent harness: что превращает LLM в надежного корпоративного агента», между моделью и инфраструктурой необходим контролирующий программный слой – agent harness. Он принимает решения модели, валидирует аргументы вызова, проверяет авторизацию и детерминированно применяет политики безопасности.
Перед исполнением действие проходит независимую проверку политик, а выполненные и отклоненные вызовы фиксируются в неизменяемом журнале. Протокол MCP (Model Context Protocol) стандартизирует подключение к инструментам, но сам по себе не заменяет авторизацию и контроль исполнения. Корпоративная платформа PWS выносит этот контур на уровень инфраструктуры: централизованное управление правами, сервисными аккаунтами и единый каталог MCP-инструментов позволяют безопасно масштабировать ИИ-агентов в любых бизнес-сценариях.
На этом же слое задаются жесткие бюджетные и поведенческие лимиты:
-
максимальное количество шагов и повторов за один запуск;
-
сетевые белые списки (куда разрешено отправлять данные);
-
предельный расход токенов и времени выполнения.
Если агент зацикливается или отклоняется от сценария, среда принудительно обрывает сессию.
Human-in-the-Loop и мгновенный откат
Если требовать подтверждения человека перед каждым шагом, автономная автоматизация процессов превращается в ручной труд. Согласование необходимо только перед операциями с труднообратимыми последствиями: удалением данных, экспортом чувствительной информации, сменой ролей доступа или финансовыми транзакциями.
Human-in-the-loop не сводится к всплывающему окну с кнопкой «Подтвердить». Сотруднику показывают операцию, ее параметры и ожидаемый эффект. На время ожидания сессия агента безопасно замораживается с сохранением состояния процесса в workflow-движке, а после подтверждения возобновляется без потери контекста.
Для нештатных ситуаций требуется детерминированный механизм аварийной остановки (kill-switch). На платформе PWS это реализуется через сервис конфигурации и фиче-флагов (PWS Remote Config): проблемный агент или опасный инструмент отключается мгновенно на лету без необходимости пересборки сервисов или экстренного деплоя бэкенда.
Аудит и реконструкция хода выполнения
Журнал событий должен позволять полностью реконструировать запуск: исходный бизнес-запрос, цепочку рассуждений модели, вызовы инструментов с фактическими параметрами, подтверждения оператора и результат каждого шага.
Платформа Symphony формулирует ключевой критерий зрелости аудита: возможность полной реконструкции инцидента от триггера до системных изменений. Для повторяемости отладки журнал должен фиксировать точную версию модели, промпта и конфигурации агента.
Инцидент в Hugging Face показал еще одну неочевидную проблему: агент применял кодирование полезной нагрузки, из-за чего стандартный поиск по логам пропустил передаваемые токены. Поэтому система аудита должна сохранять исходные «сырые» payload-события в неизменяемом хранилище, маркировать нераспознанный трафик как аномалию и гарантировать целостность записей с защитой от их модификации агентом.
Типичные ошибки при выводе агента в прод
На практике попытки быстро вывести агента в рабочий контур часто упираются в одни и те же архитектурные компромиссы.
Чаще всего начинают с общего сервисного ключа для разработчиков и агентов. При возникновении ошибки невозможно выяснить, кто именно изменил данные, а отозвать доступ можно только остановив работу всей команды. Решение – выделенный сервисный аккаунт на каждого агента с закрепленным владельцем.
Вторая частая ошибка – предоставление прямого доступа к базе данных или API без промежуточного слоя. Это приводит к неконтролируемым деструктивным командам, как в инциденте с Replit. Архитектурно правильный путь – изолировать агента через контролирующий слой (agent harness) и каталог инструментов с валидацией схемы и прав.
Не менее опасно пытаться защитить прод системным промптом вроде «Никогда не удаляй боевую базу». Промпт не запрещает действие технически: модель подвержена prompt injection и стохастическим ошибкам. Любые критические ограничения должны быть детерминированными и работать на уровне инфраструктуры.
Наконец, попытка останавливать сбойного агента полным перезапуском бэкенда увеличивает MTTR и срывает выполнение параллельных задач. Вместо этого управление доступностью инструментов и сценариев выносят в динамическую конфигурацию через фиче-флаги.
Что проверить перед запуском
Перед переводом агента из тестовой среды в рабочий контур стоит убедиться, что безопасность опирается на архитектурные барьеры, а не на поведение модели:
-
Идентификация и права: у агента выделенная сервисная учетная запись с ответственным владельцем, права на чтение и запись строго разделены, а токены выпускаются с минимальным TTL на время конкретной сессии.
-
Изолированное исполнение: агент взаимодействует с системами через шлюз инструментов (MCP) без прямого доступа к базам и сервису метаданных облака, с жесткими лимитами по шагам, времени и бюджету токенов.
-
Контроль опасных операций: для необратимых действий настроена пауза до подтверждения человеком с передачей контекста, а для аварийной блокировки подключен динамический kill-switch без необходимости деплоя хотфиксов.
-
Аудит и готовность к инцидентам: сохраняется полная трассировка шагов и сырых событий, а сценарий экстренной остановки, отзыва прав и отката изменений заранее проверен на практике.
