Где возникает риск

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

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

Три разных субъекта вместо одного «бота»

В типовой интеграции полезно разделить три понятия:

  • Сотрудник, по чьему запросу выполняется действие. У него есть должность, зона ответственности и доступ к конкретным клиентам или подразделению.
  • Сервис агента. Его техническая идентичность позволяет обратиться к шлюзу инструментов, но сама по себе не должна давать доступ ко всем записям CRM и ERP.
  • Инструмент или шлюз действий. Он проверяет пользователя, допустимость операции и границы данных перед обращением к целевой системе.

Если целевая система поддерживает делегированный доступ, действие можно выполнять в контексте пользователя и с нужным ограниченным scope. Стандарт OAuth 2.0 Token Exchange описывает механизм, с помощью которого один сервис получает токен для обращения к другому сервису от имени пользователя; конкретные возможности зависят от реализации провайдера и целевой системы. Это не универсальная кнопка: старые CRM и ERP могут не поддерживать такую схему. Тогда шлюз обязан проверять полномочия пользователя самостоятельно, а его собственная техническая учётная запись должна иметь минимальные права, достаточные только для разрешённых операций.

Как выглядит безопасный путь записи

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

1. Приложение аутентифицирует сотрудника и передаёт шлюзу его идентификатор, подразделение и контекст запроса. Агент не подставляет эти поля из собственного ответа.
2. Модель предлагает структурированное действие: например, `update_next_contact` с идентификатором карточки и новой датой. Свободный SQL-запрос или универсальный HTTP-вызов в этом процессе не нужен.
3. Шлюз повторно получает карточку, проверяет принадлежность подразделению, роль сотрудника, разрешённые поля и срок действия запроса. Проверка проводится непосредственно перед записью, а не только при начале диалога.
4. Для чувствительных изменений — скидки, платёжных реквизитов, удаления, массового экспорта — шлюз требует отдельного подтверждения уполномоченным человеком либо вообще не предоставляет агенту такой операции.
5. После записи система журналирует: кто инициировал действие, какой инструмент использовался, какая карточка затронута, какой результат вернула CRM. Пароли, токены и лишние персональные данные в журнал не попадают.

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

Что делать с секретами и общей учётной записью

Инвентаризация обычно начинается с простого вопроса: каким именно ключом пользуется каждый коннектор агента? Если один секрет открывает и чтение, и изменение, и выгрузку всех данных, разделите операции. Для поиска карточек — учётная запись только на чтение и с ограниченной областью данных; для записи — отдельный канал с узким набором методов и дополнительной проверкой. Токены храните в предназначенном для секретов хранилище, а не в промпте, базе диалогов или настройках, доступных бизнес-пользователям. Опишите срок действия, отзыв и ротацию; при увольнении сотрудника его полномочия не должны продолжать действовать через общий агентский ключ.

Не стоит заменять один «суперключ» несколькими ключами без разграничения: это только умножит количество секретов. Цель — уменьшить максимальный объём данных и действий, доступных каждому коннектору. Если CRM не позволяет создать отдельные роли и ограничить набор данных, зафиксируйте этот пробел как риск и начните с режима подготовки черновиков без автоматической записи.

Данные, инфраструктура и экономика

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

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

Следующий шаг без большого проекта

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