Я более чем уверен что в 2026м году если действительно постараться - можно разослать сообщения хоть всем абонентам одновременно. Просто стараться невыгодно.
Вы эту проксю перед базой никак не поставите, а если она не стоит сразу перед базой - то код между проксёй и базой всегда может интерпретировать отсутствие пользователя как повод разрушить мир.
Вот вам псевдокод:
@route("...")
function deleteUserByName(name) {
// здесь прокся уже проверила что доступ есть,
// лимиты не превышены и вообще всё замечательно
let userId = findUserByName(name);
deleteUserById(userId);
}
Автор кода думает, что findUserByName возвращает null если пользователя нет, а deleteUserById(null) - это no op. На самом деле findUserByName возвращает undefined и deleteUserById(undefined) дропает базу.
От этого никакая прокся не защищает, единственная защита - не писать такого кода, и следить чтобы ИИ тоже его не написал.
Я бы вас понял, если бы вы отвечали на статью комментарием верхнего уровня. Но вы-то отвечали не на статью, а на мой комментарий, где я написал что там произошло на самом деле.
В обсуждаемом случае речь идёт о “простом” баге в коде, то есть ожидаемое поведение как код должен работать было корректным, а налажал исключительно ИИ в реализации (а перед этим - он же в архитектуре).
Более того, было же сообщение о модели, которая, получив от инструмента file ошибку о невозможности удалить файл за пределами workspace, не долго думая повторила попытку через инструмент shell.
То есть эта самая эскалация привелегий работает у ИИ автоматически.
Не уверен что есть готовые решения, которые разрешают удалять не более N строк из БД в сутки исполняя запрос delete без where, а без этого любые рейтлимиты будут половинчатым решением.
Ну, если стартап занимался чем-то полезным, то клиенты ещё раз подпишутся, невелика беда. А если клиентам услуги нафиг не нужны и подписки оставались активными исключительно из-за тёмных паттернов - то туда стартапу и дорога
Это “API” называется SQL, с добрым утром. Там всё ровно так как вы сказали: забыл написать where в запросе - и получи удаление всех данных, к тому же каскадное.
Вам не нужно “делать” эту функцию намеренно, она идёт из коробки в любой ORM кроме самых бесполезных. Достаточно допустить ошибку в коде которая эту функцию случайно активирует.
Я более чем уверен что в 2026м году если действительно постараться - можно разослать сообщения хоть всем абонентам одновременно. Просто стараться невыгодно.
Потому что кому-то надо эту джобу написать, а программистов в штате нет, только вайб-кодеры.
Но если поменять ситуацию на обратную - лучше не станет, вот я к чему.
Китайская комната - это модель человеческого мышления. Наши нейроны в мозгу тоже передают друг другу сигналы по очень-очень сложным правилам.
Нет никакой разницы если в стартапе нет ни одного программиста
Ну так я сразу и написал же, что ревью таки требуется. А вы спорить начали.
Без ревью ничего путного из затеи с проксёй не выйдет, с этим вы согласны?
Вы эту проксю перед базой никак не поставите, а если она не стоит сразу перед базой - то код между проксёй и базой всегда может интерпретировать отсутствие пользователя как повод разрушить мир.
Вот вам псевдокод:
Автор кода думает, что findUserByName возвращает null если пользователя нет, а deleteUserById(null) - это no op. На самом деле findUserByName возвращает undefined и deleteUserById(undefined) дропает базу.
От этого никакая прокся не защищает, единственная защита - не писать такого кода, и следить чтобы ИИ тоже его не написал.
ИИ не нажимал кнопку, он её только создал. Кнопка нажалась по расписанию.
Это работает для, собственно, запросов. Но обсуждаемая проблема была вызвана ошибкой в коде.
Ну, базовый safety check уже был в библиотеке, но ИИ его выключил :-)
Я бы вас понял, если бы вы отвечали на статью комментарием верхнего уровня. Но вы-то отвечали не на статью, а на мой комментарий, где я написал что там произошло на самом деле.
Почему вы отвечаете на комментарии не читая их?
Потому что блокировать сайты можно через dns, по ip и через dpi. У разных видов блокировки - разные симптомы и разные способы обхода.
Вы вообще читаете комментарии, или только пишете?
Нет, мутации инициировала не ллмка. Соответственно, все защиты от мутаций со стороны ллмки тут никак бы не спасли.
Ну, он довольно храбрый человек. Однако в данном случае проблема была не в слишком больших правах агента
В обсуждаемом случае речь идёт о “простом” баге в коде, то есть ожидаемое поведение как код должен работать было корректным, а налажал исключительно ИИ в реализации (а перед этим - он же в архитектуре).
Более того, было же сообщение о модели, которая, получив от инструмента file ошибку о невозможности удалить файл за пределами workspace, не долго думая повторила попытку через инструмент shell.
То есть эта самая эскалация привелегий работает у ИИ автоматически.
Не уверен что есть готовые решения, которые разрешают удалять не более N строк из БД в сутки исполняя запрос delete без where, а без этого любые рейтлимиты будут половинчатым решением.
В данном случае, бот - и есть “гамнакодер”
Ну, если стартап занимался чем-то полезным, то клиенты ещё раз подпишутся, невелика беда. А если клиентам услуги нафиг не нужны и подписки оставались активными исключительно из-за тёмных паттернов - то туда стартапу и дорога
Хуже если там ещё и рефанды были сделаны.
Это “API” называется SQL, с добрым утром. Там всё ровно так как вы сказали: забыл написать where в запросе - и получи удаление всех данных, к тому же каскадное.
Вам не нужно “делать” эту функцию намеренно, она идёт из коробки в любой ORM кроме самых бесполезных. Достаточно допустить ошибку в коде которая эту функцию случайно активирует.