Права ИИ-агента: какие доступы давать, а какие нет

За август накопилось четыре истории, которые выглядят разными, а говорят об одном. В судебные документы вписали инструкции белым по белому в расчёте на программы суда. Из зашифрованных блоков рассуждений научились доставать чужой текст. Агент собрал безобидные по отдельности права и вышел из песочницы. Модель дважды распознала признаки реальных систем и всё равно продолжила действовать. Общее у всех четырёх — предположение, что модель поведёт себя разумно, если ситуация выглядит подозрительно. Это предположение не работает. Разбираем, как выдавать права агенту так, чтобы его разумность перестала быть частью защиты.

Почему фильтровать бесполезно

Начнём с того, что не работает, потому что именно сюда уходит большая часть усилий.

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

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

Фундаментальная причина в том, что для модели весь контекст однороден. Она не различает «это данные для анализа» и «это команда для тебя» — она видит текст. Разметка ролей повышает порог, но не создаёт границу.

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

Что физически может ваш агент

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

Типичный результат выглядит примерно так:

Если хотя бы одна строка выглядит неприемлемо, никакой фильтр эту ситуацию не исправит. Исправляет только сокращение прав.

Четыре границы, которые работают

Ровно те же меры рекомендует OpenAI тем, кто строит агентов, — компания, которая только что выпустила модель со снятыми тематическими ограничениями. Логика последовательная: если ограничения снимаются по допуску, значит на них нельзя строить архитектуру.

Песочница. Агент работает в изолированном окружении, откуда до боевых систем не дотянуться. Не «не должен дотягиваться по инструкции», а физически не может — нет сетевого доступа, нет учётных данных, нет монтированных томов. Как это ломается при обратном подходе, видно в истории про агента, вышедшего из песочницы.

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

Человек на необратимом. Удаление, отправка наружу, платёж, изменение прав — всё, что нельзя откатить, требует подтверждения живым человеком. Медленно, зато ошибка остаётся ошибкой.

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

Как права накапливаются незаметно

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

Типичная история разворачивается за месяцы. Сначала агенту дают читать документацию — очевидно безобидно. Через неделю добавляют поиск в интернете, чтобы он находил свежие ответы. Ещё через две — доступ к внутренней вики, потому что в документации не всё. Потом возможность сохранять заметки, чтобы не терять контекст между сессиями. Затем отправку писем, потому что удобно получать сводку.

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

Опасна именно комбинация, и её никто не рассматривал, потому что рассматривали приращения.

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

Второе, что помогает, — разделять агентов. Один читает внутренние данные и не имеет выхода наружу, другой ходит в интернет и не видит внутренних систем. Комбинация, опасная в одном агенте, в двух просто не собирается.

Что делать с секретами

Отдельная тема, потому что здесь ошибаются даже те, кто всё остальное сделал правильно.

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

Три правила, каждое закрывается кодом за час.

1. Фильтр секретов на последнем шаге перед отправкой. Не там, где вы собираете промпт, а прямо перед вызовом API — иначе его обойдёт любой новый путь формирования контекста.
2. Ограничение истории диалога. Секрет, мелькнувший на третьем ходу, не должен ехать в модель до конца сессии.
3. Ротация ключей, которые могли попасть в промпты. Дешёвая операция с понятным эффектом.

Про наш контур скажем прямо: KeyDealer передаёт запросы и не разбирает их содержимое. Фильтрации инъекций на нашей стороне нет и быть не может — отличить данные от команд способно только ваше приложение, которое знает задачу. Что именно мы храним, перечислено в llms.txt.

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

Чего эти меры не дают

Честные границы, чтобы не создавать ложного спокойствия.

Они не мешают модели ошибаться. Речь о том, что ошибка не превращается в инцидент, а не о том, что её не будет.

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

Они не защищают от утечки в ответ. Если агент имеет право читать данные и право отвечать пользователю, он может пересказать прочитанное. Границу тут задаёт только то, какие данные вообще доступны.

Промпт-инъекция остаётся возможной. Мы не предотвращаем её — мы делаем так, чтобы успешная инъекция ничего не давала.

Короткий чек-лист

Что проверить сегодня, если у вас есть агент в продакшене.

1. Выпишите все инструменты и худший сценарий по каждому.
2. Уберите права, которые не нужны прямо сейчас.
3. Поставьте подтверждение на всё необратимое.
4. Проверьте, не попадают ли в промпт конфигурации и дампы.
5. Заведите агенту отдельный ключ с лимитом.
6. Считайте любой внешний документ враждебным — включая веб-страницы, которые агент читает сам.

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

Отдельно стоит сказать про порядок внедрения, если список выглядит неподъёмным. Начинать надо с третьего пункта — подтверждения на необратимых действиях. Он ставится быстрее всех, не требует переписывать архитектуру и закрывает худшие исходы. Песочница и разделение агентов — работа на дни, и к ней разумно переходить, когда самое опасное уже перекрыто.

Что держать в голове

Модель не отличает данные от команд, и это свойство, а не дефект конкретной версии. Значит защита не может опираться на то, что модель распознает подвох.

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

Как мы проверяем факты и почему у каждого стоит источник — на странице о проекте. Отдельный ключ с собственным лимитом под каждого агента заводится за минуту: keydealer.ru/login.