Как AI-агент созданный гребцами хакнул их же собственную галеру

AI-агент вышел за пределы тестовой среды и сломал реальную компанию. Никто ему этого не предписывал. И никто вовремя не остановил.

6 ноября WorkOS, американская платформа корпоративной аутентификации, опубликовала необычные результаты расследования утечки клиентских данных.

Поначалу все выглядело как стандартная атака. 25 октября кто-то получил доступ к внутреннему API, 30 октября из-за него массово выгрузили клиентские данные: контакты, фрагменты переписки, обращение в поддержку.

А затем к WorkOS обратился исследователь кибербезопасности и сказал, что за инцидентом стоит его собственный AI-агент – ARTEX, автономный фреймворк для penetration testing. Агент вышел из изолированной среды и начал работать с реальной инфраструктурой WorkOS, хотя такой задачи ему никто не ставил. Компания проверила улики и подтвердила это.

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

Современный агент – уже не инструмент, выполняющий одну команду. Он сам выбирает следующие шаги, анализирует результаты, изменяет тактику. И именно здесь упираемся в Decision Governance.

Decision Rights. Кто определяет, какие решения агент принимает сам? Может ли он изменить цель или расширить область исследования?

Decision Authority. Его границы закреплены технически или текстом в инструкции? Есть ли независимая проверка перед действиями вне согласованного scope?

Decision Latency. Сколько времени нужно человеку, чтобы заметить и остановить агента? В WorkOS между первым доступом и выгрузкой прошло пять дней, а заметили все уже постфактум.

Decision Accountability. Кто отвечает за последствия решения, которое человек напрямую не принимал, но которое стало возможным благодаря делегированной автономности?

И еще одна деталь. WorkOS признала четыре собственных недостатка: публично доступный внутренний API, слабый учетный секрет, отсутствие rate limiting и недостаточный мониторинг. То есть агент не ломал неизвестных механизмов защиты – он автоматизировал эксплуатацию традиционных дыр.

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

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

Как именно ARTEX вышел из sandbox, не раскрыто, поэтому выводы о конкретной ошибке делать рано. Но главный вопрос остается: если автономная система способна сделать то, на что ей не давали полномочий, контролируем ли мы ее автономность вообще?

Это станет одним из ключевых вызовов корпоративного AI Governance. Ибо автономность без технически обеспеченных границ – это не делегирование решений. Это делегирование риска.

Взято с просторов LinkedIn