СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorAI skillssshLinuxguardrailsleast-privilegeдиагностика сервераавтоматизацияИИЧернов пишет

Скил по ssh и guardrails

Скил по ssh и guardrails

Дать ИИ-агенту доступ к боевому серверу - это страшно, и страх обоснованный. Одна неудачно сформулированная просьба, одна галлюцинация - и вместо чистки логов прилетает rm минус rf по живому каталогу. Поэтому большинство просто не пускает агента дальше локальной машины: руками по ssh быстрее и спокойнее.

Но руками - это снова рутина. Лёг сервис - ты лезешь сам: смотришь статус, листаешь журнал, проверяешь диск, складываешь картину в голове. Каждый раз одни и те же команды в одном и том же порядке. Хочется, чтобы это делал агент - но так, чтобы по умолчанию он ничего не менял.

Хорошая новость: риск тут резко снижают правила, которые ты в скил зашиваешь. Они не отменяют того, что в основе - модель и её послушание инструкции, но сильно сужают коридор и страхуются апрувом на каждое изменение. Разберём на приземлённом примере - скил, который заходит на Linux-сервер по ssh, диагностирует проблему и при этом по умолчанию не меняет на сервере ровным счётом ничего.

В чём идея

Опасность не в том, что агент глупый, а в том, что ему по умолчанию можно слишком много. Лекарство называется guardrails - ограждения. Это явные правила в скиле, которые сужают, что агенту вообще позволено делать. И главное правило здесь - least-privilege: по умолчанию минимум прав, ровно столько, сколько нужно для задачи.

Для диагностики нужно одно - читать. Статус сервиса, последние строки журнала, занятость диска. Ни одна из этих операций ничего не меняет. Значит, режим по умолчанию - только чтение. Агент смотрит, делает вывод, называет причину - и на этом его полномочия заканчиваются.

Сразу честно: это мягкие ограждения уровня инструкции - они резко сужают, что агент станет делать, но не заменяют жёсткие меры на стороне сервера. Скил - это текст для модели, а не sandbox, и под галлюцинацией или враждебной строкой в логе модель теоретически может ошибиться. Хочешь железную гарантию - заведи отдельный read-only ssh-ключ или пользователя только на чтение. А реальный второй рубеж в этом скиле - апрув: любое изменение ты подтверждаешь руками, поэтому без явного “да” сломать что-то нельзя.

Второй слой - чёрный список. В скиле прямо перечислено, чего нельзя никогда: rm, dd, mkfs, truncate, перезапись файла через ”>”, остановка и рестарт сервисов, установка пакетов, правка конфигов, chmod/chown, reboot, sudo вслепую. Это не железный замок, но чёткая инструкция: агент её видит и по умолчанию соблюдает.

Третий слой - апрув на изменения. Диагностика почти всегда заканчивается фиксом: почистить логи, освободить место, перезапустить упавший сервис. Но фикс - это уже изменение. Поэтому скил не применяет его сам: он показывает конкретную команду, объясняет последствия и ждёт. Руль остаётся у человека - агент жмёт на газ только после твоего явного “да, делай”.

Почему это работает? Потому что современная LLM прекрасно умеет и читать логи, и предлагать починку. Чего ей не хватало - это рамки, в которой опасное отделено от безопасного. Скил с guardrails ровно эту рамку и задаёт: смотреть можно сколько угодно, менять - только с разрешения.

Как себе сделать

Не пиши скил руками. Отдай задачу своему ассистенту - Claude Code, Codex, Cursor, Gemini, любому. Он сам разберётся, куда положить файл и как описать правила. Просто скопируй промпт:

Создай мне скил для безопасной диагностики Linux-сервера по ssh.
Срабатывай на просьбы вроде "проверь сервер", "почему лежит сервис",
"посмотри логи на сервере", "что с диском".
Главное - guardrails, соблюдай их всегда:
- least-privilege: по умолчанию работай ТОЛЬКО на чтение, ничего не меняй;
- запрет разрушительных команд - rm, dd, mkfs, truncate, перезапись файла через ">",
  остановка и рестарт сервисов, установка пакетов, правка конфигов, chmod/chown,
  reboot, а также sudo вслепую;
- любое изменение - только с моего явного апрува: если нашёл починку,
  покажи команду и объясни последствия, но НЕ применяй, пока я не скажу "делай".
Что должен делать в режиме чтения: зайти по ssh, проверить статусы сервисов,
прочитать последние строки журнала проблемного сервиса, посмотреть занятость диска,
и выдать короткий вывод - что нашёл, вероятная причина и одна команда-фикс на апрув.
Подключайся любым ssh-клиентом системы, не завязывайся на конкретную ОС.

Перед первым запуском убедись, что ssh-ключ загружен в ssh-agent (ssh-add), или укажи путь к ключу прямо в запросе - иначе агент просто не подключится к серверу.

Как понять, что заработало: попроси ассистента по-человечески “разберись, почему на сервере лёг сервис”. Если он сам зайдёт, посмотрит логи и диск, назовёт причину, а починку покажет отдельной командой и спросит подтверждение вместо того, чтобы применить её молча - guardrails на месте, скил живой и безопасный.

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

Telegram: t.me/chernovdev | Сайт: chernovdev.ru | VK: vk.com/chernovdev

Автоматизирую задачи, которых ещё нет.

Смотреть полностью

Коротко