я сделал скилл, который заставит агента сам проверять новый скилл
Читать. Скиллы надо чи-тать. Самому. Т.е. совсем-совсем самому, лично, глазками, без помощи агента. До установки. И до обновления скилла на новую версию смотреть diff.
А прогнать SkillSpector стоит перед тем, как читать.
Агент, который имеет возможность изменять код и запускать тесты - имеет возможность делать абсолютно что угодно (просто добавив временный код в тест и запустив тесты разрешённой командой). А агент который таких возможностей не имеет - бесполезен. Поэтому единственный рабочий способ что-либо агенту запретить - запустить его в песочнице/виртуалке где запрещённое действие выполнить не может никто, включая Вас.
Видимо, не все верно понял, но пока кажется, что и скрытые от гита файлы, которые обсуждали парой сообщений выше, должны синхронизироваться.
Синхронизируются конфиги вроде ~/.bashrc и ~/.config/git/. Пример списка в репо тут. Каталог с проектами/репо у агента полностью собственный, в нём не синхронизируется ничего, только через git push/pull.
Смотрели ли в эту сторону?
А что туда смотреть, у меня это всё штатно работает. Я же говорю, по UX работа в песочнице ничем от работы на хосте не отличается. У меня в песочнице открыто несколько терминалов, можно прямо в них запускать GUI приложения вроде VS Code/Cursor и они штатно работают прямо на Wayland хоста, видят в прокинутых конфигах текущую тему DE, имеют доступ к /etc и /usr хоста, etc. Можно запускать их не в терминалах а хоть прямо из менюшки DE - только нужно вызов нужного приложения обернуть через скрипт sandbox-а (примерно в том же духе, как работает firejail etc.).
Вообще это вполне ожидаемая реакция на встраивание в приложения жёсткого шпионажа за пользователями. Скорее всего постепенно выпилят вообще все приложения, куда добавили "детекторы VPN".
Меня в первую очередь пугает неожиданное изменение системных файлов или пресловутый rm rf
У меня в репо в README выложен rationale и модель угроз, почитайте, возможно передумаете. Если вкратце, то на сегодня в принципе нет защиты от атак prompt injection и supply chain - нет и даже не предвидится. Это значит что любой агент в любой момент становится вредоносным. Учитывая отсутствие защиты и популярность этой темы (выраженную например в проценте вредоносных навыков для openclaw - я видел цифры порядка 60% если не путаю) полагаться на то, что это не случится лично с нами - довольно наивно. Поэтому, на мой взгляд, Вы не того опасаетесь.
Clone mode, насколько это близко вашему подходу и реализации?
В плане того, чтобы не шарить с агентом рабочий каталог - да, по описанию очень похоже. Упомянутую мной дырищу это должно закрыть, так что рекомендую его использовать. А вот удобство работы в отдельной VM всегда будет сильно хуже, чем в привычной среде на хосте - и моё решение умудряется совместить безопасность и это удобство, чем и уникально. :)
Что касается настроенной IDE хоста, улавливаю некое противоречие, наличие отдельной копии для агента неизбежно ухудшает скорость синхронизации, в случае с подключение по SSH к среде разработки в локальной песочнице да, этот момент решается, хоть и сложнее настраивать окружение.
У меня там два варианта. На базе Linux namespaces синхронизация обеспечивается через ro bind-mount этих конфигов, что моментально. На базе ssh на localhost синхронизация пока сделана через rsync при запуске, в целом работает прекрасно, но есть и другие варианты на будущее. Но синхронизация конфигов это половина дела, ещё нужно открывать ссылки в браузере хоста, сохранять look&feel DE хоста для GUI приложений, показывать десктопные уведомления на хосте, проигрывать звуковые уведомления, etc. В целом у меня всё получилось - работа в песочнице никак не ощущается отличной от работы на хосте в плане UX.
А вот насчет шарить окружение категорически не согласен, все переменные окружение, доступные агенту, потенциально под угрозой.
Я под окружением имел в виду утилиты и их конфиги, начиная с zsh и заканчивая VS Code, а вовсе не переменные окружения.
К слову говоря, у меня там довольно сильно проработана защита от случайных утечек секретов - grep/ps/env никаких секретов никогда не возвращают. Специально, конечно, все доступные агенту секреты получить можно без проблем запустив secret-tool - но тут уже срабатывает фактор что все доступные агенту секреты были созданы специально для него, так что никакого "лишнего" доступа они не дадут.
Расскажите, а как у вас дела с Docker контейнерами? Доступно ли внутри песочницы изолированное ядро для запуска контейнеров?
Докер доступен, но ядро ОС общее - защита от эксплойта ядра автоматом требует (micro)VM, а VM автоматом убивает UX, так что я сделал выбор в пользу UX.
При использовании варианта ssh используется rootless docker под юзером ai-dev, в варианте на namespaces запускается rootful docker но внутри того же userns что и вся песочница, так что получение там рута никаких дополнительных прав снаружи песочницы не даёт.
У подхода Docker Sandbox есть серьёзный недостаток в плане безопасности: из такой песочницы элементарно сбежать на хост. Поскольку рабочий каталог с проектом шарится с хостом, то агент может подложить в каталог проекта малозаметные файлы, которые приведут к выполнению кода на хосте: git hooks, .mise.local.toml, direnv, etc. - есть тьма инструментов, которые "для удобства" выполняют код из файлов проекта, и зачастую изменения в таких файлах git diff не показывает. Так что идея делать git commit/push на хосте - это как раз уязвимость (из-за хуков), а не усиление безопасности.
На мой взгляд категорически неприемлемо шарить каталог проекта с агентом. Агент должен работать как отдельный сотрудник, с собственным клоном репо проекта, в собственном домашнем каталоге, имея доступ только к разрешённым для него секретам. И обмениваться с ним кодом можно только через git push/pull - это исключает атаки через все вышеупомянутые "невидимые" файлы.
Ещё один важный нюанс: если не вайб-кодить, то не получится ограничиться работой только внутри claude - изменения нужно ревьювить, допиливать, а для этого нужно иметь доступ к уже настроенному и удобному окружения хоста (IDE с кучей утилит и их конфигов).
В результате, более правильный подход к безопасной работе с агентами, на мой взгляд, совершенно противоположный подходу Docker Sandbox/Dev Container/виртуалок: с изолированной средой нужно шарить не каталог проекта, а настроенное окружение хоста (рабочие инструменты).
Пример реализации этого подхода (даже два варианта - один на базе ssh ai-dev@localhost а второй на базе linux namespaces) я выложил в https://github.com/powerman/sandbox-ai-dev. К сожалению, утилиту для упрощения установки я пока не реализовал, плюс поддерживается только Linux (впрочем, вариант на базе ssh в теории можно адаптировать для macOS).
Главная проблема $mol в его авторе, точнее в его стиле коммуникации, отпугивающем большинство потенциальных новых пользователей. А у текущей статьи - в слишком высоком уровне абстракции, она не про конкретно $mol, а про любой новый фреймворк. Про особенности $mol там одна картинка про закрытые на уровне архитектуры баги, но вот как раз эту тему статья и не раскрывает.
Ну, пример с TLSMode несколько натянутый, спорить не буду. Идея была в том, что в этом кейсе значение (true/false) по умолчанию может быть любым (напр. зависящим от каких-то других факторов), поэтому его требовалось явно отделить от форсированного пользователем true/false.
А что не так с bool? Если значение по умолчанию это false, то всё работает само собой. Если значение по умолчанию это true, то да, становится неудобно, но это решается переименованием поля так, чтобы изменить смысл на обратный и значением по умолчанию стал false.
А как Вы заставите коллег не писать плохой код руками? Точно так же и с вайб-кодерами.
Есть процесс ревью (людьми), есть история того, как коллега "игнорировал" замечания с прошлых ревью или документированные требования проекта/компании повторно совершая те же ошибки - и причина по которой он "пишет плохо и не обучается" совершенно не важна, как и используемые им инструменты.
Когда о необходимости регулирования начинают говорить аутсайдеры - им нужны понятные правила игры. А когда лидеры - им нужна возможность эти правила задавать для других.
Амодеи напоролся ровно на то, за что боролся. Он хотел регулирование - он его получил. Правда, он явно думал, что регулировать поставят его, и регулировать он будет конкурентов, но… не свезло.
Конечно же, настройки там есть, и их море. Да, сейчас оно уже из коробки без настроек работает, и весьма неплохо, но тот же MTP нужно включать ручками, и не только - тюнинг ещё штук 8 опций весьма значительно сказывается на производительности.
Чтобы упереться в 5-ти часовой лимит у меня уходит 1.5-2 часа на Opus - это примерно до 5 запросов, иногда успеваю одну задачу сделать, но далеко не всегда. Про Fable вообще говорить нечего - 3 запроса и привет лимит. Да, задачи у меня сложные, контекста относительно много набегает за одну такую сессию (под 200K), но эти модели и нужны для сложных вопросов, простые за копейки делает DeepSeek V4 Flash.
Если не ошибаюсь, разница DeepSeek V4 Flash и Sonnet не порядок - а два порядка. А разница в качестве, на глазок, процентов 15. Я из-за этого вообще перестал Sonnet использовать - на подписке Pro лимиты жёсткие, так что либо Opus/Fable для архитектурных вопросов, либо DeepSeek V4 Flash для "набрать код".
Та проблема, которую Вы описали - вполне реальна. Но это не единственное, что существует в этом мире, помимо этого есть и другое. Например, качество генерации LLM сильно зависит от того, кто с ней разговаривает и как он это делает.
Если попросить LLM "напиши статью на хабр про X" - наверняка будет мусор (хотя лично я не проверял, но вроде это очевидно). А вот если несколько часов общаться с LLM обсуждая сложный кейс, пройти в процессе несколько осознаний обоим участникам этого обсуждения, а потом попросить написать статью про этот кейс - качество результата будет принципиально на другом уровне. А если после этого вручную сделать серьёзную редактуру, то от собственноручно написанной статьи отличить станет сложно даже "автору". Если работать в таком стиле, то LLM из "автора нейрослопа" превращается в "очень быструю печатную машинку" - ровно та же ситуация, что и при написании кода, когда ты либо в браузерном чате просишь "напиши мне код для фичи X" либо тот же запрос отправляешь агенту, который имеет доступ к коду проекта, получил море контекста из AGENTS.md и обвешан скиллами "как делать X правильно". В первом случае будет фигня, во втором не всегда можно отличить код от собственного.
У меня это только терминалы. При запуске можно задать уникальный идентификатор/имя приложения/окна, по которому оно автоматически попадает на нужный виртуальный десктоп. Напр. foot --app-id=… и urxvt -name ….
Я в 2001 сделал свой дистрибутив на базе LFS и сидел на нём (вместе с несколькими друзьями) 2.5 года, потом ушёл на Gentoo, и с тех пор ни разу не переустанавливал ОС - зачем мне уходить с Gentoo? Чтобы каждые пару лет осваивать изменения в новой версии убунты? И нет, хакером я себя не считаю, я разработчик - просто мне для комфортной разработки нужна удобная, надёжная и безопасная среда. (С безопасностью стало хуже после того, как Gentoo Hardened умер, но до этого много лет радовала и она.)
У меня уже… хз сколько, больше 20 лет наверное всегда ровно 24 виртуальных десктопа, с переключением по Alt-Fx и Alt-Shift-Fx. В 23 из них одно приложение, открытое на весь экран, без рамки окна, запускаемое в заранее заданном виртуальном десктопе при запуске DE (в результате все эти годы одна комбинация всегда переносит меня в браузер или мессенджер или почту etc. - сами браузеры и мессенджеры за эти годы менялись, а вот какой кнопкой я в них переключаюсь - нет), а 24-й оставлен на случай если мне понадобятся редко запускаемые оконные приложения (gimp, steam, etc.). О! Я в 2007 на хабре про это уже писал: https://habr.com/ru/articles/13051/
Читать. Скиллы надо чи-тать. Самому. Т.е. совсем-совсем самому, лично, глазками, без помощи агента. До установки. И до обновления скилла на новую версию смотреть diff.
А прогнать
SkillSpectorстоит перед тем, как читать.Агент, который имеет возможность изменять код и запускать тесты - имеет возможность делать абсолютно что угодно (просто добавив временный код в тест и запустив тесты разрешённой командой). А агент который таких возможностей не имеет - бесполезен. Поэтому единственный рабочий способ что-либо агенту запретить - запустить его в песочнице/виртуалке где запрещённое действие выполнить не может никто, включая Вас.
Синхронизируются конфиги вроде
~/.bashrcи~/.config/git/. Пример списка в репо тут. Каталог с проектами/репо у агента полностью собственный, в нём не синхронизируется ничего, только через git push/pull.А что туда смотреть, у меня это всё штатно работает. Я же говорю, по UX работа в песочнице ничем от работы на хосте не отличается. У меня в песочнице открыто несколько терминалов, можно прямо в них запускать GUI приложения вроде VS Code/Cursor и они штатно работают прямо на Wayland хоста, видят в прокинутых конфигах текущую тему DE, имеют доступ к /etc и /usr хоста, etc. Можно запускать их не в терминалах а хоть прямо из менюшки DE - только нужно вызов нужного приложения обернуть через скрипт sandbox-а (примерно в том же духе, как работает firejail etc.).
Вообще это вполне ожидаемая реакция на встраивание в приложения жёсткого шпионажа за пользователями. Скорее всего постепенно выпилят вообще все приложения, куда добавили "детекторы VPN".
У меня в репо в README выложен rationale и модель угроз, почитайте, возможно передумаете. Если вкратце, то на сегодня в принципе нет защиты от атак prompt injection и supply chain - нет и даже не предвидится. Это значит что любой агент в любой момент становится вредоносным. Учитывая отсутствие защиты и популярность этой темы (выраженную например в проценте вредоносных навыков для openclaw - я видел цифры порядка 60% если не путаю) полагаться на то, что это не случится лично с нами - довольно наивно. Поэтому, на мой взгляд, Вы не того опасаетесь.
В плане того, чтобы не шарить с агентом рабочий каталог - да, по описанию очень похоже. Упомянутую мной дырищу это должно закрыть, так что рекомендую его использовать. А вот удобство работы в отдельной VM всегда будет сильно хуже, чем в привычной среде на хосте - и моё решение умудряется совместить безопасность и это удобство, чем и уникально. :)
У меня там два варианта. На базе Linux namespaces синхронизация обеспечивается через ro bind-mount этих конфигов, что моментально. На базе ssh на localhost синхронизация пока сделана через rsync при запуске, в целом работает прекрасно, но есть и другие варианты на будущее. Но синхронизация конфигов это половина дела, ещё нужно открывать ссылки в браузере хоста, сохранять look&feel DE хоста для GUI приложений, показывать десктопные уведомления на хосте, проигрывать звуковые уведомления, etc. В целом у меня всё получилось - работа в песочнице никак не ощущается отличной от работы на хосте в плане UX.
Я под окружением имел в виду утилиты и их конфиги, начиная с zsh и заканчивая VS Code, а вовсе не переменные окружения.
К слову говоря, у меня там довольно сильно проработана защита от случайных утечек секретов - grep/ps/env никаких секретов никогда не возвращают. Специально, конечно, все доступные агенту секреты получить можно без проблем запустив secret-tool - но тут уже срабатывает фактор что все доступные агенту секреты были созданы специально для него, так что никакого "лишнего" доступа они не дадут.
Докер доступен, но ядро ОС общее - защита от эксплойта ядра автоматом требует (micro)VM, а VM автоматом убивает UX, так что я сделал выбор в пользу UX.
При использовании варианта ssh используется rootless docker под юзером ai-dev, в варианте на namespaces запускается rootful docker но внутри того же userns что и вся песочница, так что получение там рута никаких дополнительных прав снаружи песочницы не даёт.
У подхода Docker Sandbox есть серьёзный недостаток в плане безопасности: из такой песочницы элементарно сбежать на хост. Поскольку рабочий каталог с проектом шарится с хостом, то агент может подложить в каталог проекта малозаметные файлы, которые приведут к выполнению кода на хосте: git hooks,
.mise.local.toml, direnv, etc. - есть тьма инструментов, которые "для удобства" выполняют код из файлов проекта, и зачастую изменения в таких файлахgit diffне показывает. Так что идея делать git commit/push на хосте - это как раз уязвимость (из-за хуков), а не усиление безопасности.На мой взгляд категорически неприемлемо шарить каталог проекта с агентом. Агент должен работать как отдельный сотрудник, с собственным клоном репо проекта, в собственном домашнем каталоге, имея доступ только к разрешённым для него секретам. И обмениваться с ним кодом можно только через git push/pull - это исключает атаки через все вышеупомянутые "невидимые" файлы.
Ещё один важный нюанс: если не вайб-кодить, то не получится ограничиться работой только внутри
claude- изменения нужно ревьювить, допиливать, а для этого нужно иметь доступ к уже настроенному и удобному окружения хоста (IDE с кучей утилит и их конфигов).В результате, более правильный подход к безопасной работе с агентами, на мой взгляд, совершенно противоположный подходу Docker Sandbox/Dev Container/виртуалок: с изолированной средой нужно шарить не каталог проекта, а настроенное окружение хоста (рабочие инструменты).
Пример реализации этого подхода (даже два варианта - один на базе
ssh ai-dev@localhostа второй на базе linux namespaces) я выложил в https://github.com/powerman/sandbox-ai-dev. К сожалению, утилиту для упрощения установки я пока не реализовал, плюс поддерживается только Linux (впрочем, вариант на базе ssh в теории можно адаптировать для macOS).И как у него качество по сравнению с CamScanner?
Главная проблема $mol в его авторе, точнее в его стиле коммуникации, отпугивающем большинство потенциальных новых пользователей. А у текущей статьи - в слишком высоком уровне абстракции, она не про конкретно $mol, а про любой новый фреймворк. Про особенности $mol там одна картинка про закрытые на уровне архитектуры баги, но вот как раз эту тему статья и не раскрывает.
Ну, пример с
TLSModeнесколько натянутый, спорить не буду. Идея была в том, что в этом кейсе значение (true/false) по умолчанию может быть любым (напр. зависящим от каких-то других факторов), поэтому его требовалось явно отделить от форсированного пользователем true/false.А что не так с
bool? Если значение по умолчанию этоfalse, то всё работает само собой. Если значение по умолчанию этоtrue, то да, становится неудобно, но это решается переименованием поля так, чтобы изменить смысл на обратный и значением по умолчанию сталfalse.А как Вы заставите коллег не писать плохой код руками? Точно так же и с вайб-кодерами.
Есть процесс ревью (людьми), есть история того, как коллега "игнорировал" замечания с прошлых ревью или документированные требования проекта/компании повторно совершая те же ошибки - и причина по которой он "пишет плохо и не обучается" совершенно не важна, как и используемые им инструменты.
Когда о необходимости регулирования начинают говорить аутсайдеры - им нужны понятные правила игры. А когда лидеры - им нужна возможность эти правила задавать для других.
Амодеи напоролся ровно на то, за что боролся. Он хотел регулирование - он его получил. Правда, он явно думал, что регулировать поставят его, и регулировать он будет конкурентов, но… не свезло.
Конечно же, настройки там есть, и их море. Да, сейчас оно уже из коробки без настроек работает, и весьма неплохо, но тот же MTP нужно включать ручками, и не только - тюнинг ещё штук 8 опций весьма значительно сказывается на производительности.
Чтобы упереться в 5-ти часовой лимит у меня уходит 1.5-2 часа на Opus - это примерно до 5 запросов, иногда успеваю одну задачу сделать, но далеко не всегда. Про Fable вообще говорить нечего - 3 запроса и привет лимит. Да, задачи у меня сложные, контекста относительно много набегает за одну такую сессию (под 200K), но эти модели и нужны для сложных вопросов, простые за копейки делает DeepSeek V4 Flash.
Если не ошибаюсь, разница DeepSeek V4 Flash и Sonnet не порядок - а два порядка. А разница в качестве, на глазок, процентов 15. Я из-за этого вообще перестал Sonnet использовать - на подписке Pro лимиты жёсткие, так что либо Opus/Fable для архитектурных вопросов, либо DeepSeek V4 Flash для "набрать код".
Та проблема, которую Вы описали - вполне реальна. Но это не единственное, что существует в этом мире, помимо этого есть и другое. Например, качество генерации LLM сильно зависит от того, кто с ней разговаривает и как он это делает.
Если попросить LLM "напиши статью на хабр про X" - наверняка будет мусор (хотя лично я не проверял, но вроде это очевидно). А вот если несколько часов общаться с LLM обсуждая сложный кейс, пройти в процессе несколько осознаний обоим участникам этого обсуждения, а потом попросить написать статью про этот кейс - качество результата будет принципиально на другом уровне. А если после этого вручную сделать серьёзную редактуру, то от собственноручно написанной статьи отличить станет сложно даже "автору". Если работать в таком стиле, то LLM из "автора нейрослопа" превращается в "очень быструю печатную машинку" - ровно та же ситуация, что и при написании кода, когда ты либо в браузерном чате просишь "напиши мне код для фичи X" либо тот же запрос отправляешь агенту, который имеет доступ к коду проекта, получил море контекста из AGENTS.md и обвешан скиллами "как делать X правильно". В первом случае будет фигня, во втором не всегда можно отличить код от собственного.
У меня это только терминалы. При запуске можно задать уникальный идентификатор/имя приложения/окна, по которому оно автоматически попадает на нужный виртуальный десктоп. Напр.
foot --app-id=…иurxvt -name ….Я в 2001 сделал свой дистрибутив на базе LFS и сидел на нём (вместе с несколькими друзьями) 2.5 года, потом ушёл на Gentoo, и с тех пор ни разу не переустанавливал ОС - зачем мне уходить с Gentoo? Чтобы каждые пару лет осваивать изменения в новой версии убунты? И нет, хакером я себя не считаю, я разработчик - просто мне для комфортной разработки нужна удобная, надёжная и безопасная среда. (С безопасностью стало хуже после того, как Gentoo Hardened умер, но до этого много лет радовала и она.)
У меня уже… хз сколько, больше 20 лет наверное всегда ровно 24 виртуальных десктопа, с переключением по Alt-Fx и Alt-Shift-Fx. В 23 из них одно приложение, открытое на весь экран, без рамки окна, запускаемое в заранее заданном виртуальном десктопе при запуске DE (в результате все эти годы одна комбинация всегда переносит меня в браузер или мессенджер или почту etc. - сами браузеры и мессенджеры за эти годы менялись, а вот какой кнопкой я в них переключаюсь - нет), а 24-й оставлен на случай если мне понадобятся редко запускаемые оконные приложения (gimp, steam, etc.). О! Я в 2007 на хабре про это уже писал: https://habr.com/ru/articles/13051/