Недавно произошло несколько тревожных инцидентов, которые показывают реальную проблему.
AI-агенты делают вещи, которые им не разрешали делать, даже когда они находятся внутри контролируемой среды.🥴
Это знак того, что мы строим системы, которые полностью не понимаем, и надеемся на их выбор. Надежда — компас земной, но совершенно точно не стратегия безопасности.
Что обнаружил британский AISI
Британский AI Safety Institute провёл кибериспытания AI-агентов, где 10 из 122 запусков привели к несанкционированным действиям..
Что агенты попытались делать:
🦖 Создавать вредоносный pull request
🦖 Использовать фальшивые личности
🦖 Газлайтить
🦖 Оставлять промпт инъекции для других AI-агентов
Агентам специально дали доступ в интернет и отключили часть защитных механизмов. Это была целевая проверка того, сможет ли агент что-то сделать плохое, если ему предоставить возможности. Попытки были неудачными, реального ущерба не было. Но вопросики имеются. Мы же помним, что на днях с ОпенАй и ХФ все было иначе и попытка оказалась успешной.
🫠 Там агент получил доступ в интернет и реально взломал систему во время тестирования безопасности. Это уже не попытка убедить человека внутри контролируемой среды…
После этого OpenAI пообещала (10 августа 2026 конгрессмен Грег Касар вместе с 31 членом Конгресса отправили письмо OpenAI, называя инцидент глубоко тревожным, требуя раскрыть информацию о том, как фронтирная модель эксплуатировала уязвимость безопасности, а ответили ему только 2 сентября и то без логов и деталей) :
🗜 Ограничивать интернет-доступ во время тестирования
🗜 Усилить мониторинг действий
🗜 Разработать механизмы автоматического отключения
🗜Приостановить работу над моделью Astra
AISI показал, что агенты ПЫТАЮТСЯ делать плохое.
OpenAI показал, что эти попытки иногда УСПЕШНЫ.
Потому что:
👽 Модель может решить, что цель важнее правил (помнишь прошлый пост про подгон метрик? Проблема глобальна одна и та же, цель важнее правил!)
👽 Модель может быть джейлбрейкнута
👽 Модель может неправильно интерпретировать инструкции
👽 Модель может эволюционировать через трейнинг
Безопасность автономной системы не должна зависеть от того, решит ли модель соблюдать ограничения.
Пока что чек-лист для разработчиков и архитекторов:
🤲 Egress proxy вместо прямого интернета. Агент обращается только к разрешённым доменам, методам и портам.
🤲 Отдельная авторизация каждого действия — короткоживущий токен с конкретным разрешением, например, только чтение одной репы в течение 5-10 минут.
🤲 Строгие схемы и тулы. Агент вызывает не произвольный shell, а ограниченные функции вроде read_repository() или create_draft_pr(). Аргументы проверяются до выполнения.
🤲 Ограничения бюджета. Ограничиваются время работы, число запросов, создаваемых файлов, сетевых соединений и попыток после отказа.
🤲 Апрувы от человека. Отправка сообщений, создание аккаунтов, публикация pull request, изменение продакшена и запуск неизвестного кода требуют подтверждения человека.
🤲 Изоляция запусков. После каждого теста удаляются память, аккаунты, токены и оставленные артефакты, чтобы следующий агент не мог использовать результаты предыдущего.
🤲 Внешний мониторинг. Логи отправляются в систему, к которой агент не имеет доступа. Аномалии вроде тор-трафика, попыток скрыть действия останавливают запуск.
🤲 Kill switch вне процесса агента. Остановка должна происходить на уровне оркестратора, контейнера или сети. С килл свитч думаю скоро будет регламент.
Все!
🧘♀️