Сначала радиус поражения: семь рамок, прежде чем пустить ИИ на свои серверы

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Истории о том, как ИИ-агент «натворил дел» на сервере, похожи одна на другую. Модель не злая, она уверенная. Сделать её безошибочной нельзя, а решить заранее, во что обойдётся её ошибка, можно.

В обсуждениях «ИИ снёс мне прод» сюжет почти всегда один. Агент почистил каталог, который оказался каталогом с данными. «Починил» конфиг, просто заменив его. Прогнал миграцию на боевой базе, потому что нашёл именно эту строку подключения.

Злого умысла там нет — есть уверенность. И вопрос «насколько умна модель» здесь второстепенный. Главный вопрос другой: что худшее она может сделать с теми правами, которые вы ей дали? Это и есть радиус поражения, и задаётся он задолго до первого запроса.

У меня был свой такой случай. Local Commander я разрабатываю вместе с несколькими ИИ-агентами: каждый работает в своей копии репозитория (git worktree), а папка node_modules у всех копий общая, через ссылку. В начале октября агент убирал за собой отработанные копии. Ссылка не отцепилась, агент этого не заметил, и git worktree remove на пару минут опустошил node_modules основного проекта. Обошлось одной командой npm ci из lock-файла — потому что откат был дешёвым заранее. После этого в правилах для агентов появилось: удалять только обычным git worktree remove без force, ссылки отцеплять отдельно и проверять состояние прямо перед удалением.

Через три дня — второй случай. Другой агент при слиянии веток молча затёр исправления безопасности из соседнего пулреквеста. Заметили по диффу и вернули трёхсторонним слиянием. Ещё один довод за пятый пункт ниже: изменения должны проходить через то, что можно прочитать.

1. Минимальные права на каждой машине

  • Отдельный пользователь без root на каждом сервере. Им пользуется только агент.

  • sudo только для конкретных команд: systemctl restart myapp, а не ALL.

  • В базу данных — под ролью, которая читает всё, а пишет только туда, куда вы разрешили.

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

2. Никаких новых дверей

Не открывайте порт ради того, чтобы до сервера дотянулся ИИ. Ходите через Tailscale или WireGuard, либо берите инструмент, где сервер сам подключается наружу. Любой новый открытый порт найдут сканеры, даже если сам ИИ им так и не воспользуется.

3. Неделя «только смотреть»

Первую неделю агент читает и объясняет, но ничего не меняет. Так вы дёшево узнаёте, как часто он неправильно понимает вашу систему.

4. Сначала откат, потом действие

  • Снимки виртуальных машин и датасетов перед любым изменением.

  • Резервные копии там, куда агент не дотянется: другой пользователь, другой хост или хранилище только на дозапись.

  • Хотя бы раз проверьте восстановление. Непроверенная копия — это надежда, а не копия.

5. Изменения — через то, что можно прочитать

Всё, что повторяется, ИИ оформляет скриптом или плейбуком Ansible. Вы читаете, коммитите и запускаете сами. Чат хорош для разбора и разовых действий. Перед каждым разовым действием — вопрос: «что это изменит и как это откатить?»

6. Знать, что произошло

Ведите журнал: что запускалось, на какой машине и чем закончилось. История команд отдельного пользователя — уже неплохое начало. Цель — ответить на вопрос «что он делал в два часа ночи» без догадок.

7. Кнопка «стоп»

Нужна возможность за секунды отменить запущенную задачу и отключить машину, в том числе с телефона, если вы не за столом.

Где здесь мой инструмент и в чём компромисс

Я делаю Local Commander, так что я пристрастен. Он закрывает часть пунктов: агент на каждом компьютере сам подключается наружу (порт открывать не нужно), права задаются отдельно для каждой машины — вся учётная запись или выбранные папки. Есть запрет команд, журнал всех запросов с результатом, отмена и отключение машины откуда угодно. Если связь пропала посреди задачи, её не перезапустят наугад — она подождёт вас.

Честный компромисс для тех, кто держит всё у себя: ретранслятор у нас облачный. Команды и их результаты проходят через наш сервис по пути к вашему ИИ-приложению. Если ваше правило — «ничего не выходит за пределы моей сети», это не ваш вариант. Тогда лучше MCP-сервер через SSH, который вы поднимете сами, с теми же рамками. Открытая версия работает локально и без аккаунта, но только для одного компьютера и для настольных ИИ-клиентов.

Коротко

  1. Свой пользователь, минимум sudo.

  2. Никаких новых портов.

  3. Сначала только чтение.

  4. Снимки, копии вне досягаемости.

  5. Повторяющееся — скриптами, которые вы прочитали.

  6. Журнал того, что запускалось.

  7. Кнопка «стоп».

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

Подробнее о настройке: https://localcmd.app/control-multiple-computers-with-ai

Источник: https://habr.com/ru/articles/1098582/


Интересные статьи

Интересные статьи

Когда команда небольшая и все сидят в одном открытом пространстве, знания передаются почти сами собой — через разговор у кофемашины, ревью кода, общий чат. Пока команда маленькая, это терпимо, но как ...
Если вы внедряете «Битрикс24» не как игрушку для HR, а как полноценный инструмент управления процессами, вопрос интеграции возникнет сразу. Причем остро. Как ИТ-директор, вы должны понимать: может ли ...
Инженер и блогер Джеймс Доусон специализируется на обзорах одноплатных компьютеров, но сейчас он начал необычный марафон, а заодно решил подзаработать. Инженер купил на eBay партию пр...
Существует традиция, долго и дорого разрабатывать интернет-магазин. :-) Лакировать все детали, придумывать, внедрять и полировать «фишечки» и делать это все до открытия магазина.
В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes. Битрикс, Kubernetes, Сep...