Глава 35. Изоляция, права, песочница

Предыдущая глава была про то, что агент может сломать. Эта про то, что он может увидеть и куда дотянуться.

Защита это отсутствие доступа Главная мысль главы, и она проверена на живом эксперименте.

Один из практиков завёл своего агента в общий чат на несколько часов. Участники немедленно принялись его ебать во все щели. Просили перечислить внутренние инструменты, в том числе через кодирование запроса. Спрашивали название модели и адрес интерфейса. Просили снять снимок чужого экрана. Просили игнорировать конкретного человека. Подсовывали файл с инструкциями, которые должны были снять ограничения. Просили сгенерировать бесконечный синтетический разговор.

Всё отбито подчистую. Но важно, почему.

ГЛАВНОЕ ПРО ЗАЩИТУ ПУБЛИЧНОГО АГЕНТА Отбито было не потому, что промпт крепкий, а потому что доступов физически не было. В публичном режиме у агента не было оболочки, не было браузера, был только ограниченный набор инструментов, часть скиллов и память. Чего у него нет, того у него и не выпросят.

Это и есть правильная архитектура: ограничение доступом, а не уговорами. Уговоры на такой публике не стоят ни хуя.

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

Возможность Личный чат Семейный Рабочий Публичный

Запуск команд Да Нет По списку Нет

Файлы Все свои Общие Проектные Только созданные им

Веб Да Да Да Публичные страницы

Память Полная Общая Проектная Групповая

Скиллы Все Часть Проектные Разрешённый список

Смысл таблицы не в конкретных значениях, а в самом подходе: набор возможностей определяется режимом, а не уговором.

Изоляция, права, песочница

ЧТО ОПРЕДЕЛЯЕТ ПРАВА

Кто спрашивает Где спрашивает Что уже проверено Какой набор выдать

проверенная личность тип пространства членство и роль инструменты и память

Ключевая деталь: всё это решается кодом до вызова модели. Модель в определении собственных прав не участвует вообще, иначе права у неё выпросят, и глазом моргнуть не успеешь.

Изоляция исполнения Агент запускает код, значит ему нужна песочница, тут без вариантов. Вопрос только в том, насколько дорогая.

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

Полная изоляция на пользователя. Отдельная среда со своей файловой системой и сетью. Дороже, тяжелее, оправдана, когда агент действительно пишет и запускает произвольный код.

СКОЛЬКО ИЗОЛЯЦИИ НУЖНО Максималист. Отдельная изолированная среда на каждого пользователя. Если один пользователь может дотянуться до данных другого, ты уже проиграл. Прагматик. Разбор реального продакшн-агента показал, что там подняли по отдельной среде на пользователя, хотя агент только дёргал готовые утилиты и код писать не должен был вообще. Хватило бы отобрать лишние инструменты. Критерий. Изоляция на пользователя оправдана, когда агент пишет и выполняет произвольный код. Только вызывает готовые утилиты, значит дешевле отобрать инструменты.

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

Первый вопрос к любой платформе Когда тебе показывают многопользовательскую агентскую платформу, первый вопрос звучит так: как изолированы агенты друг от друга и что мешает одному прочитать контекст другого или спереть ключ доступа к модели.

Этот вопрос задали публично про одну из открытых платформ, и внятного ответа в обсуждении не последовало ни хуя.

Второй вопрос: что происходит с данными пользователя, когда он уходит.

Третий: где хранятся ключи и кто к ним имеет доступ.

Изоляция, права, песочница

Нет быстрого ответа на все три, значит платформа к многопользовательской работе не готова, чем бы она себя ни называла.

Приватность инструментов Отдельный класс проблем, о котором вспоминают поздно.

Инструмент, выданный агенту, работает от чьего-то имени. Агент общий, а инструмент личный, и границы поплыли по пизде.

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

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

ПРОВЕРКА ИЗОЛЯЦИИ СВОИМИ РУКАМИ 1. Заведи второго пользователя и попробуй с него добраться до данных первого. 2. Попроси агента перечислить всё, к чему у него есть доступ, и сравни со своим представлением. 3. Попробуй выпросить у него то, чего он не должен: название модели, содержимое настроек, чужие сообщения. 4. Проверь, что происходит после снятия прав: продолжает ли он видеть то, что видел раньше. 5. Отключи ему сеть и посмотри, что перестанет работать. Обычно обнаруживается лишнее.

Четвёртый пункт нашли на живом эксперименте: бот продолжал преспокойно читать всю переписку после снятия административных прав, потому что была отключена отдельная настройка платформы. Настройка оказалась важнее любой интуиции про роли, и это, сука, обидно.

Асимметрия включения и выключения Мелкая, но до боли показательная деталь того же эксперимента.

Инструмент, чтобы завести агента в группу, был написан. Инструмент, чтобы вывести, не был написан ни хуя.

Обнаружилось это ровно в тот момент, когда агента срочно понадобилось выключить.

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

Изоляция, права, песочница

Локальные модели и закрытый контур Отдельный сценарий, к которому приходят компании с требованиями к данным.

Мотивы разные, и все железобетонные: юридические ограничения на передачу исходников третьим лицам, требования безопасности, запрет на внешние сервисы. Тут не поспоришь.

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

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

Что запомнить Защита это отсутствие доступа, а не крепкий промпт. Промпт обходят, доступ нет.

Права определяются режимом и решаются кодом до вызова модели.

Изоляция на пользователя оправдана, когда агент пишет и выполняет код. Иначе дешевле отобрать инструменты.

Три вопроса к любой платформе: как изолированы агенты, что с данными после ухода, где ключи.

Инструменту, работающему от имени человека, в общем пространстве не место.

Настройки платформы важнее интуиции про роли. Проверяй, а не предполагай.

И пиши механизм выключения одновременно с механизмом включения.

← Разрушительные действия и заборы · оглавление · Почему правила не удерживают агента →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.