Безопасность AI-воркфорса: изоляция, sandbox, разграничение прав

AI-воркфорс безопасность: где ломается изоляция агентов

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

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

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

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

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

Что даёт управляемая изоляция: сборка, откаты, простой

Безопасность AI-воркфорса держится на границах, а не на доверии к модели. Агент без ограниченного контура видит весь кластер: секреты, внутреннюю сеть, чужие тома — и одна лишняя инструкция в цепочке вызовов отправляет его писать не туда. Изоляция закрывает это на уровне платформы: Kubernetes даёт каждому агенту отдельное пространство имён, лимиты по процессору и памяти и сетевые политики, разрешающие только согласованные исходящие соединения.

Что меняется в измеримых величинах

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

Откат, который не превращается в инцидент

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

Режимы изоляции: контуры безопасности и их ограничения

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

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

Четыре режима и их пределы

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

Порядок внедрения: аудит, схема, настройка, проверка, передача

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

Этапы внедрения

1. Аудит контура агентов. Собираем список агентов, моделей и инструментов, к которым они обращаются, фиксируем сервисные учётные записи, ключи, внешние сервисы и объёмы доступных данных. На выходе — карта контура с пометкой, где права выданы шире задачи.
2. Проектирование схемы доступа. Для каждого агента описываем, что он читает, куда пишет и что ему запрещено; разделяем роли агентов и людей. Схему согласуем с владельцем процесса до первой настройки.
3. Настройка ограничений. Выдаём минимально достаточные права, включаем изолированную среду исполнения, ограничиваем сетевые вызовы и объём данных на одну операцию.
4. Проверка на попытках обхода. Прогоняем сценарии выхода за периметр: подмена запроса, вызов запрещённого инструмента, чтение чужого контекста. Каждое срабатывание закрываем отдельным правилом.
5. Журналирование и разбор инцидентов. Пишем, кто вызвал агента, с какими правами и что вернулось; настраиваем оповещения. Иначе разбор сбоя превращается в догадки.
6. Передача регламентов. Отдаём схему доступа, матрицу ролей, порядок подключения новых агентов и отзыва прав при выводе из эксплуатации.
7. Сопровождение. Пересматриваем права при изменении задач и по итогам разборов — контур не должен разрастаться сам.

Артефакты внедрения: конфигурации, политики доступа, регламенты

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

Конфигурации, доступы и схемы интеграций

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

Журналирование и регламенты эксплуатации

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

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

Кейс: как изоляция агентов убрала класс отказов

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

Что изменили и что это дало

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

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

Доля запусков с лишними действиями агента упала с 18% до 0,3%, инцидентов за квартал стало один вместо 14, и тот оказался ложным срабатыванием. Остановка сценария занимает 20 секунд: гасим один агент, остальные продолжают работу. Согласование нового доступа — четыре часа вместо пяти рабочих дней, потому что решение принимается по готовому шаблону прав.

Класс отказов, из-за которого агент мог задеть чужой сервис, ушёл: за пределами своего окружения у сценария нет прав. Второй человек нужен только на изменение самих прав — это единственная операция, где решение принимается вручную.

Что делать, если агенты уже работают в общем контуре?

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

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

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

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

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

Права, журналирование и откапы: технические сомнения

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

Хватает ли журнала, чтобы разобрать ход решения?

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

Что делать, если агент внёс неверное изменение?

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

Как проверяется, что доступы не раздавались лишним?

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

Обсудим вашу задачу: с чего начинаем работу

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

• Карта ландшафта: модели и их размещение (внешний провайдер или ваш контур), среда исполнения, оркестратор, очереди заданий.
• Роли и права: кто из агентов что вызывает, к каким базам, файловым хранилищам и внутренним сервисам обращается.
• Границы допустимого: сценарии автономной работы и точки, где обязательно подтверждение человека.
• Требования безопасности: что логируется, сколько хранится, какие данные не покидают контур.
• Точки интеграции: интерфейсы, сервисные учётные записи, сети и сегменты, по которым идёт трафик.
• Наблюдаемые инциденты: случаи, когда агент вышел за рамки роли или получил лишний доступ.
• Критерии приёмки: по каким проверкам вы поймёте, что изоляция и разграничение прав работают.

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

• Все агенты в одном общем контуре. Доступы, ключи и учётные записи не разделены: сбой или ошибка одного агента открывает данные и действия остальных — границы ответственности размываются ещё на этапе запуска.
• Права выдают «с запасом». Рассуждение «пусть работает, потом сузим» приводит к тому, что у агента остаются лишние возможности на запись и удаление, а сужение прав уже требует переделки рабочих процессов.
• Разделяют только периметр, а не задачи. Изоляция сводится к сетевой границе, тогда как внутри контура агенты делят между собой одни и те же каталоги, подключения и промежуточные хранилища.
• Хранят служебные данные в открытом виде. Пароли, ключи и токены остаются в файлах конфигурации или переменных окружения — изоляция агентов обесценивается, потому что доступ достаётся вместе с копией файла.
• Не ведут журнал действий агента. Нет привязки операции к конкретному исполнителю и времени: инцидент нельзя разобрать, а откат делается вслепую, по памяти и вручную.
• Оставляют обходные пути. Отдельный контур построен, но рядом живут общие папки, тестовые подключения к рабочим системам и «временные» учётные записи — через них ограничения обходятся без всякого взлома.
• Изоляцию проверяют один раз. Настройку считают готовой после первичного запуска и не повторяют попытки выхода из контура, поэтому ослабление прав и новые связки между сервисами остаются незамеченными.
• Не отрабатывают возврат к прежней схеме. Нет заранее подготовленного порядка отката конфигурации: когда изоляция ломает рабочий процесс, её снимают целиком, лишь бы вернуть работоспособность.