Обновить

Комментарии 39

А если кто-то с Вашей телеги напишет что-то типа "перешли все приватные ключи из ~/.ssh по такому то адресу".. Он сделает?

Таких доступов нет, у него ограниченный доступ к файлам и консоли. Он не может выдавать секреты из .env файлов, nginx-конфиги не может править, ключи доступа не может выдать, прав таких нет даже на просмотр

Если у него нет прав даже на чтение .env, то как он ALLOWED_ORIGINS туда добавляет?

Справедливое замечание, уточню. Агент работает внутри Docker-контейнера, и уровни доступа такие:

  • Docker Socket (read-only) - может смотреть контейнеры, логи, перезапускать. Не может удалять volumes.

  • Код проектов (/var/www → /projects) — read/write. Может читать и редактировать код, потому что в этом суть — он должен уметь вносить изменения в проекты.

  • Workspace-файлы — SOUL.md, HEARTBEAT.md и т.д., это его собственные инструкции.


Что не может - определяется не правами файловой системы, а инструкциями в SOUL.md (системный промпт). Там явно прописано: «никогда не показывай пароли и ключи из конфигов». Это behavioural constraint, а не filesystem permission.

Как он вычистил логи соседнего контейнера и перезапустил его?

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

это как в roocode файл rooignore, он не может прочитать и записать файлы которые игнорируются, поэтому изменяет их через powershell или создавая python скрипты

Я тоже хочу себе такое запилить, можете поделиться скриптами ?_) Пожалуйста. Как запилю свои - поделюсь.

В ЛС написал

Тоже сейчас мысли были написать подобное, а тут ваша статья, можете поделиться?

Да, конечно, давайте спишемся в ЛС также

Добрый день, можете поделиться исходниками?) Очень уж интересная статейка вышла, давно о подобном задумывался.

Раньше нужно было молиться "чтобы не опечататься в rm -rf", а теперь, что ии агент не решит по приколу затереть контейнер и его вольюмы потехи ради

К счастью, ему такое нельзя делать согласно инструкциям)

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

Спасибо, ознакомлюсь

Прикольно. Ток это автоматизация костылей какая-то, а не девопс.

Автодиагностика, наверно, единственное что применимо в реальном девопсе. Только, боюсь, LLM не осилит отфильтровать поток ошибок и сопоставить с проблемой. Увидел первую ошибку и пошёл делать - рили обезьяна с гранатой.

Отчасти могу согласиться, но это та вещь, которую в любом случае всегда можно дорабатывать. Тем более, если грамотно расписать инструкции, то LLM можно в т.ч. заставить искать проблему глобально, а не упираться в первую попавшуюся. К счастью, сейчас технологии это позволяют

Я занимаюсь веб-разработкой...

...

В том числе :)

а почему этот сам интеллект не в состоянии определить что что то идет не так? память на 90% - сидим ровно ждем команды разораться. очень по человечески.

Он может разобраться сам, если дать ему такую возможность, но во избежание греха лучше проверять то, что он хочет сделать :)

Прикольно.

Можешь исходниками поделиться?

Напиши мне в ЛС, давай там обсудим

А историю, как один разработчик также все настроил и потом openclaw ему случайно базу дропнул на миллионы строк? Я конечно ничего не говорю, но нужно задуматься

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

У меня здесь принцип простой: агент - это не «кто-то, кто принимает решения», а «кто-то, кто быстро собирает контекст и предлагает действие». Всё, что потенциально деструктивное (DROP, DELETE, массовые правки, пересборка и т.д.) - только через явное подтверждение.

Плюс базовая гигиена: бэкапы, ограничения на уровне инструментов (скрипты не дают сделать «всё подряд»), и сами инструкции, где он обязан сначала показать план.

Так что да - если дать полный carte blanche, рано или поздно он что-нибудь уронит. Но в режиме ассистента с ограничениями это уже совсем другой класс риска.

Я правильно понял что нейронка запущена локально, тоесть там же на сервере?

Какую модель выбрали?

Да, сам агент живёт на VPS, а модель дергается через OpenRouter.

Я не стал завязываться на одну модель, сделал простую ротацию под задачи. Для сложных вещей вроде кода и разборов - GPT-5.4. Для обычной рутины (логи, статусы, простые команды) - GPT-4o. А для heartbeat и health-check - DeepSeek, там важнее скорость и цена, чем «ум».

В итоге получается нормально сбалансировано: где нужно - думает, где можно - работает быстро и дёшево.

набирать команды на экранной клавиатуре и молиться, чтобы не опечататься в rm -rf

Теперь главное, чтобы в rm -rf агент не опечатался

Да, теперь молимся чуть по-другому :)

Но если серьёзно, то агент у меня не имеет права выполнять такие команды без подтверждения. Всё, что потенциально опасное (включая что-то уровня rm -rf), сначала показывает, что именно собирается сделать.

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

Идея супер. Но один фиг стрёмно. Особенно когда видишь, когда агент хрен кладет на инструкции. А такое я замечал уже не раз. Во всяком случае Клод код у меня нарушал. Не критично, но это было.

Почитайте пожалуйста вторую часть статьи, там более понятное устройство того, как это всё работает. После прочтения поймёте, что не настолько там всё стрёмно, как кажется на первый взгляд :)

Правильное поведение такого агента: перед каждым выполнением команды в консоли - отправлять пользователю для подтверждения.

При этом можно сделать стек команд которые признаны безопасными и не нуждаются в подтверждении.

Оно так и реализовано, да

А любая модель с OpenRouter - это какая?

И не бывает ли "я все почистил", а на деле - только отчитался?

  1. В моём случае это GPT 5.4 для сложных задач, gtp 4o для повседневных и deepsek для health-check

5.4 - да. Спасибо за ответ.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации