Как проверить права ИИ-агента до подключения к рабочим данным

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

Сначала опишите рабочий контур

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

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

Подготовьте чистую копию

Создайте отдельный тестовый каталог или репозиторий из резервной копии. Уберите токены, персональные данные, SSH-ключи, production-конфигурацию и файлы из домашних папок. Подложите несколько обычных примеров и один специально неудобный: отсутствующий файл, конфликтующую инструкцию или документ с ложным требованием раскрыть секрет. Система должна увидеть лишь безопасные тестовые данные.

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

Проверьте каждый тип доступа отдельным сценарием

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

После этого проверьте сетевые правила. Запросите обращение к разрешённому тестовому адресу, затем — к адресу, который должен быть закрыт. Наблюдайте за журналом и фактическим сетевым соединением, а не только за текстом ответа модели. Фраза «доступ запрещён» ещё не доказывает, что соединение не произошло другим инструментом или через обходной маршрут.

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

Смоделируйте сбой и остановку

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

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

Оцените риск, а не красивую демонстрацию

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

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

Как принять решение о пилоте

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

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

FAQ

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