Почему агенту нельзя давать «рабочую учётку»

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

OWASP называет это excessive agency — избыточной агентностью. Корневая причина обычно состоит из трёх частей: агенту доступно больше функций, чем нужно; его техническая учётная запись имеет слишком широкие права; опасные операции выполняются без независимого подтверждения. Защищаться поэтому нужно не только промптом. Полномочия ограничивают в самих инструментах и целевых системах.

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

Правильная единица проектирования — не «умный помощник», а конкретная операция с владельцем, входными данными, областью доступа и условиями исполнения.

Разделите чтение, подготовку и действие

Процесс полезно разбить на три уровня.

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

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

**Действие.** Отдельный исполнитель применяет утверждённое изменение. Он не принимает свободный текст модели как команду, а работает с узкой схемой: `create_draft`, `add_crm_note`, `reserve_stock`. Для чувствительных операций требуется человек или независимое правило.

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

Матрица прав для трёх знакомых систем

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

Для агента первичной обработки почты разумный набор может быть таким:

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

Для CRM:

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

Для учётной системы:

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

Если API поставщика не умеет разделять такие права, безопасный адаптер должен показать агенту только собственные узкие методы. Универсальный метод «выполни любой запрос» или доступ к командной строке делает область возможной ошибки слишком большой.

Где должны жить токены

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

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

Практический минимум:

  • отдельная техническая идентичность для каждого агента и среды;
  • разные токены для почты, CRM и учёта;
  • короткий срок жизни токена и понятная процедура отзыва;
  • привязка токена к конкретному ресурсу и проверка аудитории;
  • запрет передачи входящего токена дальше в сторонний API;
  • исключение заголовков авторизации и секретных полей из журналов.

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

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

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

Удобно разделить операции по риску:

  • низкий: чтение справочника, поиск документа, добавление внутренней метки — автоматическое выполнение;
  • средний: создание черновика, резерв товара, обновление некритичного поля — выполнение по правилу и с журналом;
  • высокий: внешняя отправка, удаление, платёж, изменение прав, массовый экспорт — обязательное подтверждение человеком.

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

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

Журнал нужен не для объёма, а для ответа

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

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

Для раннего обнаружения проблем настройте простые сигналы:

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

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

Локальная модель не отменяет контроль доступа

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

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

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

Пилот за две недели

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

В первую неделю:

  • опишите 20–50 реальных сценариев, включая ошибки и вредоносные инструкции;
  • составьте матрицу инструментов и прав;
  • создайте отдельные технические учётные записи;
  • определите поля подтверждения и журнала;
  • установите лимиты частоты и аварийный отзыв.

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

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

Управленческий вывод

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

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