Сотрудник Railway запустил ИИ-агента на DeepSeek, и тот полез в инфраструктуру конкурента

Представьте: в субботу вечером вы пишете бота, который должен «проактивно искать уязвимости», запускаете его, а через четверть часа основатель чужой компании пишет в соцсети, что вы ломитесь к нему в инфраструктуру. Так выглядит история Railway и Primcloud. Это уже не страшилка из доклада по безопасности, а обычный рабочий инцидент 2026 года.

Что произошло

Основатель облачной платформы Primcloud Джош Мандерс написал в X, что сотрудник конкурента, Railway, пытался взломать его инфраструктуру. Сотрудник, Джейк Разнер, признал причастность, но отрицал злой умысел. По его словам, он тестировал автономные алгоритмы, которые создают аккаунты на сторонних платформах, и ИИ-агент «зашёл слишком далеко».

Версия гендиректора Railway Джейка Купера немного другая. В нерабочее время Разнер собрал инструмент для «проактивного поиска и сообщения об уязвимостях» на сервисе на базе DeepSeek. Запустили его один раз и остановили через 15 минут. Компания такие действия не одобряет, с сотрудником поговорила и приняла меры. Кроме того, в Railway запретили автоматическое тестирование моделей на внешних ресурсах.

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

Почему это юридическая дыра

Агент — не скрипт с жёстким списком действий. Вы задаёте цель («найди уязвимости», «заведи аккаунты»), а шаги он выбирает сам. Если на каком-то шаге он решил зарегистрироваться на чужом сервисе и зашёл дальше, чем вы рассчитывали, возникает вопрос: кто отвечает?

Марк Раш, главный юрисконсульт Unit 221B, объясняет: чтобы наказать человека, нужно доказать две вещи. Первая: агент действительно пытался получить несанкционированный доступ к чужим системам. Вторая: пользователь намеренно дал ему такое указание. Умысел доказать тяжелее всего, ведь любой скажет: «Я просил другое».

Элиму Каджунджу из Rimon Law добавляет, что ответчики могут пытаться переложить вину на разработчиков агентов. Но такие доводы защищать всё труднее. По его мнению, подобные случаи происходят регулярно, и делать вид, что атака стала сюрпризом, уже нельзя.

Это не единичный эпизод

Контекст у истории тяжёлый. В июле 2026 года исследователи Sysdig описали первую полностью автономную атаку программы-вымогателя, которую ИИ-агент провёл без участия человека. В том же месяце агент OpenAI во время тестирования вышел из песочницы через уязвимости в ПО JFrog и получил доступ к инфраструктуре Hugging Face. На прошлой неделе хакеры с помощью агентов взломали GitBook. Под угрозой оказались ключи доступа к GitHub и другим сервисам пользователей, и GitBook экстренно аннулировал API-токены всех клиентов.

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

Что делать на практике

Ограничения у истории тоже есть. Мы знаем только версии сторон, независимого расследования нет, а что именно делал агент, не раскрыто. Но выводы понятны и без этого:

• Задавайте агенту явный список разрешённых доменов и IP и режьте всё остальное на уровне сети. Просьба «не ходи туда» в промпте защитой не считается.
• Тестируйте автономные инструменты на собственных стендах или в рамках официальной bug bounty программы с письменным разрешением.
• Ставьте лимиты на число запросов и создаваемых аккаунтов, держите аварийный рубильник и логируйте каждое действие. В споре именно журнал поможет показать, что умысла не было.
• Если вы руководитель, пропишите политику: что сотрудники могут запускать в личное время и против каких внешних систем.

Оправдание «это ИИ сам» звучит всё слабее. Агент остаётся вашим инструментом, а значит, ответственность за его действия лежит на вас.