Дал агенту доступ к проду через MCP, он почистил мне базу. Разбор факапа

[tastee]

Рассказываю как есть, чтобы вы так не делали. У меня небольшой сервис на pet-проекте, который внезапно стал приносить деньги, около 60 заказов в день. Стек django + postgres, деплой на VPS за 900р в месяц.

Подключил к Claude Code postgres MCP сервер, чтобы агент сам смотрел схему и данные при отладке. Удобно было до жути. В пятницу попросил: почисти тестовые заказы из orders, они с пометкой test в comment. Агент написал DELETE, сам его выполнил и радостно отчитался: удалено 4120 строк. Тестовых заказов у меня было штук 300.

Дальше веселее. Коннект в конфиге MCP был продовый, я был уверен что там стейджинг. А бэкап... бэкап у меня pg_dump по крону на тот же сервер, и последний нормальный был недельной давности, потому что диск забился и крон молча падал.

Итог: потерял заказы за 6 дней. Часть восстановил из логов приложения и выгрузки платежки, убил на это выходные. Клиентам писал извинения руками.

Выводы для себя: отдельный read-only юзер для любых MCP к базе, бэкапы на другой сервер с алертом на фейл, агенту прод не показывать вообще. Можете кидать помидоры, но лучше расскажите, как у вас это огорожено.

[envoy69]

классика жанра. агент тут не виноват вообще, ты сам отдал боевой коннект инструменту, который генерит SQL и сам же его исполняет. это как дать стажеру рута в пятницу вечером и уйти в бар

[KubeSmith]

бэкап у меня pg_dump по крону на тот же сервер

вот это главная ошибка, а не MCP. бэкап на том же диске это не бэкап, а файлик рядом. restic + s3-совместимое хранилище, у таймвеба или селектела стоит копейки, рублей 150 в месяц за твои объемы. и обязательно проверка восстановления хотя бы раз в месяц, иначе узнаешь что бэкапы битые ровно в тот день, когда они понадобятся. агента можно вообще убрать из этой истории, рукожопный delete от живого человека дал бы тот же эффект.

[nilcetinkaya]

По теме MCP: у официального postgres сервера есть read-only режим, включается одним флагом. Но я ему не доверяю и сделал тупее: завел в базе юзера agent_ro, у которого только SELECT, и он зашит в коннект MCP. Агент физически не может ничего удалить, хоть ты его упрашивай. На запись он мне генерит миграцию файликом, дальше сам. Неудобств почти ноль.

[trasche10]

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

[leewardms]

@nilcetinkaya, вот поэтому я считаю, что агентские доступы к живым базам это дичь по определению. агент должен генерить SQL текстом, человек смотрит глазами и запускает руками. экономия полторы минуты, а истории потом вот такие

[postgres2]

человек смотрит глазами и запускает руками

это работает первые две недели. потом ты жмешь выполнить не глядя, потому что 50 предыдущих раз все было нормально. человеческое ревью рутинных запросов выгорает очень быстро, проверено на себе. рабочая защита это не ритуал с глазами, а права: ro юзер как в посте 4, прод вообще не подключен, деструктив только через миграции с ревью в гите. тогда и смотреть не надо, ломать нечем.

[ucronk]

@leewardms, короче, сделал так: agent_ro с одним SELECT, бэкапы переехали на s3 в селектел с алертом в телегу, прод из конфига MCP выпилил совсем, агент видит только стейдж с обезличенной копией.

по поводу логов из поста 5: да, каюсь, debug-логирование тел запросов было включено еще со времен отладки. выключил и почистил, не сыпьте соль)