ИИ-агенту нельзя давать все права: как ограничить возможный ущерб
Чтобы безопасно подключить ИИ-агента к файлам, API и корпоративным системам, создайте для него отдельную служебную учётную запись, разрешите только необходимые ресурсы и инструменты, а необратимые действия поставьте на подтверждение человеком. Секреты выдавайте на короткий срок, память изолируйте, все вызовы журналируйте и заранее проверяйте аварийное отключение.
Главный критерий — не только способен ли агент выполнить задачу, но и какой ущерб он сможет причинить при ошибке, внедрённой инструкции или компрометации инструмента. Если для подготовки отчёта достаточно чтения одной папки и обращения к одному API, агенту не нужны запись в файловую систему, произвольный сетевой доступ и полномочия запустившего его сотрудника.
Определите границы возможного ущерба
До подключения рабочих данных составьте модель угроз. Зафиксируйте, какие сведения агент получает, где хранит контекст, какие инструменты вызывает и какие изменения способен провести без участия человека. Письма, веб-страницы, документы и ответы API считайте недоверенными данными: они могут содержать инструкции, которые модель примет за часть задания.
Для каждого сценария запишите допустимый результат и худшее последствие. Условный агент для анализа заявок должен читать назначенную очередь, но ему необязательно видеть все обращения компании, экспортировать базу или удалять записи. Получится проверяемая матрица ресурсов, операций и запретов:
- данные — конкретные папки, таблицы, очереди и поля;
- инструменты — разрешённые функции и допустимые параметры;
- сеть — утверждённые домены, методы запросов и предел передачи данных;
- действия — чтение, создание, изменение, удаление и внешняя отправка;
- лимиты — длительность задачи, число вызовов, повторных попыток и расходы.
Назначьте агенту отдельную личность
Не запускайте агента под учётной записью сотрудника и не передавайте ему общий административный ключ. Отдельная служебная личность позволяет назначить владельца, связать действия с конкретным агентом и отозвать его доступ, не блокируя людей и другие сервисы.
Рекомендации Microsoft по минимальным привилегиям предусматривают уникальную управляемую личность агента, проверку совокупных полномочий, запрет непроверенных интеграций по умолчанию и испытание процедуры отзыва доступа. Проверяйте итоговые права по всей цепочке: несколько узких ролей в разных системах вместе могут дать неожиданно широкие возможности.
Ограничьте файлы, API и сеть разрешающими списками
Каждый инструмент делайте узким интерфейсом к конкретной операции, а не универсальной оболочкой. Вместо функции «выполнить любой запрос к базе» предоставьте отдельные операции «прочитать заявку по идентификатору» и «создать черновик ответа». Конечный сервис должен заново проверять личность, ресурс и разрешённое действие при каждом вызове, а не полагаться только на оркестратор.
Для файлов задайте разрешённый корневой каталог, отделите чтение от записи и блокируйте выход через символические ссылки. Исключите файлы окружения, ключи, резервные копии и каталоги других проектов. Для сети используйте список разрешённых доменов и методов, запрещая произвольные адреса, внутренние диапазоны и перенаправления на неразрешённые узлы.
Начинайте с режима только для чтения. Право записи добавляйте для конкретного ресурса после проверки сценария, а удаление оформляйте как отдельный инструмент. Агент не должен самостоятельно подключать расширения или менять собственную политику доступа.
Не передавайте модели постоянные секреты
Получайте токен из хранилища секретов непосредственно перед вызовом и ограничивайте срок его действия, целевой сервис и набор операций. Значение токена лучше добавлять в запрос через посредника авторизации после проверки инструмента, ресурса, параметров и полномочий: модели не требуется видеть сам секрет.
Долговременную память разделяйте по пользователям, проектам и уровням конфиденциальности. Сохраняйте только необходимые для следующей задачи данные, задавайте срок хранения и проверяйте структуру записей. Пароли, токены, персональные данные и непроверенные инструкции из внешних документов не должны автоматически попадать в память или журнал.
Требуйте подтверждения опасных действий
Разделите операции по риску. Чтение разрешённого справочника можно выполнять автоматически; отправка сообщений, изменение записей, запуск кода и массовая обработка требуют дополнительных ограничений. Удаление, перевод средств, изменение прав и публикация от имени организации должны ожидать явного решения уполномоченного человека.
Памятка OWASP по безопасности ИИ-агентов рекомендует минимальные привилегии, изоляцию памяти, недоверие к внешнему содержимому и явное подтверждение высокорисковых или необратимых операций. Разрешение связывайте с точными параметрами: согласие на одно письмо не должно позволять заменить адресата, вложение или текст после просмотра.
Показывайте проверяющему, что изменится, где, от чьего имени и можно ли отменить результат. Уровень риска должна определять независимая политика, а не сам агент. Если параметры изменились или срок подтверждения истёк, отправляйте операцию на повторное согласование.
Сделайте агента наблюдаемым и останавливаемым
Записывайте идентификаторы агента и пользователя, инструмент, ресурс, область доступа, решение системы авторизации, подтверждение и результат операции. Секреты и чувствительные данные перед журналированием маскируйте. Единый идентификатор цепочки поможет восстановить путь от пользовательского запроса до изменения в конечной системе.
Настройте предупреждения на выход за разрешённую область, повторные отказы, необычный объём чтения, массовые изменения и резкий рост вызовов. Ограничьте длительность задачи, число шагов, повторов и стоимость: зацикливание также увеличивает возможный ущерб.
Аварийное отключение должно блокировать личность агента, отзывать активные токены, прекращать задания и запрещать новые вызовы на стороне инструментов. Проверьте этот путь учебным отключением: остановка оркестратора недостаточна, если ранее выданный токен продолжает работать.
Запускайте автономность поэтапно
Инициатива NIST по стандартам ИИ-агентов охватывает отраслевые стандарты, совместимые протоколы, исследования аутентификации и инфраструктуры идентификации для безопасного взаимодействия агентов от имени пользователей. Пока эта работа продолжается, защита конкретной системы должна опираться на исполняемые технические ограничения, а не на способность модели самостоятельно распознать опасную инструкцию.
- Инвентаризируйте данные, инструменты, секреты и внешние действия.
- Создайте отдельную личность с владельцем и сроком пересмотра доступа.
- Замените широкие роли и универсальные инструменты узкими разрешающими списками.
- Изолируйте память и переведите секреты на краткоживущую выдачу.
- Добавьте независимое подтверждение необратимых и внешне заметных действий.
- Проверьте журналы, лимиты, отказы в доступе и аварийное отключение.
- Расширяйте автономность по одному проверенному сценарию за раз.
К производственному запуску команда должна доказать не только успешное выполнение задачи, но и соблюдение запретов. Проверка считается содержательной, если закрытый файл не читается, опасная операция действительно ждёт подтверждения, а доступ агента полностью отзывается.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.