Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
Меня поражает стремление навесить на llm агента то что прекрасно делалось без них. Я бы вместо возни с собственным mcp и гардрейлом для агента просто настроил Прометеус. А во первых для съема телеметрии полно уже готовых решений. Опять же агент мог бы рулить нодежкспортером для Прометея через ансибл
Если смотреть на это с позиции, что мы не саму работу улучшаем (я понимаю, что devops и без этой тулзы справится), а снижаем порог входа (теперь и не девопс и условно не программист в целом сможет делать мало-мальски то же, что и девопс будучи в его сфере некомпетентным), то смысл у этого дела всё-таки появляется
Разобрался с вашими запятыми. Если проект — стартап, то, поверьте, такие системы, наоборот, помогут разработчикам натворить меньше дел, чем если бы они делали всё сами. ИИ неплохо помогает осваивать новые направления. А если ещё попросить его сделать систему тестирования и проверки на безопасность, это уже повышает качество продуктов в стартапах или в проектах, где не хватает компетенций.
Моя же задача как DevOps/SRE иметь первичную диагностику сервиса, при возникновение инцидента. И даже запустить workaround из системы мониторинга.
Мониторинг никто не отменит, вопрос в другом, чтобы когда алерт прилетал в Grafana, в поле ресолв была уже вся информация ) и даже кнопка починить )
Меня поражает, как люди все ещё считают что способны писать короткие скрипты и анализировать гипотезы быстрее чем агенты
Мне всегда нравилась идея "company as service", когда каждый отдел или департамент оказывает услуги (уже оплаченные, согласно трудового договору) сотрудниками или департаментам. Так вот теперь с MCP это становится стандартом, каждый департамент делает своей mcp сервер, и каждый сотрудник может взаимодействовать через ИИ агента )
Настройка получается довольно тяжеловесной. Наверное, имеет смысл так заморачиваться только для долгосрочного сопровождения и там, где вообще есть возможность так сильно перенастроить сервер.
Мне приходилось выдавать root только локальным агентам, поэтому я сделал собственную приблуду (jusdo у меня в профиле на GitHub), которая работает от root, слушает сокет и позволяет выполнить любой рецепт из заранее подготовленного и утверждённого по контрольной сумме Justfile. Можно в любой момент на любой сервер скопировать два бинарника (включая just) + Justfile, а потом запустить вручную.
Посмотрел проект - элеганто!
Очень хотелось заморочиться в 2026 году, а то совсем не понятно, зачем все эти агенты пишутся, если они не пишут тебе код ,)
Хотелось:
- AI way - MCP который рассказывает все, что можно использовать
- Уйти максимально от использование утилит, но тут вот прям не везде по трудо затратам, например переписывать демона docker
- и конечно представить Linux через kubernetes way - linuxctl
Раз вызов идёт от аккаунта с тем же именем, пользователь
rootв mcpd получал root на каждый вызов — мимо всех ограниченийmcp-sudo.yaml. Теперь такой конфиг просто не загружается, аlinuxctlне даст такого пользователя создать.
Вот что меня всегда поражало - почему автор программы считает что лучше меня знает, что мне надо. Ну а если мне надо? Да, от рута.
Разумно - не давать такое сделать случайно. Т.е. не создавать конфиг по умолчанию с рутом. Или требовать специальной конфигурации. Или ключ при запуске. Что угодно, но не "я подумал и решил что мне виднее".
Например авторы ssh не считают себя самыми умными и допускают PermitRootLogin yes хотя куда-уж страшнее.
Может формулировка здесь не подходящая, здесь говорится, что если кому то вдруг захочется добавить пользователя root в mcpd, то как бы вся наша система изоляции рухнет.
Если нужно от root, весь механизм mcp-sudo построен для этого. Так же как в линукс появился sudo. Надо от рута, да пожалуйста, но строго в рамках. Это как раз про не пожалеть случайно ...
В данной реализации, с механизмом mcp-sudo, что вас не устраивает? Какие есть ограничения? Можно пример? Как вы бы сделали?
У программы есть первоочередная задача предоставить, AI агентам доступ до системы наиболее естественным для них способом - это MCP реализация. Со строгими ограничениями unix-way по умолчанию: что не разрешено - то запрещено, на предоставлен механизм точечного, гранулярного расширения прав.
Поэтому хочется услышать вашу точку зрения, чего не хватает, в каких случаях, чтобы хотелось?
Так же хочу обратить внимание, что текущая версия v0.3.5, как говорится до v1 еще очень далеко наверно, как раз для этого статьи и пишутся, чтобы собрать feedback компетентных людей - и в "обсудение" рождаются new feature requests :)
Я бы посмотрел на это с точки зрения "а может просто дать рута агенту?" Поднимаешь виртуальный сервер и отдаёшь его агенту - пусть там сам хозяйничает, раз такой умный. Если что и грохнет, то только этот самый сервак (ну и всё, до чего дотянется через этот сервак). Тогда вопрос безопасности упирается не в ограничения, а в контроль - как убедиться, что агент выполняет то, что надо и не выполняет, чего не надо. Ну и в том, что телеметрия не фейковая.
Как бы мы агента ни ограничивали, эти вопросы всё равно будут актуальными. Может сосредоточиться на них?
Проблема в том, что вы не контролируете агента полностью. Сколько уже было случаев удаления информации с личных ноутбуков и серверов?
Так же, как компания не контролирует сотрудника на сто процентов: у него есть свобода воли, и с неограниченными правами он может начудить будь здоров. Пока правовая система не начала судить ИИ-агентов за нанесенный урон, думаете, стоит ввести для них какую-то ответственность? :)
Поэтому мне пока непонятна эта движуха с рутом, кроме как классического ролинга-троллинга :)
Вы пускаете в систему неконтролируемую сущность — а как же правила ИБ и другие наработанные стандарты?
В общем, пока вы полностью не контролируете код и логику агента, добиться того, чтобы он делал только то, что надо, и не делал того, чего не надо, у вас просто не получится. Это всегда «обезьяна с гранатой».
И да на этом должны сосредотачиваться разработчики AI агентов, а не я как разработчик демона. А пока они сосредотачиваются, мы будем делать дела, и запускать обезьяну в строго ограниченных вольерах под запись, как и делали до этого.
Хотите рута? Попросите AI агента прочитать документацию демона, и состряпать вам конфиг с разрешенными максимально расширенными границами, делов то? :)
Проблема в том, что вы не контролируете агента полностью, сколько было уже случаев удаления информации с личных ноутбуков и серверов?
Да, именно об этом я и говорю. Не надо вообще запускать агента там, где он может сделать что-то вредное. Надо сразу подходить с точки зрения, что агент - это "обезьяна с гранатой". Не пускайте её в "жилые помещения" (свой ноутбук), пусть в "специальном бункере" (VPS) играется.
А если агент уже в "бункере", то в чём смысл ограничивать его права? Как раз лучше сосредотачиваться на мониторинге и контроле. И сохранности данных.
Точно так же, как вы нанимаете «обезьяну с гранатой», чтобы делать работу, и ограничиваете ее трудовым договором и NDA, так и тут — кто-то же должен работать :) Обезьяна-агент моего вассала — не мой вассал.
По поводу "не запускать" не соглашусь в корне. Это как компании-сельпо, где у людей визуальный мониторинг, где они за графиками глазами смотрят, а потом мы удивляемся про недоступность сервисов и веселые цифры в SLO, SLI, SLA :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доверить сервер ИИ-агенту и не пожалеть: как спать спокойно без SSH