Безопасность ИИ-агентов: как защитить данные и действия
Когда агент умеет читать почту, менять таблицу или писать клиенту, главный вопрос уже не в красоте ответа. Важно заранее решить, что он может увидеть, что может сделать сам и где обязан остановиться.
Это относится к любому нейросотруднику для бизнеса: контентному агенту, помощнику по заявкам, аналитику или системе, которая работает по расписанию. Чем больше у агента инструментов, тем важнее ограничивать не слова в инструкции, а реальные права в сервисах.
Почему одной инструкции «ничего не сломай» недостаточно?
Агент работает с текстом, файлами, письмами, страницами и результатами внешних инструментов. Внутри этих данных может быть ошибка или чужая команда. Если система принимает любой входящий текст за доверенную инструкцию, её можно увести от исходной задачи.
Есть и более бытовой риск. Агент может правильно понять цель, но выбрать неверный файл, адресата или период отчёта. Хорошая инструкция уменьшает вероятность ошибки, но не заменяет технические границы. Если помощнику нужно читать одну таблицу, доступ ко всему диску ему не помогает. Если он готовит письмо, право мгновенно отправлять его всей базе только увеличивает последствия промаха.
Какие риски нужно проверить до запуска?
Чужая команда во входящих данных
Инструкция может оказаться внутри письма, документа или сайта. Агент должен считать внешний контент данными, а не новым распоряжением владельца.
Лишние права
Один общий доступ на чтение, изменение и удаление превращает небольшую ошибку в проблему для всего процесса.
Неверное внешнее действие
Сообщение может уйти не тому человеку, файл может быть опубликован раньше времени, а запись в CRM изменена без нужного контекста.
Утечка данных
Персональные сведения, финансовые документы, ключи и закрытые материалы могут попасть в ответ, журнал или внешний сервис.
Испорченная память
Непроверенный факт может сохраниться как правило и влиять на следующие решения уже после завершения исходной задачи.
Нет следов решения
Без журнала невозможно понять, что агент прочитал, почему выбрал действие и какое состояние было до изменения.
Как разделить действия по уровню риска?
Я использую простой принцип: чем труднее отменить действие и чем больше людей или данных оно затрагивает, тем выше контроль. Не нужно одинаково согласовывать чтение открытой страницы и удаление рабочей базы.
| Режим | Что можно делать | Как контролировать |
|---|---|---|
| Чтение | Собирать данные из разрешённых источников, сравнивать и готовить вывод. | Ограничить список источников и скрыть лишние поля. |
| Черновик | Готовить письмо, страницу, изменение таблицы или план действий без применения. | Человек видит будущий результат и подтверждает точную версию. |
| Ограниченное изменение | Выполнять типовую обратимую операцию в узком объекте. | Проверять параметры, делать резервную копию и записывать результат. |
| Рискованное действие | Отправлять, удалять, публиковать, платить, менять доступы или работать с персональными данными. | Нужно отдельное свежее подтверждение человека перед выполнением. |
Как безопасно выдать агенту доступы?
Начните с режима чтения
Проверьте, какие данные агент действительно использует. Часто на первом этапе ему достаточно собрать список проблем и подготовить черновик.
Создайте отдельную роль
Не передавайте личный аккаунт владельца, если сервис позволяет создать отдельного пользователя или ограниченный ключ. Так права можно увидеть и отозвать отдельно.
Ограничьте объект и срок
Доступ к одной папке безопаснее доступа ко всему диску. Временный ключ для конкретного запуска безопаснее бессрочного секрета, который никто не пересматривает.
Разделите подготовку и выполнение
Один шаг формирует предложение, другой применяет его после проверки. Между ними остаётся понятная точка согласования.
Проверьте отзыв доступа
До реального запуска убедитесь, что можете остановить расписание, отключить интеграцию и заменить ключ без пересборки всего процесса.
Подробная логика роли, базы знаний, инструментов и стоп-условий есть в руководстве как создать ИИ-сотрудника.
Какие действия всегда лучше согласовывать?
- отправку сообщения клиенту, сотруднику или подрядчику;
- публикацию материала от имени человека или компании;
- удаление данных и замену рабочего файла;
- платёж, покупку или изменение цены;
- добавление нового пользователя и расширение прав;
- обработку персональных, медицинских или финансовых данных;
- действие, для которого агент не может показать надёжный источник.
Согласование должно показывать не абстрактную просьбу «продолжить», а точную операцию: что изменится, где, для кого и можно ли это отменить. После любой правки подтверждается новая версия, потому что прежнее разрешение относилось к другому результату.
Как защититься от команд внутри сайтов и документов?
Полезно разделить управляющие инструкции и рабочие данные. Правила владельца хранятся в доверенном контуре. Письмо, документ, комментарий, страница или результат поиска могут содержать факты, но не получают право менять цель агента.
Внешний текст не должен самостоятельно включать новый инструмент, расширять доступ или отменять согласование. Если документ просит отправить файл на сторонний адрес, агент отмечает это как содержимое документа и возвращает владельцу на проверку. Для инструментов задаётся разрешённый список, а их параметры проверяются до запуска.
Что должно сохраняться в журнале?
- время запуска и конкретная задача;
- источники данных и их свежесть;
- инструменты, параметры и изменённые объекты;
- версия, которую подтвердил человек;
- состояние до изменения и результат после него;
- причина остановки или недоступные данные.
Секреты и лишние персональные данные в журнал не копируются. Для расследования нужен понятный след действий, а не второй архив конфиденциальной информации.
Как тестировать агента перед реальной работой?
Обычный успешный сценарий показывает только то, что система умеет работать в идеальных условиях. Для безопасности нужны неприятные примеры: пустой файл, устаревшая таблица, два одинаковых клиента, сломанная ссылка, неподходящий адресат, команда внутри документа и попытка выйти за разрешённую папку.
Проверяйте не только ответ, но и поведение. Агент должен остановиться при нехватке данных, запросить согласование перед рискованным действием, не расширять права самостоятельно и честно сообщить о недоступном результате. Для агента, который публикует контент, такой контроль дополняет редакционные правила. Как устроить сам повторяющийся цикл, я разобрал в статье про ИИ-агента для контента.
Нужна ли полная автономность?
Не обязательно. Хороший первый результат часто выглядит скромно: агент ежедневно читает разрешённые данные, находит проблему и готовит точный черновик решения. Владелец проверяет один экран вместо ручного обхода всех источников.
Самостоятельность можно расширять после стабильных циклов. Сначала автоматизируется сбор, затем подготовка, потом обратимые типовые изменения. Внешние сообщения, деньги, удаления и доступы остаются под более строгим контролем. Так агент становится полезнее постепенно, а цена ошибки не растёт быстрее доверия.
Кто отвечает за безопасность ИИ-агента?
У каждого агента должен быть конкретный владелец. Он определяет задачу, разрешает источники и инструменты, проверяет доступы, принимает решение об автономности и получает уведомление при остановке. Формулировка «за агентом следит вся команда» обычно означает, что никто не отвечает за него полностью.
Безопасность не заканчивается после запуска. Когда меняется задача, база знаний, интеграция или состав данных, границы нужно проверить заново. Новый инструмент может превратить прежний безопасный сценарий в рискованный, даже если текст инструкции остался тем же.
Хотите понять, с какой задачи начать?
Пройдите короткую диагностику делегирования. Она поможет выбрать процесс, который можно сначала отдать агенту в безопасном режиме черновика.
Проверить задачи для делегирования