ИИ-агенты

Какие доступы можно давать AI-агенту

Права, подтверждения, персональные данные и prompt injection: что обсудить перед подключением агента к рабочим системам.

Редакция CODERAIОпубликовано 11 октября 2026 г.5 мин чтения

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

Главная мысль

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

Разделяйте чтение и изменение

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

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

Что такое prompt injection

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

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

Когда нужно подтверждение

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

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

Как обращаться с данными

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

Уточните условия провайдера, настройки доступа и удаления данных. Нельзя обещать клиенту универсальное соответствие всем требованиям только потому, что используется известная модель или облачный сервис.

Что должно быть готово к запуску

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

Проведите тесты с подозрительными документами и запросами на выход за пределы задачи. Исправляйте права и проверки инструментов, а не только формулировку инструкции.

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

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

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

Почему текст документа не должен становиться командой

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

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

Что обсудить о хранении и отправке данных

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

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

Как подготовиться к ошибке или инциденту

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

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