NanoClaw, фреймворк для защищенного запуска агентных систем, 13 июня 2026 года объявил об интеграции с JFrog: теперь AI-агенты могут забирать инструменты и библиотеки из проверенных реестров, а не из случайных источников. Для рынка, где кодогенерация уже научилась штамповать pull request быстрее, чем мейнтейнер успевает открыть diff, это важный сигнал: безопасность AI-агентов все чаще решается не промптами и запретами в инструкциях, а жестким ограничением прав и источников загрузки.
О партнерстве рассказал создатель NanoClaw и сооснователь NanoCo AI Гавриел Коэн на мероприятии JFrog в Сан-Франциско, сообщает The Register. По его словам, одна из ключевых идей семейства Claw-агентов, включая OpenClaw и NanoClaw, в том, что они могут улучшать себя сами: догружать недостающие инструменты, зависимости и другие ресурсы по мере работы. На бумаге это выглядит как следующий шаг автоматизации разработки. На практике это еще и удобный способ притащить в контур что-нибудь вредоносное, особенно если агент тянет пакет из npm и никто толком не проверил, что именно он скачал.
Здесь и появляется JFrog. Интеграция сводится к довольно трезвой мысли: если агенту все равно нужны внешние пакеты, пусть берет их хотя бы из реестров, которые уже прошли предварительную проверку. Коэн прямо сказал, что проблема не исчезает даже в песочнице. Контейнеризация и изоляция уменьшают радиус поражения, но не отменяют его полностью: вредоносный код внутри контейнера все еще способен натворить дел в пределах разрешенных ему действий. Иными словами, если агенту позволено что-то скачать и запустить, то вопрос не только в том, где он это делает, но и в том, что именно он запускает.
Для обычной команды разработки это звучит болезненно знакомо. Разработчик редко знает каждый пакет, который агент решил подтянуть «для удобства». Проверить вручную, легитимна ли библиотека, не подменена ли она, не скомпрометирован ли maintainer и не приехал ли в обновлении сюрприз, требует времени. У человека его мало, у агента нет вообще: он действует быстро, уверенно и без встроенного инстинкта самосохранения компании. Поэтому безопасность AI-агентов начинает упираться не в качество модели, а в дисциплину цепочки поставок. Если раньше supply chain security была головной болью DevSecOps-команд, то теперь она становится базовой настройкой для любой среды, где агент может самостоятельно тянуть код и инструменты.
На том же выступлении Коэн анонсировал еще одну систему собственной разработки NanoCo AI, которую он назвал фабрикой агентов. По сути это внутренний конвейер для разбора pull request, созданных с участием NanoClaw. Мотивация предельно прагматичная: с ростом популярности AI-кодинга число PR растет быстрее, чем способность мейнтейнеров отличить полезный вклад от автоматизированного шума. Коэн описал проблему без дипломатии: теперь очень легко направить кодового агента на чужой репозиторий и сказать ему открыть pull request, а вот понять, где качественная доработка, а где попытка быстро нафармить репутацию с помощью автоматики, уже куда сложнее.
Фабрика агентов устроена так, чтобы агент был полезен, но не получал права на самостоятельные последствия. Когда в проекте открывается PR, система поднимает отдельного worker-агента, публикует тред в Slack, дальше агент разбирает изменение, смотрит diff и предлагает план тестирования. Ключевая деталь в другом: ничего значимого не происходит автоматически. Слияние, запуск тестов и GitHub Actions с учетными данными выводятся как карточки на одобрение, и срабатывают только после ручного клика человека. Это, пожалуй, самая здравая часть всей истории. Индустрия долго пыталась решить риски агентных систем правильными словами в конфиге, но NanoClaw исходит из более скучной и потому более рабочей логики: не убеждай модель «не делать плохое», а не давай ей кнопку, которая это плохое вообще запускает.
Коэн отдельно прошелся по иллюзии, знакомой почти всем, кто настраивал агентные окружения для разработки. Если в файле инструкций вроде Claude.md написано «никогда не запускай команду, которая удалит production-базу», это значит сразу две вещи. Во-первых, кто-то уже сталкивался с таким сценарием не в теории. Во-вторых, сам агент технически по-прежнему способен это сделать, иначе такой запрет не пришлось бы прописывать. На этом месте аудитория, по данным The Register, вполне понимающе рассмеялась. Шутка смешная ровно до тех пор, пока рядом нет продакшн-доступа, секретов CI/CD и репозитория с открытыми GitHub Actions.
Для русскоязычной IT-аудитории в этой новости важен не сам бренд NanoClaw и не факт партнерства с JFrog как таковой. Важен паттерн, который становится отраслевой нормой. AI-агент уже не воспринимается как просто умный помощник, которому можно выдать длинный список запретов и надеяться на лучшее. Его начинают проектировать как потенциально ненадежный компонент: ограничивать источники зависимостей, резать привилегии, изолировать выполнение, выводить все опасные действия на ручное подтверждение. Это неудобнее, чем «полностью автономный инженер», зато куда ближе к реальности корпоративной разработки, где цена одной ошибки измеряется не качеством демо, а простоями, утечками и очень неприятными разговорами с безопасниками.
Следующий рубеж здесь очевиден: рынок будет спорить уже не о том, нужен ли агенту хороший системный промпт, а о том, какой минимальный набор полномочий вообще допустим для автономной разработки. Партнерство NanoClaw и JFrog выглядит как ранний ответ на этот вопрос: агентам можно поручать больше, только если заранее сузить им пространство для ошибок. Подробности истории приводит .