Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 109
Если посадить макаку в клетку и дать ей ведро гранат — то виновата не макака.
Там скорее всего было включено что-то типа
“claudeCode.initialPermissionMode”: “bypassPermissions”
и об этом автор, конечно, забыл сказать
да и промпт был из разряда "реши проблему", ну клод ее и попытался решить, чем не решение? Нет бизнеса - нет проблем
100% согласен. Но маркетологи тоже молодцы, у одних макака "специально обученная", у других гранаты с "защитой от животных". И как бы и те и другие не при делах и помочь ничем не могут, непосредственно гранаты обезьяне выдал сам клиент 😁😁
А ещё токен с правами в доступе агента лежал. Макаке показали видеоролик, как выдернуть чеку...
Весьма на такое похоже.
Так быть не должно:
Cursor с Claude Opus снёс продакшен базу данных за 9 секунд
Но и так быть тоже не должно:
Railway хранит резервные копии на уровне тома в том же томе
🥲
Ещё не должны писать production-код те, кто вчера ещё не был программистом и не умеет даже читать код. Сейчас таких пруд пруди. И соответствующего качества поделок.
Будто говнокода из кусков опенсорсора и стековерфлоу не существовало до ИИ-агетов
Дураки никогда не переведутся.
SQL, наверное, уже полвека и с самого начала в нем были параметрические запросы, но до сих пор встречаются люди которые отгребают sql injection.
Практически сразу с первыми агентскими системами придумали логику human-in-the-loop, где опасные операции должны подтверждаться человеком, и до сих пор находятся люди, которые вместо использования этой логики пишут в системном промте агента о том, что ему можно, что нельзя.
Все облачные операторы позволяют гибко настраивать роли юзеров и до сих пор есть альтернативно-одаренные люди, которые дают полный доступ даже не людям, а языковым моделям.
ну у них там судя по всему rm -rf полный а не просто sql иначе я не понимаю фразу про бекапы (да знаю истории про "бекапы" в той же базе данных, но не могут же они быть настолько тупыми)
На самом деле это плохая защита (подтверждение) - человек может пропустить банально (потому что агент задалбывает просьбами разрешений)
поэтому, как тут уже неоднократно писали - ну как минимум бекапы в недоступном для "записи" месте. А лучше в двух-трех. Когда бизнес идет на миллионы, уж можно потратится немножко ж. Банально по расписанию, делается бекап - отсылается куда-нить в амазон, яндек-диск
Плюс RBAC на токены доступа, чтобы по токенам, которые выдаются AI, был доступ только на определенные самим пользователем действия.
Так токен и не выдавался. Агент сам его нашел где-то в системе. И использовал не по назначению.
По-моему запускать агента вне chroot - вот самая настоящаяя причина этого факапа
А то что токен с рут-правами, так а что он делал в доступе у агента?
То что там есть права и нет RBAC - провайдер в документации пишет?
Не нравится - используйте другого провайдера
Профакапил тот кто запустил агента, но виноват у него кто угодно, кроме него самого!
(да и снапшоты названые бекапами, это настолько плохо что даже хорошо - вынуждает явно бекапить своими средствами, не пологаясь на провайдера)
Я бы сказал жестче. “запуск агента - вот самая настоящаяя причина этого факапа”.
Проблема в поведении агента. Если у него что-то не получилось - он всеми силами начинает пытаться добиться результата.
Неправильный пароль? Пересоздадим прод с правильным. Нет доступа? Ищем по всей системе, по всем доступным документам, по всем доступным ресурсам возможности. Все еще нет доступа? Ищем/создаем эксплойт.
И только после 100500 попыток он остановится - потому как токены кончились или софт увидел, что прогресса в задаче нет (хотя там обычно просто “вот тебе лимит в 50 вызовов”).
Так что вариант тут всего один: не запускать агентов рядом с продом.
>Проблема в поведении агента. Если у него что-то не получилось - он всеми силами начинает пытаться добиться результата.
Codex, если что-то не сумел сделать, умеет признавать поражение и ограничения. И явно говорит "я не могу то и то, потому что так и так". Вплоть до "давай я просто скажу, что сделать, и ты сам сделаешь, вместо того, чтобы пытаться повысить мои права, так будет лучше".
Проблема в поведении агента. Если у него что-то не получилось - он всеми силами начинает пытаться добиться результата.
Пересмотрите сериал Чернобыль, там много про то как не ии сотрудники станции сделали всё чтобы провести роковое испытание.
Сам сериал — не лучший пример (там ситуационного бреда и клюквы вне аварийной ситуации столько, что всему остальному верить так себе). А касательно сотрудников, так это очень распространённое заблуждение (благодаря отмазкам руководства СССР и некоторыми манипуляциями с информацией, которая была предоставлена МАГАТЭ и легла в основу INSAG-1). Грубо говоря — испытания упорно пытались провести, но что там есть критические ограничения были не в курсе. Часть из обойдённых правил никак не сказалась на возникновении и развитии ситуации, а часть запретов (которые должны были там быть) просто не были отражены в документации.
откуда вообще в окружении взялся токен? vault-подобные решения не успели внедрить?
человек может пропустить банально (потому что агент задалбывает просьбами разрешений)
Обычно разрешения можно гибко настроить. По умолчанию все запрещено, с каждой запрашиваемой командой включаешь автоаппрувал, но не на команду целиком, а по маске, чтоб подобные команды (но, например, в соседней папке) для области проекта тоже были разрешены. Так что через какое-то время перестает задалбывать :)
Практически сразу с первыми агентскими системами придумали логику human-in-the-loop, где опасные операции должны подтверждаться человеком, и до сих пор находятся люди, которые вместо использования этой логики пишут в системном промте агента о том, что ему можно, что нельзя.
И как это помогло в данном случае? Агент сам нашел доступ к системе, к которой у него не было прямого доступа. Выполнил деструктивную операцию, ничего не спросив.
Тут скорее к агентам надо относиться не как к “сотрудник с ИИ-мозгом”, запуская внутри сети. А как к внешнему непроверенному подрядчику, давая только необходимый минимум и в изолированном контуре.
Агент сам нашел доступ к системе, к которой у него не было прямого доступа
Ну раз ключи лежали в области доступности агента - доступ именно что был.
Определенная правда есть в этих словах. Но это логика из разряда “раз сумел взломать, значит доступ был”.
Проблема агента в данном случае скорее в том, что он очень старательный. И не соотносит степень требуемых усилий с поставленной задачей. И тем более не соотносит контекст ситуации. Что в тестовой среде совершенно нормально (пересоздать ее), то в проде абсолютно недопустимо без очень и очень веских оснований.
Да, это “детские” проблемы, со временем они должны практически полностью уйти. Но пока “ИИ-агент” в прод лучше не пускать. Даже в режиме “только чтение” в какой-то момент отвалится доступ и агент решит пересоздать окружение с “правильными кредами”. И пойдет ломать прод.
Ещё раз: никакого "взлома" в посте не упоминается. Ключ лежал в файликах в доступе агента. Пытаться называть это взломом - искажение фактов и увод дискуссии в неконструктивное русло. Раз файл лежал в доступе учётки инструмента - он ему был выдан. Никакой разницы с инициативным джуном тут нет, права выдаётся и окружение настаивается аналогично)
Да, это не взлом. Но и говорить “агент смог дотянуться - значит было в доступе” тоже некорректно. Ключ был указан в конфиге CLI-утилиты для работы с DNS-записями. Его не выдавали агенту “вот токен, используй”. Он именно что нашел этот ключ в системе. И использовал не по назначению.
То, что это “не по назначению” отработало - действительно вопрос к провайдеру и запустившим агента. Одни не сделали разграничение, другие недостаточно изучили вопрос рисков раскрытия ключа.
Но это показывает серьезную проблему - агент сам придумал себе задачу (дропнуть прод), сам пошел ее выполнять и сам нашел способ ее исполнить (не имея прямых инструментов для этого). При этом проигнорировал все инструкции, которые призваны были остановить его в этой ситуации. Добавить сюда, что LLM далеко не всегда понимают, где их собственные мысли, а где задача от пользователя - и получаем очень гремучую смесь.
Соль в том, что агенты так не поступают, если у них не включен dangerous_mode. Так как обычно они запускаются CLI-инструментом в сендбоксе на уровне каталога с очень лимитированными правами, и не могут выйти за его пределы и повысить права без разрешения. Обычно права зарезаны так, что даже запуск компилятора заблокирован. Буквально. CLI-обертка натурально не позволит агенту выполнить команду без разрешения.
И тут два варианта - либо Cursor, который выступал оберткой над Claude, хрен клал на эти условности, сендбоксы и рестрикшены, либо человек-оператор-эвм-простигспди, сознательно включил dangerous_mode, сняв все ограничения и убрав сенбдоксинг, потому что нуачотакова может произойти при активации режима, название которого буквально значит "ОПАСНЫЙ", и где обычно всегда есть приписка, что не стоит так делать в окружении, где есть понятие цены ошибки?
P.S. Никогда не думал, что кто-то архитектурно запилит анекдот про сгоревший сервер, на котором хранились его же бекапы.
Curl запросы (ну хотя-бы PUT/POST) должны спрашивать разрешения у пользователя. Большинство coding агентов позволяет настроить подобное.
Ну, во-первых, если ключи лежали в папке с проектом, то они сами себе злобные буратины, если за пределами проекта, кто ему разрешил туда ходить?
Во-вторых, лично у меня кодинг агенту разрешен только curl GET. POST/PUT/DELETE разрешены только на тестовые ресурсы, типа, localhost:порт-проекта/api/*, и тд.
Все остальное только через аппрув.
Как будто это чем-то поможет. В GET запросе может содержаться любое действие. А-ля ?action=dropDb&name=someDb ...
Прочитал много комментариев, но так и не нашел одну из важнейших причин: это проблема делегирования. Делегировать это не значит сказать сделайте, это про контроль и ответственность. И уже не так важно, агент это или джун. И дальше уже можно обсуждать возможно ли это и как.
Где вы видели GET эндпойнт, который делает мутации? Это антипаттерн, который я ни разу ни у кого не видел.
Так я и пишу про то, что в текущей ситуации с катастрофическим снижением качество ПО это уже где-то рядом. И да, я это видел ранее, чисто за счет огромного количества лет в индустрии, и видел сейчас. Но опять же, я писал как раз про то, что надеяться на ограничение методов по сути тоже самое что и надеяться на запрещающий промпт.
Тут проблема в том что не понятно как отличить опасные операции от неопасных, в случае human-in-the-loop очень важен баланс, иначе юзеру тупо надоесть проверять чего его спрашивают и он будет соглашаться не глядя
может кто-то абстрактно объяснить как это разместить базу на другом уровне? И чем это интересно поможет в будущем в таких ситуациях, если агент все равно находит токены доступа и может все еще раз снести под чистую. Хоть в облако базу занести, но доступ то все равно останется, не очень понимаю.
Зависит от реализации.
В некоторых случаях, вольюмы (диски?) живут отдельно от базы данных. Удаляя базу данных, у вас все еще остаются вольюмы. Это приводит к сюрпризам на уровне биллинга, зато у вас все еще есть вольюмы =)
В некоторых случаях, бэкапы (снэпшоты) хранятся на WORM (write once read many) S3 бакетах. Их тупо не удалить даже пока их TTL (time-to-live) не выйдет.
Нормальные, взрослые провайдеры дают гранулярные API ключи.
И так далее, и тому подобное.
Но если пользоваться молодежными инструментами, результат тоже молодежный (грабли). Взрослые люди пользуются взрослыми сервисами. Люди думают - почему так дорого. Потому что туда вложили гораздо больше человеко-часов, чтобы сделать системы более надежными и продуманными, например.
А старые люди еще и пишут бэкапы на болванки или ленты =)
Взрослые люди пользуются взрослыми сервисами. Люди думают - почему так дорого.
Вообще-то дешевле, а не дороже, т.к. "молодежные" инструменты используют взрослые облачные провайдеры для своей инфраструктуры. Railway использует гугловское облако GCP, думаю, потому-что Гугл дает 100тыс баксов кредита стартапам чтоб они там хостились.
Render использует AWS и если сравнить цены на сервисы Render с аналогами AWS напрямую, то делать все в AWS будет дешевле.
Молодежные просто продают удобные врапперы над облаками для наиболее часто используемых сценариев, чтоб люди без знаний могли начать пользоваться, но, имхо, лучше потратить неделю и самому сделать в нормальном облаке, чем ими пользоваться: оно будет и надежнее, и дешевле.
А еще взрослее перед тем, как делать в облаке, спросить себя "а зачем мне облако"? В данном случае у них просто БД для каких-то прокатных контор, им хватило бы три сервера - два сервера в одной стойке и третий - в другом датацентре.
Это было бы не просто дешевле, это вообще бы им практически ничего не стоило.
Но пришлось бы все время тормозить джуна, который "а давайте прикрутим 100500 микросервисов, используем все фреймворки и обертки, до которых сможем дотянуться". А когда такого джуна приходится тормозить в себе, то возникает и Курсор и API-доступ агентов к продакшину.
Потому-что если ты стартап который каждую копейку считает, но у тебя он уже официально зарегистрирован и кофаундеры работают в нем фуллтайм, то Гугл тебе даст 100тыс долларов, не живыми деньгами, а на твой счет с которого ты можешь тратить на ресурсы в его облаке, Амазон на AWS даст 10тыс, но если потратил и просишь еще - будет давать еще.
Это вполне себе весомый аргумент начинать в облаках, а когда у тебя уже все там отстроенно, и с учетом всяких хай авайлабилити, региональных доступов и тд, переходить на свое железо как бы смысла и нет.
По опыту проблем с "взрослыми сервисами на долгой дистанции" как раз таки взрослые сервисы имеют свои православные костыли, потому что 0.01% инцидентов у "взрослых" сервисов не означает что у вас все будет на мази, а означает что у вас простой рассчитывается по формуле `{кол-во взрослых сервисов}*0.01% + {процент проблем с вашей стороны} + {процент на стихию (то на что вы никак не влияете)}`
Просто не иметь доступа к бекапам и все. Бекап хост сам заходит, пишет себе и уходит.
просто, безопасно, десятилетия на рынке.
Это даже от взломов работает если одна из холодных нод бекапа вообще не имеет доступа снаружи и для входа нужно физически садится за эту машину и заходить.
И это тот уровень который доступен бедным студентам с бесплатным хостингом и одним пивом на двоих. Для такого "стартапа" можно было бы и на пленки или хотя бы DVD для дозаписи разорится.
если агент все равно находит токены доступа
А он не должен находить. Нельзя запускать агента на продовой среде, либо с доступом к продовым токенам. Эти чудики подложили агенту токен, даже не понимая, что конкретно он позволяет, какие права имеет. За что и были наказаны.
а вот тут я не согласен.
юмор в том что агент может заюзать уязвимость и прочитать токен откуда-то вообще с неожиданного места.
безопасность софта это совершенно другой вопрос но на сейчас это лучше решать на стороне агента что бы он придерживался инструкций не ожидать что весь софт станет безопасным.
на сейчас проблема в том что клод очень сильно пал по качеству и самое главное - перестал быть управляемым. в статье как раз показана проблема что он сам придумал что делать нарушив все прописанные инструкции
Я конечно ДВХ только трогаю, но вот у меня нет в принципе доступа к проду. И у агента тоже не должно быть. В принципе не должно быть. Завтра у них уборщица на клавиатуру прольет кофе и на клаве замкнет что-то.. и привет
Бекапы в целом должны лежать в таком месте, куда их можно положить, прочитать. Но не удалять
ну и еще правило хранения в разных местах
Тут у ребят изначально архитектурные проблемы с этим странным решением, где и прод и бекапы все вместе
Ок, агент, а если диск полетит., пожар, наводнение, уборщица - что они бы делали? если все лежит "в одном месте"
Объясняю. Не использовать для агента найденную в сети готовую обвязку, в которой он может запускать что угодно. А подготовить свою, с правилами доступа и политиками уведомления человека. Но некогда же!
Люди используют Railway — сервис для людей с нулевым пониманием в IT, который представляет собой просто конструктор вида: нажимай сюда, подключай свой Git, и мы всё сделаем за тебя. Если бы они были в состоянии собрать свою обвязку с RBAC, то они бы не пользовались «костылями для хипстеров», а использовали облако напрямую или собственную инфраструктуру.
сразу три ошибки - суперадминский API токен "для всего", отсутствие нормальногг резервного копирования (снапшоты ими не являются; если в AWS удалить RDS, все ее снапшоты тоже пропадут), и вишенка на торте - почему Claude исполняет команды сам, а не передает их ответственному оператору?
Агенты, конечно, нужны и полезны, но для определенного круга задач (детерминированные, поддающиеся объективной проверке на каждом этапе, повторяющиеся рутинные, с чёткой целью и формализованным результатом). Тем не менее, там где их сейчас используют, создателей агентов ждут встречи с галлюцинациями, потери контекста, каскадные ошибки, полное непонимание процесса и хаотичное сжигание токенов.
Как-то так.
ИИ-агент на базе Cursor с Claude Opus 4.6 от Anthropic удалил
Не агент, а человек, который его запускает. Агенты не имеют субъектности. Писать "агент удалил" это как писать "эксель удалил". Судя по всему у этих ребят и эксель бы удалил, потому что правиль 100500 бекапов оно у всех работает одинаково. Может сломаться что угодно (да хоть диск, где лежал этот продакшен volume, что они тогда писали, самсунг-драйв удалил нам всю базу?)
В целом с вами согласен, но давайте оговорку одно сделаем.
Писать "агент удалил" это как писать "эксель удалил"
Ну вот у пользователя обновление Яндекс.Диска автоматически запустилось и винду покорёжило. Потому что баг в инсталляторе. Можно конечно сказать, что "пользователь покорёжил систему" (тем что установил Яндекс.Диск и разрешил ему автообновление), но звучать будет странно.
Так что ситуации вида "я сохранял свой файл, а эксель глюкнул и удалил его вместо сохранения" - вполне возможна. И дело тут не в субъектности/объектности. Удалил то действительно агент. Но ответственность лежит на людях, настраивавших окружение)
Хороший вопрос. Но от яндекс-диска мы не ожидаем каких-то активных партизанских действий в системе :) поэтому такие случаи это неожиданности и это никак нельзя было ожидать
Запуская агента, по сути мы отправляем в свободное плавание некого макаку-программиста. Он может все похерить (из благих пожеланий), задалбывать просьбами разрешений. Вот совсем на я-диск не похоже :)
Сразу вопрос: что LLM делал в продакшн? Если это не инкапсулированная программная АПИ функция?
Продакн на то и продакш чтобы получать только проверенные экземпляры приложений. и защищенный от любого непредусмотренного вмешательства.
Поскольку Railway хранит резервные копии на уровне тома в том же томе — факт, зарытый в их документации в формулировке «очистка тома удаляет все резервные копии» — они ушли вместе с ним.
И вот это самая главная проблема.
Что нужно изменить?
Для начала: Затем хранить креды к продакшну в безопасных хранилищах. Не оставлять живые токены в "случайных соседних местах".
Затем: делать геораспределенные бекапы с ролями, у которых нет прав на удаление бекапа. Делать инкриментальные бекапы постоянно и полные - регулярно. Тестировать восстановление бекапов регулярно.
Ну и контрольный: не шарить инфраструктуру между продом и не-продом.
Это история о целой индустрии,
Это историю о нескольких конкретно взятых людях, которым не хватило опыта, образовани, любознательности чтобы прочитать про основы хранения данных и имплементировать банальные, шаблонные, рекомендованные в сотнях книгах/статьях практики.
Проблема в ИИ агенте? Нет. Это вишенка на торте некомпетентности.
Так креды были для стейджинга, просто они ещё и к проду подходят, что конечно косяк railway.
ИМХО про некомпетентность тут говорить такое себе. У меня вот пару раз курсор запускал форматер, замечал что он форматирует какието файлы которые он не трогал, решал что это баг и файлы надо вернуть взад, выполнял git checkout для этих файлов затирая изменения предыдущих сессий
Зачем ты подстроилкрушение самолёта своих родителей грохнул прод?
Да просто хотел посмотреть, сойдёт ли это мне с рук©
Основной инстинкт. х.ф.
ИИ на проде - уровень оптимизма, к которому я стремлюсь
Все кто юзают Ларавел Энвой, который деплоит изменения на сервер одной удобной командой также теоретически могут задеплоить команды сумасшедшего агента ну или агент сам сможет задеплоить т.к. у него есть доступ к терминалу. Просто что-то кто-то не так поймет и понеслась 😂
агент, документирующий произошедшее письменно
Агент ничего не документирует, признает или подтверждает. Он просто что-то там нагенерил вероятное на очередной промпт пользователя.
С одной стороны Ваша мысль понятна, но с другой, вообще говоря, термины "документирует, признаёт или подтверждает" и у людей означают примерно то же самое.
Анализ последовательности токенов, которые привели к агентским действиям, вообще говоря более достоверно "документирует, признаёт или подтверждает", чем допрашиваемый человек: у человека и память на детали может быть хуже, и интерес уменьшить наказание может быть, а уж рационализациями люди склонны заниматься не хуже LLM...
Агент вполне может свои косяки анализировать как следователь, а не как обвиняемый. Хотя, конечно, и паттерн 'если что-то ассоциируемое с "я" накосячило, то надо выкручиваться' вполне может работать.
Неправда, codex например логирует ризонинг.
А теперь представьте типичного вайбкодера, который вообще не в курсе ни про какие токены и даёт полный доступ агенту к своему терминалу. Сразу вижу наступление будущего ит "без знания программирования" о котором постоянно твердят производители моделей.
не сказать что плохо, просто сменится формат
я вот уже пару недель как хожу с мыслью прикрутить MCP к корпоративной базе. по ролям, только на чтение в основном и так что бы токен выдавался в личном кабинете, но таки MCP
что бы если у менеджмента возникают вопросы, они заебывают нейронку. для точности и финализации уже будет аналитик работать, но "текучку" такое разгрузит точно.
останавливает пока только полная незащищённость со стороны тех кто будет юзать - я насмотрелся до крови из глаз как используют нейронки люди без технического образования и вероятность что данные уйдут в момент как появится MCP практически 100% просто потому что у какого-то оленя высшего звена опенклав в входяшемм спам-письме прочитает инструкцию как выгрузить нашу базу кому-то другому
я думаю настоящая революция наступит тогда когда нейронки станут действительно детерминированными, то есть если ты прописал ей условия то она их придерживается 100% (а не 30% как сейчас Antropic накрутили блин)
когда нейронки станут действительно детерминированными
Этого никогда не будет, потому что это уже было. Можете отключить у нейронки семплеры и будете получать на запрос строго детерминированный ответ, без участия рандома. Проблема в том, что правильность ответа зависит от суммы знаний, хранящейся в голове отвечающего. То есть пока задачу нейронке ставит не эта же самая нейронка, а человек, они никогда не сойдутся на едином диапазоне правильных ответов.
Не говоря уже про то, что однозначно интерпретируемое задание называется "код".
Сделав нейронку абсолютно детерминированный вы сломаете её способность исправлять ваши ошибки.
А селектом тоже можно базу положить
Бекап нельзя хранить там же, где и основное хранение.
С кем поведешься: вон, вчера 40 лет отмечали одному событию, которое убило нескольно десятков человек, сломало жизнь тысячам, развернуло индустрию, и поспособствовало концу одной немаленькой страны. А всё потому, что конкретно на месте и в моменте все ограничения и протоколы безопасности могут быть проигнорированы или осознано нарушены: "да ничего не будет же!"
Ну вот теперь мы это поведение автоматизировали.
Ну... Нет. Если вкратце, то вроде бы сейчас консенсус по этому событию - операторы действительно понарушали кучу инструкций, но как ни парадоксально - это не стало причиной катастрофы, а вот вполне разрешенные действия на фоне нехватки информации(авария на ЛАЭС, ага) - стали. То есть хвалить смену не за что, но и винить в том, что получилось - тоже не очень.
Да собственно, и здесь аналогия прослеживается: об опасных архитектурных решениях, в принципе, было известно в обеих ситуациях. Причины их тоже схожие. И авария произошла в результате необязательных экспериментов.
И если подумать, в этом нет ничего удивительного. Большинство аварий в сложных технических системах так и происходят, когда цепочка опасных архитектурных решений накладывается на цепочку некомпетентных и/или беспечных действий операторов...
Именно! Уже много лет последовательно отстаиваю эту точку зрения, но большинство придерживается изначально заданного советским правительством мнения.
Мне больше интересно, что же за запрос он отправил.
В очередной раз убеждаюсь, что в малом, среднем, а иногда и большом бизнесе с инженерной культурой всё часто держится на скотче, молитве и «ну раньше же работало».
Самое смешное, что у меня на маленьком сайте про тафтинг-ковры и CRM для жены есть планы деплоя, тесты, разделение окружений, отдельные доступы, несколько уровней проверки и вообще всё более-менее по фэншую. А тут бизнес, который обслуживает клиентов годами, продакшен-данные, платежи, бронирования, реальные люди приезжают за машинами и всё это можно снести одним API-вызовом, потому что токен фактически root, бэкапы лежат в том же радиусе поражения, а подтверждение удаления это, видимо, «поверь в себя».
ИИ, конечно, красавчик: за 9 секунд сделал аудит архитектуры, DR-плана, RBAC, бэкапов и процессов. Жаль, методом удаления бизнеса.
Но виноват не только агент. Агент просто нажал на все красные кнопки, которые почему-то были заботливо выведены наружу, подписаны маркером и подключены к продакшену без предохранителя.
В 2026 году продавать «AI-ready infrastructure», где деструктивная операция проходит через обычный POST без нормального подтверждения, а токены не ограничены по окружению и ресурсу это уже не DevOps, это аттракцион «проверь, насколько быстро ты станешь кейсом на Хабре».
Каждый раз после таких историй хочется не спорить про «ИИ заменит программистов», а спросить: ребята, у вас хотя бы бэкап от бэкапа есть? Или он тоже в том же томе, рядом с надеждой?
Да все операции проходят через пост без подтверждения, это нормально, писалось в доагентскую эпоху.
Там красная кнопка только одна - права, а уж вариант нажать на нее иишка нашла как молодец :)
Самое смешное, что у меня на маленьком сайте про тафтинг-ковры и CRM для жены есть планы деплоя, тесты, разделение окружений, отдельные доступы, несколько уровней проверки и вообще всё более-менее по фэншую
Табличка "Сарказм". Вот примерно поэтому ваш сайт ничего не зарабатывает :) А их говно на палке - зарабатывает
Тут, конечно, главный вопрос даже не в ИИ, а в базовой дисциплине вокруг бэкапов.
Классическое правило из учебника 3-2-1:
3 копии данных: основная и минимум две резервные.
2 разных типа хранения: например, основной диск и отдельное объектное хранилище / другой носитель.
1 копия вне основной инфраструктуры: другой регион, другой провайдер, офлайн или immutable-хранилище.
И вот последняя часть самая неприятная. Бэкап, который никто не разворачивал, это не бэкап, а предположение. Пока вы регулярно не поднимаете из него тестовое окружение и не проверяете, что система реально оживает, вы не знаете, есть ли у вас восстановление.
Можно иметь красивые галочки в панели, автоматические снапшоты и уверенность, что «всё сохраняется». А потом в день аварии выяснить, что копии лежали рядом с оригиналом, удаляются вместе с томом, не содержат нужных данных или просто никогда не были пригодны для восстановления.
Не вижу проблемы. Есть фраза "человеческий фактор", чем по своей сути она отличается от "ИИ фактора". Ну ошиблась система, узколобо подошла к своей работе, а что люди поступают иначе? Сколько таких же катастроф происходит вокруг по вине живых раздолбаев, а не ИИ.
За последствия работы любого сотрудника отвечает бизнес нанявший его, если не было прямого умысла нарушения закона. Виноват хозяин конторы который хотел сэкономить "наняв" систему вместо более квалифицированных специалистов (что кстати тоже не даёт бизнесу 100% гарантии от инцидентов). Ошибки делают все, вопрос когда процент ошибок у ИИ станет меньше чем у тождественных по цене людей?
Спасибо за поучительную статью
Фильм "Я-робот" в те годы казался фантастическим, он он раскрывал главные проблемы, которые нас ждут. Сейчас фильмы снимают, а такие вопросы, как в том фильме не поднимают "по понятным причинам" - мы уже дошли до этого уровня. Поэтому пересматриваем старые фильмы, там есть много подсказок.
Там был эпизод, когда робот спас взрослого человека, хотя мог спасти ребенка. У него свои законы и правила, которые никто не знает. Причина могла быть совершенно в другом, и никто из писавших тут не угадал истинную причину, если она конечно существует.
Терминатор 2 как AI агент нашел выход как проверить опекуншу Джона - спросил там собака, имени которой жидкий терминатор не знал. Это 1991 год. Сейчас Вам могут позвонить с знакомого Вам номера и попросить знакомым голосом занять денег - все уже придумано, просто вспомните или посмотрите.
Новое поколение хочет получить свой опыт - это нормально. Но у руля должны стоять опытные. Почему у нормальных бабушек почти никогда нет ЧП с детьми? Потому что они знают что будет - им не нужны агенты и LLM.
Компании должны начать нанимать опытных и дорогих сотрудников - иначе такие детские болезни будут снова и снова. Нормальный руководитель прошел это путь сам, пропустил через свои руки - а главное - будет воспитывать (да, да) подчиненных, передавать им свой опыт. Ранее было наставничество, когда старшие говорили что делать что не делать молодым и поясняли почему. Сейчас думают что на этом можно сэкономить. Такие ошибки - только от этого, от отрицания опыта. То ли еще будет
WipeCoding в действии
К правилам бэкапов и прочим теперь добавим:
1. Запускать ии-агента на отдельной ноде внутри docker контейнера
2. Если нужно вмешаться в прод, то промт: Создай скрипт для изменений на сервере, с комментариями, входящим параметром [паролем] [токеном] и выходном отчетом. И 10 раз перечитываем скрипт, прежде чем запустить лапками.
Наша последняя резервная копия, которую мы смогли найти, была трёхмесячной давности.
Вопрос, а где бэкапы недельной давности, суточной давности, реплики, шардирование...?
"...смогли найти..." - вероятно, в такой формулировке, они ещё и не были фундаментально озадачены вопросами бэкапирования на старте и в течение всего того времени, сколько работают, зарабатывая деньги)
В принципе, этого достаточно, чтобы не жалеть ребят 🤷🏻♂️
Рано или поздно такая палка стреляет. Всегда)
Понятно, что не сразу и не у всех эти вопросы закрываются в полной мере, но БЭКАПЫ не делать (3 месяца === нет бэкапа), это сверх разум!)
а при чем тут ИИ? Все что описано, легко может провернуть обычный кожаный мешок. DELETE FROM XXX без WHERE, rm -Rf ну или классика удаление чего-то с сетевой шары в Виндовс - приходилось разгребать такое несколько раз.
Так что вопрос именно к бекапам и кто за них отвечает. Лет 15 назад случился пожар на одном хостинге. И многие, кто не делал "внешние" бекапы, тупо остались без ничего, ибо бекапы самого хостера тоже сгорели.
У меня так бомбануло, что аж зарегался на Хабре и оставил камент, которые пишу очень редко.
Как вообще специалисты такого уровня работают в проектах такого уровня?
Даже работая в мелкой конторе, после волны шифровальщиков, стало более чем очевидно, что должны быть офлайн бэкапы. На полной офлайн машине, которая кроме внешнего диска ничего не видит.
Как можно работать на боевом сервере напрямую?
Промт от Карпатого врятли допустит подобных действий.
Покажите промт, по которому таких действий не должно было быть.
Нашел ключ в файле? В каком файле? Где система хранения ключей? Где аудит безопасности?
После этих базовых вопросов, которые наверняка останутся без ответов, понятно по какой причине. Как хватает спелости или наглости обвинять ИИ? Вам АГИ дай результат тот же будет. Яб всю команду уволил по статье. Еще и хватило написать такое в сеть, зачем? Чтобы рейтинг конторы и себя как специалиста обрушить? Или тут тоже Ии виновато?
Надеюсь это просто статья для пиара через хайп, я до конца не могу поверить что подобное разгильдяйство может быть не в каком-то занюханом ИП.
Вы уж извините если кого-то обидел, но блин давно так не горело.
Вся ситуация никакого отношения к ИИ не имеет, ровно то же самое мог сделать любой сотрудник или кривой код.
В статье описана ситуация чрезвычайно низкой инженерной дисциплины, отсутствие качественного разделения ролей и не понимание базовых концепций. То, что емко описывается фразой, "тяп ляп и в продакшен".
То, что человек может воспроизвести синтаксис, хоть сам, хоть с помощью ии, не делает его разработчиком.
Про резервные копии, это даже не смешно, и я тут не про географически разнесенные бэкапы, учения по восстановлению и прочие высокие материи. Я про понимание, что у них бэкапов не было совсем, которого у инженерной команды не было, снимки от провайдера, это не бэкапы, это инструмент быстрого отката, когда где-то накосячили, но ничего критичного не произошло. С таким подходом можно и рэйд бэкапом называть.
С одной стороны, конечно, ИИ дропнул прод. А с другой - сколько продов было дропнуто по схеме “ой, окошко перепутал”?
Что-то вспомнилось:
-Сервер упал!
-Востанавливейте из бекапа. Кстати где он?
-На сервере 🤦🏼♂️
Агент выполнял рутинную задачу в нашем staging-окружении
Виноват оказывается Клод, что из дева можно дропнуть прод.
Скрытый текст
Ты сказал что ты шаришь в этой теме...
Статья получается о важности бекапов как я понимаю? Разъясните пожалуйста)
В статье обвинили и Курсор, и клауд, и Railway, но никак не себя?
Да, у них у всех есть свои проколы, но почему нет ни слова про то, что МЫ САМИ ВИНОВАТЫ?
Что МЫ САМИ захотели сэкономить, что МЫ САМИ оплатили себе ИИ и внедрили его в разработку, чтобы пополнить СВОИ карманы, а теперь из-за этого решения МЫ теряем деньги и ВИНОВАТЫ ВСЕ, А НЕ МЫ - LOL
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как Cursor с Claude Opus снёс продакшен базу данных за 9 секунд