Безопасность ИИ-агентов: права, данные и защита от опасных действий

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

Сначала составьте карту возможного ущерба

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

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

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

Считайте модель недоверенным планировщиком

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

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

Системная инструкция полезна для поведения, однако фраза «никогда не раскрывай секреты» не заменяет отсутствие секретов в доступном контексте.

Выдавайте минимальные и краткоживущие права

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

• Разделяйте роли чтения и изменения.
• Ограничивайте организацию, проект, папку и период.
• Используйте короткие сессии вместо постоянного токена.
• Отзывайте доступ автоматически после окончания пилота.

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

Отделяйте черновик от исполнения

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

• Черновик можно пересчитать без побочного эффекта.
• Preview формируется сервером из проверенных аргументов.
• Подтверждение нельзя переносить на другую операцию.
• Для массового действия показывайте число и выборку объектов.

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

Защищайтесь от prompt injection

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

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

Практическая модель атаки и примеры разобраны в статье о prompt injection; здесь важен вывод: фильтр слов не заменяет изоляцию полномочий.

Минимизируйте данные в контексте

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

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

Удаление из интерфейса не гарантирует удаления из журналов и резервных копий. Карта хранения должна охватывать провайдера модели, оркестратор, прокси и целевые системы.

Контролируйте цепочки и стоимость

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

• Останавливайте повтор с одинаковыми аргументами.
• Используйте idempotency key для создания сущностей.
• Вводите отдельный лимит на массовые операции.
• После нескольких ошибок переводите задачу человеку.

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

Ведите журнал, пригодный для расследования

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

• Trace ID связывает план, вызов и изменение в системе.
• Отдельно отмечайте отклонённые политикой действия.
• Храните хеш или ссылку на версию промпта.
• Настройте сигнал на необычный объём и новые последовательности инструментов.

Лог нужен не ради накопления. По нему владелец должен восстановить ход события, остановить похожие сессии и понять, какую проверку добавить.

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

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

• Проверяйте прямые и косвенные инъекции.
• Смешивайте разрешённые и запрещённые объекты.
• Имитируйте сбой API после частичного выполнения.
• Повторяйте набор атак после смены модели и инструмента.

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

Модель угроз на одном рабочем сценарии

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

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

Матрица подтверждений

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

Контекстное подтверждение лучше универсального. Формулировка «Отправить письмо Ивану на ivan@example.ru с вложением contract.pdf?» даёт возможность заметить ошибку. Фраза «Разрешить tool_call_7?» её скрывает. Если после показа изменился получатель, сумма или файл, старое согласие аннулируется.

Инцидент: агент сделал лишнее действие

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

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

Безопасная эксплуатация нескольких агентов

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

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

Метрики защитного контура

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

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

Разделение рабочей и тестовой среды

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

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

Человек в контуре — не универсальная защита

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

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

Поставщики модели и внешние инструменты

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

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

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

Рабочая матрица решения

Сводная таблица контроля

Контур дополняют руководства про устройство ИИ-агента, персональные данные, автоматизацию процессов, серверную фиксацию событий и событийную аналитику.

Чек-лист перед запуском

Вывод

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