Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
Это очень серьёзная тема, которая пока не имеет нормального решения.
Да, все действия ИИ должен выполнять только через MCP сервер в изолированном окружении. Причём даже простая изоляция на уровне докера не обеспечивает необходимой безопасности. Нужен сильно ограниченный rootless контейнер или виртуальная машина (так как не всё можно запустить в docker).
Любой в сеть должен быть только по белому списку портов. Настроить это для localhost и локальной сети бывает нетривиально.
Любой доступ в интернет должен быть только по белым спискам сайтов и протоколов с ручным одобрением каждого неизвестного соединения. Это совсем уж неочевидная проблема не имеющая общего решения. Всё становится совсем весело, когда оказывается, что никакие секреты ИИ давать нельзя, но при этом нужно обеспечить его доступ к некоторым сторонним сервисам - нужна инъекция токенов и сертификатов на уровне прокси и MCP.
Все браузерные поделки ИИ можно запускать только в выделенном браузере с кучей ограничений. И весь локальный софт тоже можно запускать только в виртуальных средах (особенно весело становится, если этот софт содержит GUI).
В идеале нужна ещё ручная проверка всех пакетов и библиотек.
Нужен откат всего окружения к контрольным точкам с случае зависаний и крашей.
В иных случаях ИИ будет подвержен совершенно примитивным целевым атакам, а при длительной самостоятельной работе будет творить все те ужасы из новостей. Вы дали ему задание, а нужный ему интернет-сервис не отвечает, и он реально ломанёт вам всё, до чего дотянется из самый лучших побуждений.
Я бы сказал, что сейчас вот всё можно решить только частично и ручной настройкой очень сложных окружений. Есть какие-то типовые решения по изоляции, но они подходят только для разработки каких-то типовых web-сервисов.
Индустрия ещё не осознала, что ИИ это злоумышленник, которого вы вынуждены пускать в самое ядро свой инфраструктуры.
Да, я примерно в это и уперся. Только MCP сам по себе не дает изоляции - если у агента есть shell, запущенные им процессы могут обойти MCP. В моем первом прототипе чтение файла блокировалось, а те же тестовые данные оказались доступны через HTTP
Поэтому я проверял вариант с отдельными VM без прямой сети и общих папок, где разрешённые операции идут через broker, там уже ситуация по-лучше, но идеалом я бы все равно не назвал.
Так же некоторые проблемы возникли из-за MacOS, пришлось писать туда на форум выяснять нюансы, и результаты конечно не положительные, часть моих ограничений практически невозможно реализовать на их операционке
Да просто не используйте ИИ. Зачем вы мучаете себя и его.
А не думали о том, что если не делать ограничений то нейросеть нечего не взламывает вообще ? и вся та хрень в новостях происходила только в сценариях когда такое действие было намеренно спровоцированно
После "у меня нет возможности запустить sudo, но вы входите в группу dockers и я сделаю ...", и выполнил команду которая требует sudo, я и не питаю иллюзий об ограничениях, что у меня с ноута все просканировано и корпоративных тайн не осталось.
Вы уже используете поколения идентификаторов для сетевых соединений. А как насчёт аналогичного механизма для разрешений? Допустим, агент получил доступ, потом его отозвали, координатор упал и восстановился из старого состояния. Не воскреснут ли вместе с ним старые полномочия?
Я бы проверял актуальность разрешений непосредственно в broker, по состоянию, которое не откатывается вместе с координатором. А то получится зомби-агент: доступ уже отобрали, а он восстановился и снова пришёл с ключами от продакшена. :)
Такой сценарий тестировали?
про setsid узнал себя, только у нас наоборот было. долгие прогоны тестов агенты сами запускают через setsid nohup, иначе ssh рвется минут через девять и все умирает. а потом "остановил задачу" ничего не останавливает, процесс живет дальше и пишет в дерево которое уже отдали другому агенту
в итоге пришли к тупому: пид в файл при старте, ждать по kill -0, убивать только по пиду. pkill -f у нас вообще запрешен, он пару раз грохнул сам себя вместе с ожидалкой)
а в broker'е как вы считаете что нагрузка задачи реально кончилась, по cgroup?
Cgroup у меня нет, я на маке. Broker вообще не занимается проверкой нагрузки. В прототипе с VM я останавливал ее целиком и проверял, что процесс завершился, а вот для агента, который запустил что-то на хосте, полной гарантии у меня пока нет :(
ну с vm честно, потушил целиком и вопросов нет. на хосте мы пробовали убивать по группе процесов, kill -- -pgid, но setsid как раз из группы и выводит, ровно то что агенты и делают) держится по факту только отдельный юзер под агента. в конце задачи гасишь все процессы этого uid и пофиг сколько раз он там переродился. на маке тоже работает, cgroup не нужен
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хотел поручить AI целый проект. Уперся в изоляцию, память и восстановление после сбоев