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